diff --git a/app_template/default/distsearch.conf b/app_template/default/distsearch.conf index 23129734b3..0883f658cd 100644 --- a/app_template/default/distsearch.conf +++ b/app_template/default/distsearch.conf @@ -1,5 +1,5 @@ [replicationSettings:refineConf] replicate.analytic_stories = false -[replicationBlacklist] +[replicationDenylist] excludeESCU = apps[/\\]DA-ESS-ContentUpdate[/\\]lookups[/\\]... diff --git a/baselines/deprecated/baseline_of_excessive_aws_instances_launched_by_user___mltk.yml b/baselines/deprecated/baseline_of_excessive_aws_instances_launched_by_user___mltk.yml index 6982d4af4b..d1dcf15f47 100644 --- a/baselines/deprecated/baseline_of_excessive_aws_instances_launched_by_user___mltk.yml +++ b/baselines/deprecated/baseline_of_excessive_aws_instances_launched_by_user___mltk.yml @@ -10,7 +10,7 @@ description: This search is used to build a Machine Learning Toolkit (MLTK) mode the last 90 days of data to build the model. The model created by this search is then used in the corresponding detection search, which identifies subsequent outliers in the number of RunInstances performed by a user in a small time window. -search: '`cloudtrail` eventName=RunInstances errorCode=success `ec2_excessive_runinstances_mltk_input_filter` +search: '`cloudtrail` eventName=RunInstances errorCode=success | bucket span=10m _time | stats count as instances_launched by _time src_user | fit DensityFunction instances_launched threshold=0.0005 into ec2_excessive_runinstances_v1' how_to_implement: 'You must install the AWS App for Splunk (version 5.1.0 or later) diff --git a/baselines/deprecated/baseline_of_excessive_aws_instances_terminated_by_user___mltk.yml b/baselines/deprecated/baseline_of_excessive_aws_instances_terminated_by_user___mltk.yml index b240865159..1643566a67 100644 --- a/baselines/deprecated/baseline_of_excessive_aws_instances_terminated_by_user___mltk.yml +++ b/baselines/deprecated/baseline_of_excessive_aws_instances_terminated_by_user___mltk.yml @@ -11,7 +11,7 @@ description: This search is used to build a Machine Learning Toolkit (MLTK) mode is then used in the corresponding detection search, which identifies subsequent outliers in the number of TerminateInstances performed by a user in a small time window. -search: '`cloudtrail` eventName=TerminateInstances errorCode=success `ec2_excessive_terminateinstances_mltk_input_filter` +search: '`cloudtrail` eventName=TerminateInstances errorCode=success | bucket span=10m _time | stats count as instances_terminated by _time src_user | fit DensityFunction instances_terminated threshold=0.0005 into ec2_excessive_terminateinstances_v1' how_to_implement: 'You must install the AWS App for Splunk (version 5.1.0 or later) diff --git a/contentctl.yml b/contentctl.yml index 9f3b502912..1aad063900 100644 --- a/contentctl.yml +++ b/contentctl.yml @@ -3,7 +3,7 @@ app: uid: 3449 title: ES Content Updates appid: DA-ESS-ContentUpdate - version: 4.33.0 + version: 4.34.0 description: Explore the Analytic Stories included with ES Content Updates. prefix: ESCU label: ESCU @@ -47,12 +47,12 @@ apps: version: 2.2.0 description: description of app hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-okta-identity-cloud_220.tgz -- uid: 6176 +- uid: 6652 title: Add-on for Linux Sysmon appid: Splunk_TA_linux_sysmon - version: 1.0.4 + version: 1.0.0 description: description of app - hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/add-on-for-linux-sysmon_104.tgz + hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/splunk-add-on-for-sysmon-for-linux_100.tgz - uid: null title: Splunk Fix XmlWinEventLog HEC Parsing appid: Splunk_FIX_XMLWINEVENTLOG_HEC_PARSING @@ -71,9 +71,9 @@ apps: - uid: 5709 title: Splunk Add-on for Sysmon appid: Splunk_TA_microsoft_sysmon - version: 4.0.0 + version: 4.0.1 description: description of app - hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-sysmon_400.tgz + hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-sysmon_401.tgz - uid: 833 title: Splunk Add-on for Unix and Linux appid: Splunk_TA_nix diff --git a/data_sources/endpoint/Sysmon_for_Linux_EventID.yml b/data_sources/endpoint/Sysmon_for_Linux_EventID.yml index 0c8155880e..096a4002b5 100644 --- a/data_sources/endpoint/Sysmon_for_Linux_EventID.yml +++ b/data_sources/endpoint/Sysmon_for_Linux_EventID.yml @@ -2,7 +2,7 @@ name: Sysmon for Linux EventID id: da9fc0c9-4b15-4537-aa91-19ca0cb1eba5 author: Patrick Bareiss, Splunk source: Syslog:Linux-Sysmon/Operational -sourcetype: sysmon_linux +sourcetype: sysmon:linux separator: EventID supported_TA: name: Splunk Add-on for Sysmon for Linux diff --git a/data_sources/endpoint/Windows_Event_Log_Security.yml b/data_sources/endpoint/Windows_Event_Log_Security.yml index 713e887a6d..46e786a697 100644 --- a/data_sources/endpoint/Windows_Event_Log_Security.yml +++ b/data_sources/endpoint/Windows_Event_Log_Security.yml @@ -1,7 +1,7 @@ name: Windows Event Log Security id: e3e44de1-57b1-462d-b57c-c7657af7ae6e author: Patrick Bareiss, Splunk -source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational +source: XmlWinEventLog:Security sourcetype: xmlwineventlog separator: EventCode supported_TA: diff --git a/data_sources/endpoint/event_sources/Windows_Event_Log_Security_5145.yml b/data_sources/endpoint/event_sources/Windows_Event_Log_Security_5145.yml index 1250a6fee1..56e69ac05f 100644 --- a/data_sources/endpoint/event_sources/Windows_Event_Log_Security_5145.yml +++ b/data_sources/endpoint/event_sources/Windows_Event_Log_Security_5145.yml @@ -91,18 +91,20 @@ field_mappings: AccessList: access_list AccessMask: access_mask AccessReason: access_result - ShareLocalPath: share_local_path RelativeTargetName: relative_target_name + ObjectType: object_type IpAddress: src_ip IpPort: src_port + SubjectDomainName: user_domain SubjectUserName: user + SubjectLogonId: user_logon_id + SubjectUserSid: user_sid ShareName: share - data_model: ocsf mapping: AccessList: access_list AccessMask: access_mask AccessReason: access_result - ShareLocalPath: file.path RelativeTargetName: file.path ObjectType: file.type IpAddress: src_endpoint.ip diff --git a/detections/application/detect_risky_spl_using_pretrained_ml_model.yml b/detections/application/detect_risky_spl_using_pretrained_ml_model.yml index 57c99e5bbe..3f2c32c442 100644 --- a/detections/application/detect_risky_spl_using_pretrained_ml_model.yml +++ b/detections/application/detect_risky_spl_using_pretrained_ml_model.yml @@ -1,18 +1,17 @@ name: Detect Risky SPL using Pretrained ML Model id: b4aefb5f-1037-410d-a149-1e091288ba33 -version: 1 -date: '2022-06-16' +version: 2 +date: '2024-05-26' author: Abhinav Mishra, Kumar Sharad, Namratha Sreekanta and Xiao Lin, Splunk status: experimental type: Anomaly -description: The following analytic uses a pretrained machine learning text classifier - to detect potentially risky commands. The model is trained independently and then - the model file is packaged within ESCU for usage. A command is deemed risky based - on the presence of certain trigger keywords, along with the context and the role - of the user (please see references). The model uses custom features to predict whether - a SPL is risky using text classification. The model takes as input the command text, - user and search type and outputs a risk score between [0,1]. A high score indicates - higher likelihood of a command being risky. This model is on-prem only. +description: The following analytic identifies potentially risky SPL commands executed + by users. It leverages a pretrained machine learning text classifier that analyzes + command text, user, and search type to assign a risk score between 0 and 1. This + detection is significant as it helps identify suspicious or unauthorized search + activities that could indicate malicious intent or misuse of the Splunk environment. + If confirmed malicious, such activity could lead to unauthorized data access, data + exfiltration, or further exploitation of the system. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search_type=adhoc @@ -62,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt + - data: + https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/email_files_written_outside_of_the_outlook_directory.yml b/detections/application/email_files_written_outside_of_the_outlook_directory.yml index c6115c3034..7360aadcfb 100644 --- a/detections/application/email_files_written_outside_of_the_outlook_directory.yml +++ b/detections/application/email_files_written_outside_of_the_outlook_directory.yml @@ -21,7 +21,7 @@ search: '| tstats `security_content_summariesonly` count values(Filesystem.file_ != "C:\\Users\\*\\My Documents\\Outlook Files\\*" Filesystem.file_path!="C:\\Users\\*\\AppData\\Local\\Microsoft\\Outlook*" by Filesystem.action Filesystem.process_id Filesystem.file_name Filesystem.dest | `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| - `email_files_written_outside_of_the_outlook_directory_filter` ' + `email_files_written_outside_of_the_outlook_directory_filter`' how_to_implement: To successfully implement this search, you must be ingesting data that records the file-system activity from your hosts to populate the Endpoint.Filesystem data model node. This is typically populated via endpoint detection-and-response diff --git a/detections/application/no_windows_updates_in_a_time_frame.yml b/detections/application/no_windows_updates_in_a_time_frame.yml index 313edec294..5eeafa902c 100644 --- a/detections/application/no_windows_updates_in_a_time_frame.yml +++ b/detections/application/no_windows_updates_in_a_time_frame.yml @@ -1,15 +1,18 @@ name: No Windows Updates in a time frame id: 1a77c08c-2f56-409c-a2d3-7d64617edd4f -version: 1 -date: '2017-09-15' +version: 2 +date: '2024-05-15' author: Bhavin Patel, Splunk status: experimental type: Hunting -description: This search looks for Windows endpoints that have not generated an event - indicating a successful Windows update in the last 60 days. Windows updates are - typically released monthly and applied shortly thereafter. An endpoint that has - not successfully applied an update in this time frame indicates the endpoint is - not regularly being patched for some reason. +description: The following analytic identifies Windows endpoints that have not generated + an event indicating a successful Windows update in the last 60 days. It leverages + the 'Update' data model in Splunk, specifically looking for the latest 'Installed' + status events from Microsoft Windows. This activity is significant for a SOC because + endpoints that are not regularly patched are vulnerable to known exploits and security + vulnerabilities. If confirmed malicious, this could indicate a compromised endpoint + that is intentionally being kept unpatched, potentially allowing attackers to exploit + unpatched vulnerabilities and gain unauthorized access or control. data_source: [] search: '| tstats `security_content_summariesonly` max(_time) as lastTime from datamodel=Updates where Updates.status=Installed Updates.vendor_product="Microsoft Windows" by Updates.dest diff --git a/detections/application/okta_authentication_failed_during_mfa_challenge.yml b/detections/application/okta_authentication_failed_during_mfa_challenge.yml index e472b275fa..6ed2871746 100644 --- a/detections/application/okta_authentication_failed_during_mfa_challenge.yml +++ b/detections/application/okta_authentication_failed_during_mfa_challenge.yml @@ -1,16 +1,32 @@ name: Okta Authentication Failed During MFA Challenge id: e2b99e7d-d956-411a-a120-2b14adfdde93 -version: 1 -date: '2024-03-11' +version: 2 +date: '2024-05-29' author: Bhavin Patel, Splunk data_source: [] type: TTP status: production -description: The following analytic identifies an authentication attempt event against - an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Authentication.app) as app values(Authentication.reason) as reason values(Authentication.signature) as signature values(Authentication.method) as method from datamodel=Authentication where Authentication.signature=user.authentication.auth_via_mfa Authentication.action = failure by _time Authentication.src Authentication.user Authentication.dest Authentication.action | `drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| iplocation src | `okta_authentication_failed_during_mfa_challenge_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: A user may have accidentally entered the wrong credentials during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. Ensure that the user is aware of the MFA process and has the correct credentials. +description: The following analytic identifies failed authentication attempts during + the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication + datamodel to detect specific failed events where the authentication signature is + `user.authentication.auth_via_mfa`. This activity is significant as it may indicate + an adversary attempting to authenticate with compromised credentials on an account + with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt + to bypass MFA protections, potentially leading to unauthorized access and further + compromise of the affected account. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(Authentication.app) as app values(Authentication.reason) as + reason values(Authentication.signature) as signature values(Authentication.method) + as method from datamodel=Authentication where Authentication.signature=user.authentication.auth_via_mfa + Authentication.action = failure by _time Authentication.src Authentication.user + Authentication.dest Authentication.action | `drop_dm_object_name("Authentication")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| iplocation + src | `okta_authentication_failed_during_mfa_challenge_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: A user may have accidentally entered the wrong credentials + during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. + Ensure that the user is aware of the MFA process and has the correct credentials. references: - https://sec.okta.com/everythingisyes - https://splunkbase.splunk.com/app/6553 @@ -55,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_mfa_login_failed/okta_mfa_login_failed.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_mfa_login_failed/okta_mfa_login_failed.log source: okta_log - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_idp_lifecycle_modifications.yml b/detections/application/okta_idp_lifecycle_modifications.yml index c14716e1b8..c59a210bbb 100644 --- a/detections/application/okta_idp_lifecycle_modifications.yml +++ b/detections/application/okta_idp_lifecycle_modifications.yml @@ -1,16 +1,31 @@ name: Okta IDP Lifecycle Modifications id: e0be2c83-5526-4219-a14f-c3db2e763d15 -version: 1 -date: '2024-03-14' +version: 2 +date: '2024-05-28' author: Bhavin Patel, Splunk data_source: [] type: Anomaly status: production -description: This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational. -search: '`okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecycle.create","system.idp.lifecycle.delete","system.idp.lifecycle.deactivate") - | stats count min(_time) as firstTime max(_time) as lastTime values(target{}.id) as target_id values(target{}.type) as target_modified by src dest src_user_id user user_agent command description | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_idp_lifecycle_modifications_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior. +description: The following analytic identifies modifications to Okta Identity Provider + (IDP) lifecycle events, including creation, activation, deactivation, and deletion + of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta + Identity Cloud. Monitoring these events is crucial for maintaining the integrity + and security of authentication mechanisms. Unauthorized or anomalous changes could + indicate potential security breaches or misconfigurations. If confirmed malicious, + attackers could manipulate authentication processes, potentially gaining unauthorized + access or disrupting identity management systems. +search: '`okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecycle.create","system.idp.lifecycle.delete","system.idp.lifecycle.deactivate") + | stats count min(_time) as firstTime max(_time) as lastTime values(target{}.id) + as target_id values(target{}.type) as target_modified by src dest src_user_id user + user_agent command description | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `okta_idp_lifecycle_modifications_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: It's possible for legitimate administrative actions or automated + processes to trigger this detection, especially if there are bulk modifications + to Okta IDP lifecycle events. Review the context of the modification, such as the + user making the change and the specific lifecycle event modified, to determine if + it aligns with expected behavior. references: - https://www.obsidiansecurity.com/blog/behind-the-breach-cross-tenant-impersonation-in-okta/ - https://splunkbase.splunk.com/app/6553 @@ -20,7 +35,8 @@ tags: asset_type: Okta Tenant confidence: 90 impact: 90 - message: A user [$user$] is attempting IDP lifecycle modification - [$description$] from IP Address - [$src$]" + message: A user [$user$] is attempting IDP lifecycle modification - [$description$] + from IP Address - [$src$]" mitre_attack_id: - T1087.004 observable: @@ -52,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/okta_idp/okta.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/okta_idp/okta.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_mfa_exhaustion_hunt.yml b/detections/application/okta_mfa_exhaustion_hunt.yml index d933d963dc..591a9b5231 100644 --- a/detections/application/okta_mfa_exhaustion_hunt.yml +++ b/detections/application/okta_mfa_exhaustion_hunt.yml @@ -1,27 +1,33 @@ name: Okta MFA Exhaustion Hunt id: 97e2fe57-3740-402c-988a-76b64ce04b8d -version: 2 -date: '2022-09-27' +version: 3 +date: '2024-05-18' author: Michael Haag, Marissa Bower, Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic identifies patterns within Okta data to determine - the amount of successful and failed pushes. Based on that, eval statements determine - a finding of whether this is suspicious or not. The events are within a window of - time and may be tuned as needed. +description: The following analytic detects patterns of successful and failed Okta + MFA push attempts to identify potential MFA exhaustion attacks. It leverages Okta + event logs, specifically focusing on push verification events, and uses statistical + evaluations to determine suspicious activity. This activity is significant as it + may indicate an attacker attempting to bypass MFA by overwhelming the user with + push notifications. If confirmed malicious, this could lead to unauthorized access, + compromising the security of the affected accounts and potentially the entire environment. data_source: [] -search: '`okta` eventType=system.push.send_factor_verify_push OR ((legacyEventType=core.user.factor.attempt_success) AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) OR ((legacyEventType=core.user.factor.attempt_fail) AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) - | stats count(eval(legacyEventType="core.user.factor.attempt_success")) as successes count(eval(legacyEventType="core.user.factor.attempt_fail")) as failures count(eval(eventType="system.push.send_factor_verify_push")) as pushes by user,_time - | stats latest(_time) as lasttime earliest(_time) as firsttime sum(successes) as successes sum(failures) as failures sum(pushes) as pushes by user - | eval seconds=lasttime-firsttime | eval lasttime=strftime(lasttime, "%c") - | search (pushes>1) - | eval totalattempts=successes+failures - | eval finding="Normal authentication pattern" - | eval finding=if(failures==pushes AND pushes>1,"Authentication attempts not successful because multiple pushes denied",finding) - | eval finding=if(totalattempts==0,"Multiple pushes sent and ignored",finding) - | eval finding=if(successes>0 AND pushes>3,"Probably should investigate. Multiple pushes sent, eventual successful authentication!",finding) - | `okta_mfa_exhaustion_hunt_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +search: '`okta` eventType=system.push.send_factor_verify_push OR ((legacyEventType=core.user.factor.attempt_success) + AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) OR ((legacyEventType=core.user.factor.attempt_fail) + AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) | stats count(eval(legacyEventType="core.user.factor.attempt_success")) as + successes count(eval(legacyEventType="core.user.factor.attempt_fail")) as failures + count(eval(eventType="system.push.send_factor_verify_push")) as pushes by user,_time + | stats latest(_time) as lasttime earliest(_time) as firsttime sum(successes) as + successes sum(failures) as failures sum(pushes) as pushes by user | eval seconds=lasttime-firsttime + | eval lasttime=strftime(lasttime, "%c") | search (pushes>1) | eval totalattempts=successes+failures + | eval finding="Normal authentication pattern" | eval finding=if(failures==pushes + AND pushes>1,"Authentication attempts not successful because multiple pushes denied",finding) + | eval finding=if(totalattempts==0,"Multiple pushes sent and ignored",finding) | + eval finding=if(successes>0 AND pushes>3,"Probably should investigate. Multiple + pushes sent, eventual successful authentication!",finding) | `okta_mfa_exhaustion_hunt_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). known_false_positives: False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete. @@ -59,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_pushes/okta_multiple_failed_mfa_pushes.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_pushes/okta_multiple_failed_mfa_pushes.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml b/detections/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml index 33e9d58c05..41b874c8bc 100644 --- a/detections/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml +++ b/detections/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml @@ -1,65 +1,46 @@ name: Okta Mismatch Between Source and Response for Verify Push Request id: 8085b79b-9b85-4e67-ad63-351c9e9a5e9a -version: 1 -date: '2023-03-17' +version: 2 +date: '2024-05-19' author: John Murphy and Jordan Ruocco, Okta, Michael Haag, Splunk type: TTP status: experimental data_source: [] -description: 'The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic. - - For each Okta Verify Push challenge, the following two events are recorded in Okta System Log - - Source of Push (Sign-In) - - eventType eq \"system.push.send_factor_verify_push\" - - User Push Response (Okta Verify client) - - eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" - - In sequence, the logic for the analytic - - - * Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) - - * Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. - * Creates a ratio of successful sign-ins to pushes. - - * If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session.' -search: '`okta` eventType IN (system.push.send_factor_verify_push) OR - (eventType IN (user.authentication.auth_via_mfa) - debugContext.debugData.factor="OKTA_VERIFY_PUSH") - | eval groupby="authenticationContext.externalSessionId" - | eval group_push_time=_time - | bin span=2s group_push_time - | fillnull value=NULL - | stats min(_time) as _time by authenticationContext.externalSessionId eventType - debugContext.debugData.factor outcome.result actor.alternateId client.device client.ipAddress - client.userAgent.rawUserAgent debugContext.debugData.behaviors group_push_time groupby - | iplocation client.ipAddress - | fields - lat, lon, group_push_time - | stats min(_time) as _time dc(client.ipAddress) as dc_ip - sum(eval(if(eventType="system.push.send_factor_verify_push" AND - "outcome.result"="SUCCESS",1,0))) as total_pushes - sum(eval(if(eventType="user.authentication.auth_via_mfa" AND - "outcome.result"="SUCCESS",1,0))) as total_successes - sum(eval(if(eventType="user.authentication.auth_via_mfa" AND - "outcome.result"="FAILURE",1,0))) as total_rejected - sum(eval(if(eventType="system.push.send_factor_verify_push" AND - "debugContext.debugData.behaviors" LIKE "%New Device=POSITIVE%",1,0))) as suspect_device_from_source - sum(eval(if(eventType="system.push.send_factor_verify_push" AND - "debugContext.debugData.behaviors" LIKE "%New IP=POSITIVE%",0,0))) as suspect_ip_from_source - values(eval(if(eventType="system.push.send_factor_verify_push","client.ipAddress",""))) as src - values(eval(if(eventType="user.authentication.auth_via_mfa","client.ipAddress",""))) as dest - values(*) as * by groupby - | eval ratio = round(total_successes/total_pushes,2) - | search ((ratio < 0.5 AND total_pushes > 1) OR (total_rejected > 0)) AND dc_ip > 1 AND - suspect_device_from_source > 0 AND suspect_ip_from_source > 0 | `okta_mismatch_between_source_and_response_for_verify_push_request_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed. +description: 'The following analytic identifies discrepancies between the source and + response events for Okta Verify Push requests, indicating potential suspicious behavior. + It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` + and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection + groups events by SessionID, calculates the ratio of successful sign-ins to push + requests, and checks for session roaming and new device/IP usage. This activity + is significant as it may indicate push spam or unauthorized access attempts. If + confirmed malicious, attackers could bypass MFA, leading to unauthorized access + to sensitive systems.' +search: '`okta` eventType IN (system.push.send_factor_verify_push) OR (eventType IN + (user.authentication.auth_via_mfa) debugContext.debugData.factor="OKTA_VERIFY_PUSH") + | eval groupby="authenticationContext.externalSessionId" | eval group_push_time=_time + | bin span=2s group_push_time | fillnull value=NULL | stats min(_time) as _time + by authenticationContext.externalSessionId eventType debugContext.debugData.factor + outcome.result actor.alternateId client.device client.ipAddress client.userAgent.rawUserAgent + debugContext.debugData.behaviors group_push_time groupby | iplocation client.ipAddress + | fields - lat, lon, group_push_time | stats min(_time) as _time dc(client.ipAddress) + as dc_ip sum(eval(if(eventType="system.push.send_factor_verify_push" AND "outcome.result"="SUCCESS",1,0))) + as total_pushes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND "outcome.result"="SUCCESS",1,0))) + as total_successes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND + "outcome.result"="FAILURE",1,0))) as total_rejected sum(eval(if(eventType="system.push.send_factor_verify_push" + AND "debugContext.debugData.behaviors" LIKE "%New Device=POSITIVE%",1,0))) as suspect_device_from_source + sum(eval(if(eventType="system.push.send_factor_verify_push" AND "debugContext.debugData.behaviors" + LIKE "%New IP=POSITIVE%",0,0))) as suspect_ip_from_source values(eval(if(eventType="system.push.send_factor_verify_push","client.ipAddress",""))) + as src values(eval(if(eventType="user.authentication.auth_via_mfa","client.ipAddress",""))) + as dest values(*) as * by groupby | eval ratio = round(total_successes/total_pushes,2) + | search ((ratio < 0.5 AND total_pushes > 1) OR (total_rejected > 0)) AND dc_ip + > 1 AND suspect_device_from_source > 0 AND suspect_ip_from_source > 0 | `okta_mismatch_between_source_and_response_for_verify_push_request_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: False positives may be present based on organization size and + configuration of Okta. Monitor, tune and filter as needed. references: - - https://attack.mitre.org/techniques/T1621 - - https://splunkbase.splunk.com/app/6553 +- https://attack.mitre.org/techniques/T1621 +- https://splunkbase.splunk.com/app/6553 tags: analytic_story: - Okta Account Takeover @@ -67,7 +48,8 @@ tags: asset_type: Okta Tenant confidence: 80 impact: 80 - message: A mismatch between source and response for verifying a push request has occurred for $actor.alternateId$ + message: A mismatch between source and response for verifying a push request has + occurred for $actor.alternateId$ mitre_attack_id: - T1621 observable: @@ -81,15 +63,15 @@ tags: - Splunk Cloud required_fields: - _time - - authenticationContext.externalSessionId + - authenticationContext.externalSessionId - eventType - - debugContext.debugData.factor - - outcome.result - - actor.alternateId - - client.device + - debugContext.debugData.factor + - outcome.result + - actor.alternateId + - client.device - client.ipAddress - - client.userAgent.rawUserAgent - - debugContext.debugData.behaviors + - client.userAgent.rawUserAgent + - debugContext.debugData.behaviors - group_push_time risk_score: 64 security_domain: access diff --git a/detections/application/okta_multi_factor_authentication_disabled.yml b/detections/application/okta_multi_factor_authentication_disabled.yml index c8ba66e58e..4f3d2badc0 100644 --- a/detections/application/okta_multi_factor_authentication_disabled.yml +++ b/detections/application/okta_multi_factor_authentication_disabled.yml @@ -1,20 +1,29 @@ name: Okta Multi-Factor Authentication Disabled id: 7c0348ce-bdf9-45f6-8a57-c18b5976f00a -version: 1 -date: '2024-03-11' +version: 2 +date: '2024-05-13' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. -search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime - from datamodel=Change where sourcetype="OktaIM2:log" All_Changes.object_category=User AND All_Changes.action=modified All_Changes.command=user.mfa.factor.deactivate by All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src - | `drop_dm_object_name("All_Changes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies an attempt to disable multi-factor + authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when + the 'user.mfa.factor.deactivate' command is executed. This activity is significant + because disabling MFA can allow an adversary to maintain persistence within the + environment using a compromised valid account. If confirmed malicious, this action + could enable attackers to bypass additional security layers, potentially leading + to unauthorized access to sensitive information and prolonged undetected presence + in the network. +search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, + min(_time) as firstTime from datamodel=Change where sourcetype="OktaIM2:log" All_Changes.object_category=User + AND All_Changes.action=modified All_Changes.command=user.mfa.factor.deactivate by + All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src + | `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multi_factor_authentication_disabled_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: Legitimate use case may require for users to disable MFA. Filter lightly and monitor for any unusual activity. +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: Legitimate use case may require for users to disable MFA. Filter + lightly and monitor for any unusual activity. references: - https://attack.mitre.org/techniques/T1556/ - https://splunkbase.splunk.com/app/6553 @@ -24,7 +33,8 @@ tags: asset_type: Okta Tenant confidence: 60 impact: 50 - message: MFA was disabled for User [$user$] initiated by [$src$]. Investigate further to determine if this was authorized. + message: MFA was disabled for User [$user$] initiated by [$src$]. Investigate further + to determine if this was authorized. mitre_attack_id: - T1556 - T1556.006 @@ -55,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/okta_mfa_method_disabled/okta_mfa_method_disabled.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/okta_mfa_method_disabled/okta_mfa_method_disabled.log source: Okta sourcetype: OktaIM2:log diff --git a/detections/application/okta_multiple_accounts_locked_out.yml b/detections/application/okta_multiple_accounts_locked_out.yml index e062706a86..7771f9cfa8 100644 --- a/detections/application/okta_multiple_accounts_locked_out.yml +++ b/detections/application/okta_multiple_accounts_locked_out.yml @@ -1,21 +1,28 @@ name: Okta Multiple Accounts Locked Out id: a511426e-184f-4de6-8711-cfd2af29d1e1 -version: 1 -date: '2024-03-06' +version: 2 +date: '2024-05-11' author: Michael Haag, Mauricio Velazco, Splunk data_source: [] type: Anomaly status: production -description: The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts. -search: '| tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime values(All_Changes.user) as user - from datamodel=Change where All_Changes.change_type=AAA All_Changes.object_category=User AND All_Changes.action=lockout AND All_Changes.command=user.account.lock by _time span=5m All_Changes.result All_Changes.command sourcetype All_Changes.src - | where count > 5 - | `drop_dm_object_name("All_Changes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `okta_multiple_accounts_locked_out_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity. +description: The following analytic detects multiple Okta accounts being locked out + within a short period. It uses the user.account.lock event from Okta logs, aggregated + over a 5-minute window, to identify this behavior. This activity is significant + as it may indicate a brute force or password spraying attack, where an adversary + attempts to guess passwords, leading to account lockouts. If confirmed malicious, + this could result in potential account takeovers or unauthorized access to sensitive + Okta accounts, posing a significant security risk. +search: '| tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) + as firstTime values(All_Changes.user) as user from datamodel=Change where All_Changes.change_type=AAA + All_Changes.object_category=User AND All_Changes.action=lockout AND All_Changes.command=user.account.lock + by _time span=5m All_Changes.result All_Changes.command sourcetype All_Changes.src + | where count > 5 | `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `okta_multiple_accounts_locked_out_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: Multiple account lockouts may be also triggered by an application + malfunction. Filter as needed, and monitor for any unusual activity. references: - https://attack.mitre.org/techniques/T1110/ - https://splunkbase.splunk.com/app/6553 @@ -25,7 +32,8 @@ tags: asset_type: Okta Tenant confidence: 70 impact: 70 - message: Multiple accounts locked out in Okta from [$src$]. Investigate further to determine if this was authorized. + message: Multiple accounts locked out in Okta from [$src$]. Investigate further + to determine if this was authorized. mitre_attack_id: - T1110 observable: @@ -55,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110/okta_multiple_accounts_lockout/okta_multiple_accounts_lockout.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110/okta_multiple_accounts_lockout/okta_multiple_accounts_lockout.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_multiple_failed_mfa_requests_for_user.yml b/detections/application/okta_multiple_failed_mfa_requests_for_user.yml index c42377fbf6..d0a539de30 100644 --- a/detections/application/okta_multiple_failed_mfa_requests_for_user.yml +++ b/detections/application/okta_multiple_failed_mfa_requests_for_user.yml @@ -1,21 +1,28 @@ name: Okta Multiple Failed MFA Requests For User id: 826dbaae-a1e6-4c8c-b384-d16898956e73 -version: 1 -date: '2024-03-05' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk data_source: [] type: Anomaly status: production -description: The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. -search: ' `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR - | bucket _time span=5m - | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) by _time src_user - | where count >= 5 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies multiple failed multi-factor authentication + (MFA) requests for a single user within an Okta tenant. It triggers when more than + 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. + This activity is significant as it may indicate an adversary attempting to bypass + MFA by bombarding the user with repeated authentication requests, a technique used + by threat actors like Lapsus and APT29. If confirmed malicious, this could lead + to unauthorized access, potentially compromising sensitive information and systems. +search: ' `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE + debugContext.debugData.factor!=PASSWORD_AS_FACTOR | bucket _time span=5m | stats + count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) + as src_ip values(debugContext.debugData.factor) by _time src_user | where count + >= 10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multiple_failed_mfa_requests_for_user_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity. +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: Multiple Failed MFA requests may also be a sign of authentication + or application issues. Filter as needed and monitor for any unusual activity. references: - https://attack.mitre.org/techniques/T1621/ tags: @@ -24,7 +31,7 @@ tags: asset_type: Okta Tenant confidence: 70 impact: 60 - message: Multiple failed MFA requests for user [$src_user$] from IP Address - [$src_ip$]. Investigate further to determine if this was authorized. + message: Multiple failed MFA requests for user $src_user$ from IP Address - $src_ip$ mitre_attack_id: - T1621 observable: @@ -53,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_requests/okta_multiple_failed_mfa_requests.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_requests/okta_multiple_failed_mfa_requests.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_multiple_failed_requests_to_access_applications.yml b/detections/application/okta_multiple_failed_requests_to_access_applications.yml index c8b3738e1e..56a07ee4db 100644 --- a/detections/application/okta_multiple_failed_requests_to_access_applications.yml +++ b/detections/application/okta_multiple_failed_requests_to_access_applications.yml @@ -1,53 +1,66 @@ name: Okta Multiple Failed Requests to Access Applications id: 1c21fed1-7000-4a2e-9105-5aaafa437247 -version: 1 -date: "2023-03-17" +version: 2 +date: "2024-05-30" author: John Murphy, Okta, Michael Haag, Splunk type: Hunting status: experimental data_source: [] -description: - 'The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows: - * Retrieves policy evaluation and SSO details in events that contain the Application requested - - * Formats target fields so we can aggregate specifically on Applications (AppInstances) - - * Groups by User, Session and IP - - * Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies - - * Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps.' -search: '`okta` target{}.type=AppInstance (eventType=policy.evaluate_sign_on outcome.result=CHALLENGE) OR (eventType=user.authentication.sso outcome.result=SUCCESS) | eval targets=mvzip(''target{}.type'', ''target{}.displayName'', ": ") | eval targets=mvfilter(targets LIKE "AppInstance%") | stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType="policy.evaluate_sign_on",targets,NULL))) as total_challenges sum(eval(if(eventType="user.authentication.sso",1,0))) as total_successes by authenticationContext.externalSessionId targets actor.alternateId client.ipAddress | search total_challenges > 0 | stats min(_time) as _time values(*) as * sum(total_challenges) as total_challenges sum(total_successes) as total_successes values(eval(if("outcome.result"="SUCCESS",targets,NULL))) as success_apps values(eval(if(":outcome.result"!="SUCCESS",targets,NULL))) as no_success_apps by authenticationContext.externalSessionId actor.alternateId client.ipAddress | fillnull | eval ratio=round(total_successes/total_challenges,2), severity="HIGH", mitre_technique_id="T1538", description="actor.alternateId". " from " . "client.ipAddress" . " seen opening " . total_challenges . " chiclets/apps with " . total_successes . " challenges successfully passed" | fields - count, targets | search ratio < 0.5 total_challenges > 2 | `okta_multiple_failed_requests_to_access_applications_filter`' -how_to_implement: This analytic is specific to Okta and requires Okta:im2 logs to be ingested. -known_false_positives: False positives may be present based on organization size and configuration of Okta. +description: 'The following analytic detects multiple failed attempts to access applications + in Okta, potentially indicating the reuse of a stolen web session cookie. It leverages + Okta logs to evaluate policy and SSO events, aggregating data by user, session, + and IP. The detection triggers when more than half of the app sign-on attempts are + unsuccessful across multiple applications. This activity is significant as it may + indicate an attempt to bypass authentication mechanisms. If confirmed malicious, + it could lead to unauthorized access to sensitive applications and data, posing + a significant security risk.' +search: '`okta` target{}.type=AppInstance (eventType=policy.evaluate_sign_on outcome.result=CHALLENGE) + OR (eventType=user.authentication.sso outcome.result=SUCCESS) | eval targets=mvzip(''target{}.type'', + ''target{}.displayName'', ": ") | eval targets=mvfilter(targets LIKE "AppInstance%") + | stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType="policy.evaluate_sign_on",targets,NULL))) + as total_challenges sum(eval(if(eventType="user.authentication.sso",1,0))) as total_successes + by authenticationContext.externalSessionId targets actor.alternateId client.ipAddress + | search total_challenges > 0 | stats min(_time) as _time values(*) as * sum(total_challenges) + as total_challenges sum(total_successes) as total_successes values(eval(if("outcome.result"="SUCCESS",targets,NULL))) + as success_apps values(eval(if(":outcome.result"!="SUCCESS",targets,NULL))) as no_success_apps + by authenticationContext.externalSessionId actor.alternateId client.ipAddress | + fillnull | eval ratio=round(total_successes/total_challenges,2), severity="HIGH", + mitre_technique_id="T1538", description="actor.alternateId". " from " . "client.ipAddress" + . " seen opening " . total_challenges . " chiclets/apps with " . total_successes + . " challenges successfully passed" | fields - count, targets | search ratio < 0.5 + total_challenges > 2 | `okta_multiple_failed_requests_to_access_applications_filter`' +how_to_implement: This analytic is specific to Okta and requires Okta:im2 logs to + be ingested. +known_false_positives: False positives may be present based on organization size and + configuration of Okta. references: - - https://attack.mitre.org/techniques/T1538 - - https://attack.mitre.org/techniques/T1550/004 +- https://attack.mitre.org/techniques/T1538 +- https://attack.mitre.org/techniques/T1550/004 tags: analytic_story: - - Okta Account Takeover + - Okta Account Takeover asset_type: Okta Tenant confidence: 70 impact: 80 message: Multiple Failed Requests to Access Applications via Okta for $actor.alternateId$. mitre_attack_id: - - T1550.004 - - T1538 + - T1550.004 + - T1538 observable: - - name: actor.alternateId - type: User - role: - - Victim + - name: actor.alternateId + type: User + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - authenticationContext.externalSessionId - - targets - - actor.alternateId - - client.ipAddress - - eventType + - _time + - authenticationContext.externalSessionId + - targets + - actor.alternateId + - client.ipAddress + - eventType risk_score: 56 security_domain: access diff --git a/detections/application/okta_multiple_users_failing_to_authenticate_from_ip.yml b/detections/application/okta_multiple_users_failing_to_authenticate_from_ip.yml index 838e1aa5c1..6c457c5bd9 100644 --- a/detections/application/okta_multiple_users_failing_to_authenticate_from_ip.yml +++ b/detections/application/okta_multiple_users_failing_to_authenticate_from_ip.yml @@ -1,21 +1,30 @@ name: Okta Multiple Users Failing To Authenticate From Ip id: de365ffa-42f5-46b5-b43f-fa72290b8218 -version: 1 -date: '2024-03-06' +version: 2 +date: '2024-05-28' author: Michael Haag, Mauricio Velazco, Splunk data_source: [] type: Anomaly status: production -description: This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts. -search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime dc(Authentication.user) as unique_accounts values(Authentication.signature) as signature values(Authentication.user) as user values(Authentication.app) as app values(Authentication.authentication_method) as authentication_method - from datamodel=Authentication where Authentication.action="failure" AND Authentication.signature=user.session.start by _time span=5m Authentication.src sourcetype - | where unique_accounts > 9 - | `drop_dm_object_name("Authentication")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `okta_multiple_users_failing_to_authenticate_from_ip_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. +description: The following analytic identifies instances where more than 10 unique + user accounts have failed to authenticate from a single IP address within a 5-minute + window in an Okta tenant. This detection uses OktaIm2 logs ingested via the Splunk + Add-on for Okta Identity Cloud. Such activity is significant as it may indicate + brute-force attacks or password spraying attempts. If confirmed malicious, this + behavior suggests an external entity is attempting to compromise multiple user accounts, + potentially leading to unauthorized access to organizational resources and data + breaches. +search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, + min(_time) as firstTime dc(Authentication.user) as unique_accounts values(Authentication.signature) + as signature values(Authentication.user) as user values(Authentication.app) as app + values(Authentication.authentication_method) as authentication_method from datamodel=Authentication + where Authentication.action="failure" AND Authentication.signature=user.session.start + by _time span=5m Authentication.src sourcetype | where unique_accounts > 9 | `drop_dm_object_name("Authentication")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multiple_users_failing_to_authenticate_from_ip_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: A source Ip failing to authenticate with multiple users in + a short period of time is not common legitimate behavior. references: - https://attack.mitre.org/techniques/T1110/003/ - https://splunkbase.splunk.com/app/6553 @@ -25,7 +34,8 @@ tags: asset_type: Okta Tenant confidence: 90 impact: 60 - message: Multiple users failing to authenticate from a single source IP Address - [$src$]. Investigate further to determine if this was authorized. + message: Multiple users failing to authenticate from a single source IP Address + - [$src$]. Investigate further to determine if this was authorized. mitre_attack_id: - T1110.003 observable: @@ -55,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/okta_multiple_users_from_ip/okta_multiple_users_from_ip.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/okta_multiple_users_from_ip/okta_multiple_users_from_ip.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_new_api_token_created.yml b/detections/application/okta_new_api_token_created.yml index 4d99a43f7e..9d6a299dd2 100644 --- a/detections/application/okta_new_api_token_created.yml +++ b/detections/application/okta_new_api_token_created.yml @@ -1,19 +1,27 @@ name: Okta New API Token Created id: c3d22720-35d3-4da4-bd0a-740d37192bd4 -version: 2 -date: '2022-09-21' +version: 3 +date: '2024-05-11' author: Michael Haag, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts. +description: The following analytic detects the creation of a new API token within + an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity + Cloud to identify events where the `system.api_token.create` command is executed. + This activity is significant because creating a new API token can indicate potential + account takeover attempts or unauthorized access, allowing an adversary to maintain + persistence. If confirmed malicious, this could enable attackers to execute API + calls, access sensitive data, and perform administrative actions within the Okta + environment. data_source: [] -search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime - from datamodel=Change where All_Changes.action=created AND All_Changes.command=system.api_token.create by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category - | `drop_dm_object_name("All_Changes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, + min(_time) as firstTime from datamodel=Change where All_Changes.action=created AND + All_Changes.command=system.api_token.create by _time span=5m All_Changes.user All_Changes.result + All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category + | `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_new_api_token_created_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). known_false_positives: False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. references: @@ -25,7 +33,8 @@ tags: asset_type: Okta Tenant confidence: 80 impact: 80 - message: A new API token was created in Okta by [$user$]. Investigate further to determine if this was authorized. + message: A new API token was created in Okta by [$user$]. Investigate further to + determine if this was authorized. mitre_attack_id: - T1078 - T1078.001 @@ -56,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/okta_new_api_token_created/okta_new_api_token_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/okta_new_api_token_created/okta_new_api_token_created.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_new_device_enrolled_on_account.yml b/detections/application/okta_new_device_enrolled_on_account.yml index cfe8636792..8d19286783 100644 --- a/detections/application/okta_new_device_enrolled_on_account.yml +++ b/detections/application/okta_new_device_enrolled_on_account.yml @@ -1,20 +1,28 @@ name: Okta New Device Enrolled on Account id: bb27cbce-d4de-432c-932f-2e206e9130fb -version: 2 -date: '2024-03-08' +version: 3 +date: '2024-05-24' author: Michael Haag, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts. +description: The following analytic identifies when a new device is enrolled on an + Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity + Cloud to detect the creation of new device enrollments. This activity is significant + as it may indicate a legitimate user setting up a new device or an adversary adding + a device to maintain unauthorized access. If confirmed malicious, this could lead + to potential account takeover, unauthorized access, and persistent control over + the compromised Okta account. Monitoring this behavior is crucial for detecting + and mitigating unauthorized access attempts. data_source: [] -search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime - from datamodel=Change where All_Changes.action=created All_Changes.command=device.enrollment.create by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category - | `drop_dm_object_name("All_Changes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `okta_new_device_enrolled_on_account_filter`' -how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: It is possible that the user has legitimately added a new device to their account. Please verify this activity. +search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, + min(_time) as firstTime from datamodel=Change where All_Changes.action=created All_Changes.command=device.enrollment.create + by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype + All_Changes.src All_Changes.action All_Changes.object_category | `drop_dm_object_name("All_Changes")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_new_device_enrolled_on_account_filter`' +how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the + Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: It is possible that the user has legitimately added a new device + to their account. Please verify this activity. references: - https://attack.mitre.org/techniques/T1098/005/ - https://developer.okta.com/docs/reference/api/event-types/?q=device.enrollment.create @@ -24,7 +32,8 @@ tags: asset_type: Okta Tenant confidence: 60 impact: 40 - message: A new device was enrolled on an Okta account for user [$user$]. Investigate further to determine if this was authorized. + message: A new device was enrolled on an Okta account for user [$user$]. Investigate + further to determine if this was authorized. mitre_attack_id: - T1098 - T1098.005 @@ -51,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/okta_new_device_enrolled/okta_new_device_enrolled.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/okta_new_device_enrolled/okta_new_device_enrolled.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_phishing_detection_with_fastpass_origin_check.yml b/detections/application/okta_phishing_detection_with_fastpass_origin_check.yml index dcbdfc9493..ee78e21364 100644 --- a/detections/application/okta_phishing_detection_with_fastpass_origin_check.yml +++ b/detections/application/okta_phishing_detection_with_fastpass_origin_check.yml @@ -1,20 +1,28 @@ name: Okta Phishing Detection with FastPass Origin Check id: f4ca0057-cbf3-44f8-82ea-4e330ee901d3 -version: 1 -date: '2023-03-09' +version: 2 +date: '2024-05-15' author: Okta, Inc, Michael Haag, Splunk type: TTP status: experimental data_source: [] -description: The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. - Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers. -search: '`okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE" AND outcome.reason="FastPass declined phishing attempt" -| stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) by user eventType client.userAgent.rawUserAgent client.userAgent.browser outcome.reason -| `security_content_ctime(firstTime)` -| `security_content_ctime(lastTime)` | `okta_phishing_detection_with_fastpass_origin_check_filter`' -how_to_implement: This search is specific to Okta and requires Okta logs to be - ingested in your Splunk deployment. -known_false_positives: Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed. +description: The following analytic identifies failed user authentication attempts + in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically + looking for events where multi-factor authentication (MFA) fails with the reason + "FastPass declined phishing attempt." This activity is significant as it indicates + that attackers are targeting users with real-time phishing proxies, attempting to + capture credentials. If confirmed malicious, this could lead to unauthorized access + to user accounts, potentially compromising sensitive information and furthering + lateral movement within the organization. +search: '`okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE" + AND outcome.reason="FastPass declined phishing attempt" | stats count min(_time) + as firstTime max(_time) as lastTime values(displayMessage) by user eventType client.userAgent.rawUserAgent + client.userAgent.browser outcome.reason | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `okta_phishing_detection_with_fastpass_origin_check_filter`' +how_to_implement: This search is specific to Okta and requires Okta logs to be ingested + in your Splunk deployment. +known_false_positives: Fidelity of this is high as Okta is specifying malicious infrastructure. + Filter and modify as needed. references: - https://sec.okta.com/fastpassphishingdetection tags: @@ -39,9 +47,9 @@ tags: - Splunk Cloud required_fields: - _time - - eventType - - client.userAgent.rawUserAgent - - client.userAgent.browser + - eventType + - client.userAgent.rawUserAgent + - client.userAgent.browser - outcome.reason - displayMessage risk_score: 100 diff --git a/detections/application/okta_risk_threshold_exceeded.yml b/detections/application/okta_risk_threshold_exceeded.yml index bbb9eebef3..314de0f5d4 100644 --- a/detections/application/okta_risk_threshold_exceeded.yml +++ b/detections/application/okta_risk_threshold_exceeded.yml @@ -1,57 +1,78 @@ name: Okta Risk Threshold Exceeded id: d8b967dd-657f-4d88-93b5-c588bcd7218c -version: 2 -date: "2024-04-02" +version: 3 +date: "2024-05-28" author: Michael Haag, Bhavin Patel, Splunk status: production type: Correlation -description: - This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user. +description: The following correlation identifies when a user exceeds a risk threshold + based on multiple suspicious Okta activities. It leverages the Risk Framework from + Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta + Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is + significant as it highlights potentially compromised user accounts exhibiting multiple + tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed + malicious, this activity could indicate a serious security breach, allowing attackers + to gain unauthorized access, escalate privileges, or persist within the environment. data_source: [] -search: - '| tstats `security_content_summariesonly` values(All_Risk.analyticstories) as analyticstories 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 All_Risk.risk_object_type = user All_Risk.analyticstories IN ("Okta Account Takeover", "Suspicious Okta Activity","Okta MFA Exhaustion") by All_Risk.risk_object,All_Risk.risk_object_type | `drop_dm_object_name("All_Risk")` | search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`' -how_to_implement: - This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories are enabled. TTPs may be set to Notables for point detections; anomalies should not be notables but rather risk generators. The correlation relies on risk before generating a notable. Modify the value as needed. -known_false_positives: - False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization. +search: '| tstats `security_content_summariesonly` values(All_Risk.analyticstories) + as analyticstories 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 All_Risk.risk_object_type + = user All_Risk.analyticstories IN ("Okta Account Takeover", "Suspicious Okta Activity","Okta + MFA Exhaustion") by All_Risk.risk_object,All_Risk.risk_object_type | `drop_dm_object_name("All_Risk")` + | search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`' +how_to_implement: This search leverages the Risk Framework from Enterprise Security. + Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" + analytic stories are enabled. TTPs may be set to Notables for point detections; + anomalies should not be notables but rather risk generators. The correlation relies + on risk before generating a notable. Modify the value as needed. +known_false_positives: False positives will be limited to the number of events generated + by the analytics tied to the stories. Analytics will need to be tested and tuned, + and the risk score reduced as needed based on the organization. references: - - https://developer.okta.com/docs/reference/api/event-types - - https://sec.okta.com/everythingisyes +- https://developer.okta.com/docs/reference/api/event-types +- https://sec.okta.com/everythingisyes tags: analytic_story: - - Okta Account Takeover - - Okta MFA Exhaustion - - Suspicious Okta Activity + - Okta Account Takeover + - Okta MFA Exhaustion + - Suspicious Okta Activity asset_type: Okta Tenant confidence: 80 impact: 70 - message: Okta Risk threshold exceeded for user [$risk_object$]. Investigate further to determine if this was authorized. + message: Okta Risk threshold exceeded for user [$risk_object$]. Investigate further + to determine if this was authorized. mitre_attack_id: - - T1078 - - T1110 + - T1078 + - T1110 observable: - - name: risk_object - type: User - role: - - Victim + - name: risk_object + type: User + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - All_Risk.risk_object - - All_Risk.risk_object_type - - All_Risk.analyticstories - - All_Risk.calculated_risk_score - - All_Risk.annotations.mitre_attack.mitre_tactic_id - - All_Risk.annotations.mitre_attack.mitre_technique_id - - All_Risk.tag - - _time + - All_Risk.risk_object + - All_Risk.risk_object_type + - All_Risk.analyticstories + - All_Risk.calculated_risk_score + - All_Risk.annotations.mitre_attack.mitre_tactic_id + - All_Risk.annotations.mitre_attack.mitre_technique_id + - All_Risk.tag + - _time risk_score: 56 security_domain: access tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/okta_account_takeover_risk_events/okta_risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/okta_account_takeover_risk_events/okta_risk.log source: risk_data - sourcetype: stash \ No newline at end of file + sourcetype: stash diff --git a/detections/application/okta_successful_single_factor_authentication.yml b/detections/application/okta_successful_single_factor_authentication.yml index b830aedc19..02d48dae21 100644 --- a/detections/application/okta_successful_single_factor_authentication.yml +++ b/detections/application/okta_successful_single_factor_authentication.yml @@ -1,17 +1,29 @@ name: Okta Successful Single Factor Authentication id: 98f6ad4f-4325-4096-9d69-45dc8e638e82 -version: 1 -date: '2024-04-08' +version: 2 +date: '2024-05-26' author: Bhavin Patel, Splunk data_source: [] type: Anomaly status: production -description: This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search. -search: '`okta` action=success src_user_type = User eventType = user.authentication.verify OR eventType = user.authentication.auth_via_mfa| stats dc(eventType) values(eventType) as eventType values(target{}.displayName) as targets values(debugContext.debugData.url) min(_time) as firstTime max(_time) as lastTime values(authentication_method) by src_ip user action - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | search targets !="Okta Verify" | `okta_successful_single_factor_authentication_filter`' -how_to_implement: This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary. +description: The following analytic identifies successful single-factor authentication + events against the Okta Dashboard for accounts without Multi-Factor Authentication + (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication + events where "Okta Verify" is not used. This behavior is significant as it may indicate + a misconfiguration, policy violation, or potential account takeover. If confirmed + malicious, an attacker could gain unauthorized access to the account, potentially + leading to data breaches or further exploitation within the environment. +search: '`okta` action=success src_user_type = User eventType = user.authentication.verify + OR eventType = user.authentication.auth_via_mfa| stats dc(eventType) values(eventType) + as eventType values(target{}.displayName) as targets values(debugContext.debugData.url) + min(_time) as firstTime max(_time) as lastTime values(authentication_method) by + src_ip user action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | search targets !="Okta Verify" | `okta_successful_single_factor_authentication_filter`' +how_to_implement: This detection utilizes logs from Okta environments and requires + the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud + (https://splunkbase.splunk.com/app/6553). +known_false_positives: Although not recommended, certain users may be exempt from + multi-factor authentication. Adjust the filter as necessary. references: - https://sec.okta.com/everythingisyes - https://attack.mitre.org/techniques/T1078/004/ @@ -21,7 +33,8 @@ tags: asset_type: Okta Tenant confidence: 60 impact: 80 - message: A user [$user$] has successfully logged in to Okta Dashboard with single factor authentication from IP Address - [$src_ip$]. + message: A user [$user$] has successfully logged in to Okta Dashboard with single + factor authentication from IP Address - [$src_ip$]. mitre_attack_id: - T1586 - T1586.003 @@ -53,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_single_factor_auth/okta_single_factor_auth.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_single_factor_auth/okta_single_factor_auth.log source: okta_log - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_suspicious_use_of_a_session_cookie.yml b/detections/application/okta_suspicious_use_of_a_session_cookie.yml index 005ca8297d..9e144bfc6e 100644 --- a/detections/application/okta_suspicious_use_of_a_session_cookie.yml +++ b/detections/application/okta_suspicious_use_of_a_session_cookie.yml @@ -1,31 +1,34 @@ name: Okta Suspicious Use of a Session Cookie id: 71ad47d1-d6bd-4e0a-b35c-020ad9a6959e -version: 2 -date: '2024-03-17' +version: 3 +date: '2024-05-29' author: Scott Dermott, Felicity Robson, Okta, Michael Haag, Bhavin Patel, Splunk type: Anomaly status: production data_source: [] -description: 'The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. A detection opportunity arises when an adversary attempts to reuse a stolen web session cookie. - - * Retrieves policy evaluation events from successful authentication events. - - * Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window. - - * It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination.' -search: '`okta` eventType IN (policy.evaluate_sign_on) outcome.result IN - (ALLOW, SUCCESS) | stats earliest(_time) as _time, values(client.ipAddress) as src_ip, - values(client.userAgent.rawUserAgent) as user_agent, values(client.userAgent.os) as - userAgentOS_list, values(client.geographicalContext.city) as city, values(client.userAgent.browser) as userAgentBrowser_list, - values(device.os_platform) as okta_device_os, dc(client.userAgent.browser) as dc_userAgentBrowser, - dc(client.userAgent.os) as dc_userAgentOS, dc(client.ipAddress) as dc_src_ip, - values(outcome.reason) as reason by debugContext.debugData.dtHash, user - | where dc_src_ip>1 AND (dc_userAgentOS>1 OR dc_userAgentBrowser>1) - | `okta_suspicious_use_of_a_session_cookie_filter`' -how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: False positives may occur, depending on the organization's size and the configuration of Okta. +description: 'The following analytic identifies suspicious use of a session cookie + by detecting multiple client values (IP, User Agent, etc.) changing for the same + Device Token associated with a specific user. It leverages policy evaluation events + from successful authentication logs in Okta. This activity is significant as it + may indicate an adversary attempting to reuse a stolen web session cookie, potentially + bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized + access to user accounts, leading to data breaches or further exploitation within + the environment.' +search: '`okta` eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, SUCCESS) + | stats earliest(_time) as _time, values(client.ipAddress) as src_ip, values(client.userAgent.rawUserAgent) + as user_agent, values(client.userAgent.os) as userAgentOS_list, values(client.geographicalContext.city) + as city, values(client.userAgent.browser) as userAgentBrowser_list, values(device.os_platform) + as okta_device_os, dc(client.userAgent.browser) as dc_userAgentBrowser, dc(client.userAgent.os) + as dc_userAgentOS, dc(client.ipAddress) as dc_src_ip, values(outcome.reason) as + reason by debugContext.debugData.dtHash, user | where dc_src_ip>1 AND (dc_userAgentOS>1 + OR dc_userAgentBrowser>1) | `okta_suspicious_use_of_a_session_cookie_filter`' +how_to_implement: This detection utilizes logs from Okta Identity Management (IM) + environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on + for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: False positives may occur, depending on the organization's + size and the configuration of Okta. references: - - https://attack.mitre.org/techniques/T1539/ +- https://attack.mitre.org/techniques/T1539/ tags: analytic_story: - Suspicious Okta Activity @@ -33,7 +36,8 @@ tags: asset_type: Okta Tenant confidence: 70 impact: 80 - message: A user [$user$] is attempting to use a session cookie from multiple IP addresses or devices. Investigate further to determine if this was authorized. + message: A user [$user$] is attempting to use a session cookie from multiple IP + addresses or devices. Investigate further to determine if this was authorized. mitre_attack_id: - T1539 observable: @@ -60,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1539/okta_web_session_multiple_ip/okta_web_session_multiple_ip.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1539/okta_web_session_multiple_ip/okta_web_session_multiple_ip.log source: Okta sourcetype: OktaIM2:log diff --git a/detections/application/okta_threatinsight_threat_detected.yml b/detections/application/okta_threatinsight_threat_detected.yml index 9a1e594d06..77a959649f 100644 --- a/detections/application/okta_threatinsight_threat_detected.yml +++ b/detections/application/okta_threatinsight_threat_detected.yml @@ -1,20 +1,29 @@ name: Okta ThreatInsight Threat Detected id: 140504ae-5fe2-4d65-b2bc-a211813fbca6 -version: 2 -date: '2022-09-21' +version: 3 +date: '2024-05-21' author: Michael Haag, Mauricio Velazco, Splunk status: production type: Anomaly -description: This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users. +description: The following analytic identifies threats detected by Okta ThreatInsight, + such as password spraying, login failures, and high counts of unknown user login + attempts. It leverages Okta Identity Management logs, specifically focusing on security.threat.detected + events. This activity is significant for a SOC as it highlights potential unauthorized + access attempts and credential-based attacks. If confirmed malicious, these activities + could lead to unauthorized access, data breaches, and further exploitation of compromised + accounts, posing a significant risk to the organization's security posture. data_source: [] -search: '`okta` eventType = security.threat.detected - | rename client.geographicalContext.country as country, client.geographicalContext.state as state, client.geographicalContext.city as city - | stats count min(_time) as firstTime max(_time) as lastTime by app src_ip signature eventType displayMessage client.device city state country user_agent outcome.reason outcome.result severity - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`okta` eventType = security.threat.detected | rename client.geographicalContext.country + as country, client.geographicalContext.state as state, client.geographicalContext.city + as city | stats count min(_time) as firstTime max(_time) as lastTime by app src_ip + signature eventType displayMessage client.device city state country user_agent outcome.reason + outcome.result severity | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_threatinsight_threat_detected_filter`' -how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: False positives may occur. It is recommended to fine-tune Okta settings and the analytic to ensure high fidelity. Adjust the risk score as necessary. +how_to_implement: This detection utilizes logs from Okta Identity Management (IM) + environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on + for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: False positives may occur. It is recommended to fine-tune Okta + settings and the analytic to ensure high fidelity. Adjust the risk score as necessary. references: - https://developer.okta.com/docs/reference/api/event-types/?q=security.threat.detected tags: @@ -23,7 +32,8 @@ tags: asset_type: Infrastructure confidence: 50 impact: 50 - message: The following $src_ip$ has been identified as a threat by Okta ThreatInsight. Investigate further to determine if this was authorized. + message: The following $src_ip$ has been identified as a threat by Okta ThreatInsight. + Investigate further to determine if this was authorized. mitre_attack_id: - T1078 - T1078.004 @@ -58,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_threatinsight_threat_detected/okta_threatinsight_threat_detected.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_threatinsight_threat_detected/okta_threatinsight_threat_detected.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_unauthorized_access_to_application.yml b/detections/application/okta_unauthorized_access_to_application.yml index 2293135bb0..9f94ca1140 100644 --- a/detections/application/okta_unauthorized_access_to_application.yml +++ b/detections/application/okta_unauthorized_access_to_application.yml @@ -1,19 +1,30 @@ name: Okta Unauthorized Access to Application id: 5f661629-9750-4cb9-897c-1f05d6db8727 -version: 1 -date: '2024-03-07' +version: 2 +date: '2024-05-12' author: 'Bhavin Patel, Splunk' data_source: [] type: Anomaly status: production -description: This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment. -search: '| tstats values(Authentication.app) as app values(Authentication.action) as action values(Authentication.user) as user values(Authentication.reason) as reason from datamodel=Authentication where Authentication.signature=app.generic.unauth_app_access_attempt Authentication.action="failure" by _time Authentication.src Authentication.user - | `drop_dm_object_name("Authentication")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | iplocation src | `okta_unauthorized_access_to_application_filter`' -how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: There is a possibility that a user may accidentally click on the wrong application, which could trigger this event. It is advisable to verify the location from which this activity originates. +description: The following analytic identifies attempts by users to access Okta applications + that have not been assigned to them. It leverages Okta Identity Management logs, + specifically focusing on failed access attempts to unassigned applications. This + activity is significant for a SOC as it may indicate potential unauthorized access + attempts, which could lead to exposure of sensitive information or disruption of + services. If confirmed malicious, such activity could result in data breaches, non-compliance + with data protection laws, and overall compromise of the IT environment. +search: '| tstats values(Authentication.app) as app values(Authentication.action) + as action values(Authentication.user) as user values(Authentication.reason) as reason + from datamodel=Authentication where Authentication.signature=app.generic.unauth_app_access_attempt + Authentication.action="failure" by _time Authentication.src Authentication.user + | `drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | iplocation src | `okta_unauthorized_access_to_application_filter`' +how_to_implement: This detection utilizes logs from Okta Identity Management (IM) + environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on + for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: There is a possibility that a user may accidentally click on + the wrong application, which could trigger this event. It is advisable to verify + the location from which this activity originates. references: - https://attack.mitre.org/techniques/T1110/003/ tags: @@ -22,7 +33,8 @@ tags: asset_type: Okta Tenant confidence: 90 impact: 90 - message: A user [$user$] is attempting to access an unauthorized application from IP Address - [$src$] + message: A user [$user$] is attempting to access an unauthorized application from + IP Address - [$src$] mitre_attack_id: - T1087.004 observable: @@ -53,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.004/okta_unauth_access/okta_unauth_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.004/okta_unauth_access/okta_unauth_access.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/okta_user_logins_from_multiple_cities.yml b/detections/application/okta_user_logins_from_multiple_cities.yml index 68549fb6a6..adefdd2cae 100644 --- a/detections/application/okta_user_logins_from_multiple_cities.yml +++ b/detections/application/okta_user_logins_from_multiple_cities.yml @@ -1,21 +1,34 @@ name: Okta User Logins from Multiple Cities id: a3d1df37-c2a9-41d0-aa8f-59f82d6192a8 -version: 1 -date: '2024-03-07' +version: 2 +date: '2024-05-09' author: 'Bhavin Patel, Splunk' data_source: [] type: Anomaly status: production -description: This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches. -search: '| tstats `security_content_summariesonly` values(Authentication.app) as app values(Authentication.action) as action values(Authentication.user) as user values(Authentication.reason) as reason values(Authentication.dest) as dest values(Authentication.signature) as signature values(Authentication.method) as method from datamodel=Authentication where Authentication.signature=user.session.start by _time Authentication.src - | `drop_dm_object_name("Authentication")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | iplocation src - | stats count min(_time) as firstTime max(_time) as lastTime dc(src) as distinct_src dc(City) as distinct_city values(src) as src values(City) as City values(Country) as Country values(action) as action by user - | where distinct_city > 1 | `okta_user_logins_from_multiple_cities_filter`' -how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). -known_false_positives: It is uncommon for a user to log in from multiple cities simultaneously, which may indicate a false positive. +description: The following analytic identifies instances where the same Okta user + logs in from different cities within a 24-hour period. This detection leverages + Okta Identity Management logs, analyzing login events and their geographic locations. + Such behavior is significant as it may indicate a compromised account, with an attacker + attempting unauthorized access from multiple locations. If confirmed malicious, + this activity could lead to account takeovers and data breaches, allowing attackers + to access sensitive information and potentially escalate their privileges within + the environment. +search: '| tstats `security_content_summariesonly` values(Authentication.app) as + app values(Authentication.action) as action values(Authentication.user) as user + values(Authentication.reason) as reason values(Authentication.dest) as dest values(Authentication.signature) + as signature values(Authentication.method) as method from datamodel=Authentication + where Authentication.signature=user.session.start by _time Authentication.src | + `drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | iplocation src | stats count min(_time) as + firstTime max(_time) as lastTime dc(src) as distinct_src dc(City) as distinct_city + values(src) as src values(City) as City values(Country) as Country values(action) + as action by user | where distinct_city > 1 | `okta_user_logins_from_multiple_cities_filter`' +how_to_implement: This detection utilizes logs from Okta Identity Management (IM) + environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on + for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). +known_false_positives: It is uncommon for a user to log in from multiple cities simultaneously, + which may indicate a false positive. references: - https://attack.mitre.org/techniques/T1110/003/ tags: @@ -24,7 +37,8 @@ tags: asset_type: Okta Tenant confidence: 90 impact: 90 - message: A user [$user$] has logged in from multiple cities [$City$] from IP Address - [$src$]. Investigate further to determine if this was authorized. + message: A user [$user$] has logged in from multiple cities [$City$] from IP Address + - [$src$]. Investigate further to determine if this was authorized. mitre_attack_id: - T1586.003 observable: @@ -55,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/okta_multiple_city/okta_multiple_city_im2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/okta_multiple_city/okta_multiple_city_im2.log source: Okta - sourcetype: OktaIM2:log \ No newline at end of file + sourcetype: OktaIM2:log diff --git a/detections/application/path_traversal_spl_injection.yml b/detections/application/path_traversal_spl_injection.yml index e0baa0efff..7f112a5d53 100644 --- a/detections/application/path_traversal_spl_injection.yml +++ b/detections/application/path_traversal_spl_injection.yml @@ -1,15 +1,19 @@ name: Path traversal SPL injection id: dfe55688-82ed-4d24-a21b-ed8f0e0fda99 -version: 2 -date: '2024-03-19' +version: 3 +date: '2024-05-26' author: Rod Soto, Splunk status: production type: TTP -description: On May 3rd, 2022, Splunk published a security advisory for a Path traversal - in search parameter that can potentiall allow SPL injection. An attacker can cause - the application to load data from incorrect endpoints, urls leading to outcomes - such as running arbitrary SPL queries. -data_source: +description: The following analytic identifies attempts at path traversal in search + parameters, which can lead to SPL injection. It detects this activity by searching + for specific patterns in the `_internal` index that indicate path traversal attempts + (e.g., "../../../../"). This activity is significant for a SOC because it can allow + an attacker to manipulate the application to load data from incorrect endpoints, + potentially running arbitrary SPL queries. If confirmed malicious, this could lead + to unauthorized data access, code execution, or further exploitation of the Splunk + environment. +data_source: - Splunk search: ' `path_traversal_spl_injection` | search "\/..\/..\/..\/..\/..\/..\/..\/..\/..\/" | stats count by host status clientip method uri_path uri_query | `path_traversal_spl_injection_filter`' @@ -57,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/path_traversal_spl_injection.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/path_traversal_spl_injection.txt source: splunkd_ui_access.log sourcetype: splunkd_ui_access custom_index: _internal diff --git a/detections/application/persistent_xss_in_rapiddiag_through_user_interface_views.yml b/detections/application/persistent_xss_in_rapiddiag_through_user_interface_views.yml index 7de1a67049..8b68f351f7 100644 --- a/detections/application/persistent_xss_in_rapiddiag_through_user_interface_views.yml +++ b/detections/application/persistent_xss_in_rapiddiag_through_user_interface_views.yml @@ -1,57 +1,68 @@ name: Persistent XSS in RapidDiag through User Interface Views id: ce6e1268-e01c-4df2-a617-0f034ed49a43 -version: 1 -date: "2023-02-14" +version: 2 +date: "2024-05-24" author: Rod Soto, Splunk type: TTP status: production -data_source: +data_source: - Splunk -description: In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it. -search: - "`audit_searches` path=/opt/splunk/etc/users/*/search/local/data/ui/views/* +description: The following analytic identifies potential persistent Cross-Site Scripting + (XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface + views. It leverages audit logs from the `audit_searches` data source to detect actions + involving Base64-encoded images in error messages. This activity is significant + because it can allow attackers to inject malicious scripts that execute in the context + of other users, leading to unauthorized actions or data exposure. If confirmed malicious, + this could result in persistent control over the affected Splunk instance, compromising + its integrity and confidentiality. +search: "`audit_searches` path=/opt/splunk/etc/users/*/search/local/data/ui/views/* action=* |table user action roles info roles path | dedup user action | `persistent_xss_in_rapiddiag_through_user_interface_views_filter`" -how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index -known_false_positives: This is a hunting search, it will not deobfuscate base64 payload, it provides however it will provide what user added the view artifact and what user opened it. It will require further investigation based on the information presented by this hunting search. +how_to_implement: This detection does not require you to ingest any new data. The + detection does require the ability to search the _internal index +known_false_positives: This is a hunting search, it will not deobfuscate base64 payload, + it provides however it will provide what user added the view artifact and what user + opened it. It will require further investigation based on the information presented + by this hunting search. references: - - https://www.splunk.com/en_us/product-security.html +- https://www.splunk.com/en_us/product-security.html tags: analytic_story: - - Splunk Vulnerabilities + - Splunk Vulnerabilities asset_type: Endpoint cve: - - CVE-2023-22932 + - CVE-2023-22932 confidence: 50 context: - - Source:Endpoint + - Source:Endpoint dataset: - - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log impact: 50 message: A potential XSS attempt has been detected from $user$ mitre_attack_id: - - T1189 + - T1189 observable: - - name: user - type: User - role: - - Victim + - name: user + type: User + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - user - - action - - roles - - info - - roles - - path + - user + - action + - roles + - info + - roles + - path risk_score: 25 security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log source: audittrail sourcetype: audittrail - custom_index: _audit \ No newline at end of file + custom_index: _audit diff --git a/detections/application/pingid_mismatch_auth_source_and_verification_response.yml b/detections/application/pingid_mismatch_auth_source_and_verification_response.yml index 9488771f5f..19b718cce0 100644 --- a/detections/application/pingid_mismatch_auth_source_and_verification_response.yml +++ b/detections/application/pingid_mismatch_auth_source_and_verification_response.yml @@ -1,17 +1,42 @@ name: PingID Mismatch Auth Source and Verification Response id: 15b0694e-caa2-4009-8d83-a1f98b86d086 -version: 1 -date: '2023-09-26' +version: 2 +date: '2024-05-22' author: Steven Dick status: production type: TTP -description: The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country. +description: The following analytic identifies discrepancies between the IP address + of an authentication event and the IP address of the verification response event, + focusing on differences in the originating countries. It leverages JSON logs from + PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity + is significant as it may indicate suspicious sign-in behavior, such as account compromise + or unauthorized access attempts. If confirmed malicious, this could allow attackers + to bypass authentication mechanisms, potentially leading to unauthorized access + to sensitive systems and data. data_source: - PingID search: >- - `pingid` ("result.status" IN ("SUCCESS*","FAIL*","UNSUCCESSFUL*") NOT "result.message" IN ("*pair*","*create*","*delete*")) | eval user = upper('actors{}.name'), session_id = 'resources{}.websession', dest = 'resources{}.ipaddress', reason = 'result.message', object = 'resources{}.devicemodel', status = 'result.status' | join user session_id [ search `pingid` ("result.status" IN ("POLICY") AND "resources{}.ipaddress"=*) AND "result.message" IN("*Action: Authenticate*","*Action: Approve*","*Action: Allowed*") | rex field=result.message "IP Address: (?:N\/A)?(?.+)?\n" | rex field=result.message "Action: (?:N\/A)?(?.+)?\n" | rex field=result.message "Requested Application Name: (?:N\/A)?(?.+)?\n" | rex field=result.message "Requested Application ID: (?:N\/A)?(?.+)?\n" | eval user = upper('actors{}.name'), session_id = 'resources{}.websession', src = coalesce('resources{}.ipaddress',policy_ipaddress), app = coalesce(Requested_Application_ID,Requested_Application_Name) | fields app, user, session_id, src, signature ] | iplocation prefix=auth_ dest | iplocation prefix=verify_ src | stats count min(_time) as firstTime max(_time) as lastTime values(app) as app values(session_id) as session_id by user, dest, auth_Country, src, verify_Country, object, signature, status, reason | where auth_Country != verify_Country | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `pingid_mismatch_auth_source_and_verification_response_filter` -how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. -known_false_positives: False positives may be generated by users working out the geographic region where the organizations services or technology is hosted. + `pingid` ("result.status" IN ("SUCCESS*","FAIL*","UNSUCCESSFUL*") NOT "result.message" + IN ("*pair*","*create*","*delete*")) | eval user = upper('actors{}.name'), session_id + = 'resources{}.websession', dest = 'resources{}.ipaddress', reason = 'result.message', + object = 'resources{}.devicemodel', status = 'result.status' | join user session_id + [ search `pingid` ("result.status" IN ("POLICY") AND "resources{}.ipaddress"=*) + AND "result.message" IN("*Action: Authenticate*","*Action: Approve*","*Action: Allowed*") + | rex field=result.message "IP Address: (?:N\/A)?(?.+)?\n" | rex + field=result.message "Action: (?:N\/A)?(?.+)?\n" | rex field=result.message + "Requested Application Name: (?:N\/A)?(?.+)?\n" | rex + field=result.message "Requested Application ID: (?:N\/A)?(?.+)?\n" + | eval user = upper('actors{}.name'), session_id = 'resources{}.websession', src + = coalesce('resources{}.ipaddress',policy_ipaddress), app = coalesce(Requested_Application_ID,Requested_Application_Name) + | fields app, user, session_id, src, signature ] | iplocation prefix=auth_ dest + | iplocation prefix=verify_ src | stats count min(_time) as firstTime max(_time) + as lastTime values(app) as app values(session_id) as session_id by user, dest, auth_Country, + src, verify_Country, object, signature, status, reason | where auth_Country != verify_Country + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `pingid_mismatch_auth_source_and_verification_response_filter` +how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) + enterprise environment, either via Webhook or Push Subscription. +known_false_positives: False positives may be generated by users working out the geographic + region where the organizations services or technology is hosted. references: - https://twitter.com/jhencinski/status/1618660062352007174 - https://attack.mitre.org/techniques/T1098/005/ @@ -23,7 +48,8 @@ tags: asset_type: Identity confidence: 50 impact: 50 - message: An authentication by [$user$] was detected from [$dest$ - $auth_Country$] and the verification was received from [$src$ - $verify_Country$]. + message: An authentication by [$user$] was detected from [$dest$ - $auth_Country$] + and the verification was received from [$src$ - $verify_Country$]. mitre_attack_id: - T1621 - T1556.006 @@ -58,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log source: PINGID sourcetype: _json - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/application/pingid_multiple_failed_mfa_requests_for_user.yml b/detections/application/pingid_multiple_failed_mfa_requests_for_user.yml index 972f5f09c0..495f695cde 100644 --- a/detections/application/pingid_multiple_failed_mfa_requests_for_user.yml +++ b/detections/application/pingid_multiple_failed_mfa_requests_for_user.yml @@ -1,17 +1,30 @@ name: PingID Multiple Failed MFA Requests For User id: c1bc706a-0025-4814-ad30-288f38865036 -version: 1 -date: '2023-09-26' +version: 2 +date: '2024-05-29' author: Steven Dick status: production type: TTP -description: The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description: The following analytic identifies multiple failed multi-factor authentication + (MFA) requests for a single user within a PingID environment. It triggers when 10 + or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity + is significant as it may indicate an adversary attempting to bypass MFA by bombarding + the user with repeated authentication requests. If confirmed malicious, this could + lead to unauthorized access, as the user might eventually accept the fraudulent + request, compromising the security of the account and potentially the entire network. data_source: - PingID search: >- - `pingid` "result.status" IN ("FAILURE,authFail","UNSUCCESSFUL_ATTEMPT") | eval time = _time, src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user = upper('actors{}.name'), object = 'resources{}.devicemodel', reason = 'result.message'| bucket span=10m _time | stats dc(_raw) AS mfa_prompts min(time) as firstTime, max(time) as lastTime values(src) as src by user, reason, _time | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | where mfa_prompts >= 10 | `pingid_multiple_failed_mfa_requests_for_user_filter` -how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. -known_false_positives: False positives may be generated by normal provisioning workflows for user device registration. + `pingid` "result.status" IN ("FAILURE,authFail","UNSUCCESSFUL_ATTEMPT") | eval time + = _time, src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user + = upper('actors{}.name'), object = 'resources{}.devicemodel', reason = 'result.message'| + bucket span=10m _time | stats dc(_raw) AS mfa_prompts min(time) as firstTime, max(time) + as lastTime values(src) as src by user, reason, _time | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)` | where mfa_prompts >= 10 | `pingid_multiple_failed_mfa_requests_for_user_filter` +how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) + enterprise environment, either via Webhook or Push Subscription. +known_false_positives: False positives may be generated by normal provisioning workflows + for user device registration. references: - https://therecord.media/russian-hackers-bypass-2fa-by-annoying-victims-with-repeated-push-notifications/ - https://attack.mitre.org/techniques/T1621/ @@ -24,7 +37,8 @@ tags: asset_type: Identity confidence: 50 impact: 100 - message: Multiple Failed MFA requests $mfa_prompts$ for user $user$ between $firstTime$ and $lastTime$. + message: Multiple Failed MFA requests $mfa_prompts$ for user $user$ between $firstTime$ + and $lastTime$. mitre_attack_id: - T1621 - T1078 @@ -48,8 +62,9 @@ tags: risk_score: 50 security_domain: access tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log - source: PINGID - sourcetype: _json \ No newline at end of file +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log + source: PINGID + sourcetype: _json diff --git a/detections/application/pingid_new_mfa_method_after_credential_reset.yml b/detections/application/pingid_new_mfa_method_after_credential_reset.yml index 5a13b6e9f1..58957a5efe 100644 --- a/detections/application/pingid_new_mfa_method_after_credential_reset.yml +++ b/detections/application/pingid_new_mfa_method_after_credential_reset.yml @@ -1,17 +1,39 @@ name: PingID New MFA Method After Credential Reset id: 2fcbce12-cffa-4c84-b70c-192604d201d0 -version: 1 -date: '2023-09-26' +version: 2 +date: '2024-05-21' author: Steven Dick status: production type: TTP -description: A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning. +description: The following analytic identifies the provisioning of a new MFA device + shortly after a password reset. It detects this activity by correlating Windows + Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating + device pairing. This behavior is significant as it may indicate a social engineering + attack where a threat actor impersonates a valid user to reset credentials and add + a new MFA device. If confirmed malicious, this activity could allow an attacker + to gain persistent access to the compromised account, bypassing traditional security + measures. data_source: - PingID search: >- - `pingid` "result.message" = "*Device Paired*" | rex field=result.message "Device (Unp)?(P)?aired (?.+)" | eval src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user = upper('actors{}.name'), reason = 'result.message' | eval object=CASE(ISNOTNULL('resources{}.devicemodel'),'resources{}.devicemodel',true(),device_extract) | eval action=CASE(match('result.message',"Device Paired*"),"created",match('result.message', "Device Unpaired*"),"deleted") | stats count min(_time) as firstTime, max(_time) as lastTime, values(reason) as reason by src,user,action,object | join type=outer user [| search `wineventlog_security` EventID IN(4723,4724) | eval PW_Change_Time = _time, user = upper(user) | fields user,src_user,EventID,PW_Change_Time] | eval timeDiffRaw = round(lastTime - PW_Change_Time) | eval timeDiff = replace(tostring(abs(timeDiffRaw) ,"duration"),"(\d*)\+*(\d+):(\d+):(\d+)","\2 hours \3 minutes") | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `security_content_ctime(PW_Change_Time)` | where timeDiffRaw > 0 AND timeDiffRaw < 3600 | `pingid_new_mfa_method_after_credential_reset_filter` -how_to_implement: Target environment must ingest Windows Event Log and PingID(PingOne) data sources. Specifically from logs from Active Directory Domain Controllers and JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. -known_false_positives: False positives may be generated by normal provisioning workflows that generate a password reset followed by a device registration. + `pingid` "result.message" = "*Device Paired*" | rex field=result.message "Device + (Unp)?(P)?aired (?.+)" | eval src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), + user = upper('actors{}.name'), reason = 'result.message' | eval object=CASE(ISNOTNULL('resources{}.devicemodel'),'resources{}.devicemodel',true(),device_extract) + | eval action=CASE(match('result.message',"Device Paired*"),"created",match('result.message', + "Device Unpaired*"),"deleted") | stats count min(_time) as firstTime, max(_time) + as lastTime, values(reason) as reason by src,user,action,object | join type=outer + user [| search `wineventlog_security` EventID IN(4723,4724) | eval PW_Change_Time + = _time, user = upper(user) | fields user,src_user,EventID,PW_Change_Time] | eval + timeDiffRaw = round(lastTime - PW_Change_Time) | eval timeDiff = replace(tostring(abs(timeDiffRaw) + ,"duration"),"(\d*)\+*(\d+):(\d+):(\d+)","\2 hours \3 minutes") | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `security_content_ctime(PW_Change_Time)` + | where timeDiffRaw > 0 AND timeDiffRaw < 3600 | `pingid_new_mfa_method_after_credential_reset_filter` +how_to_implement: Target environment must ingest Windows Event Log and PingID(PingOne) + data sources. Specifically from logs from Active Directory Domain Controllers and + JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or + Push Subscription. +known_false_positives: False positives may be generated by normal provisioning workflows + that generate a password reset followed by a device registration. references: - https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/defend-your-users-from-mfa-fatigue-attacks/ba-p/2365677 - https://www.bleepingcomputer.com/news/security/mfa-fatigue-hackers-new-favorite-tactic-in-high-profile-breaches/ @@ -24,11 +46,12 @@ tags: asset_type: Identity confidence: 50 impact: 100 - message: An MFA configuration change was detected for [$user$] within [$timeDiff$] of a password reset. The device [$object$] was $action$. + message: An MFA configuration change was detected for [$user$] within [$timeDiff$] + of a password reset. The device [$object$] was $action$. mitre_attack_id: - T1621 - T1556.006 - - T1098.005 + - T1098.005 observable: - name: user type: User @@ -57,9 +80,11 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/windows_pw_reset.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/windows_pw_reset.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log source: PINGID - sourcetype: _json \ No newline at end of file + sourcetype: _json diff --git a/detections/application/splunk_account_discovery_drilldown_dashboard_disclosure.yml b/detections/application/splunk_account_discovery_drilldown_dashboard_disclosure.yml index 621904fb05..6ccf92f332 100644 --- a/detections/application/splunk_account_discovery_drilldown_dashboard_disclosure.yml +++ b/detections/application/splunk_account_discovery_drilldown_dashboard_disclosure.yml @@ -1,14 +1,17 @@ name: Splunk Account Discovery Drilldown Dashboard Disclosure id: f844c3f6-fd99-43a2-ba24-93e35fe84be6 -version: 1 -date: '2022-08-02' +version: 2 +date: '2024-05-15' author: Marissa Bower, Rod Soto, Splunk status: experimental type: TTP -description: Splunk drilldown vulnerability disclosure in Dashboard application that - can potentially allow exposure of tokens from privilege users. An attacker can create - dashboard and share it to privileged user (admin) and detokenize variables using - external urls within dashboards drilldown function. +description: The following analytic identifies the presence of environment variables + in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for + specific patterns in the XML data. This activity is significant because it can expose + sensitive tokens from privileged users if an attacker shares a malicious dashboard. + If confirmed malicious, this could allow an attacker to detokenize variables and + potentially gain unauthorized access to sensitive information or escalate privileges + within the Splunk environment. data_source: [] search: '| rest splunk_server=local /servicesNS/-/-/data/ui/views | search eai:data="*$env:*" eai:data="*url*" eai:data="*options*" | rename author AS Author eai:acl.sharing diff --git a/detections/application/splunk_authentication_token_exposure_in_debug_log.yml b/detections/application/splunk_authentication_token_exposure_in_debug_log.yml index 04954050ca..fa004a85b2 100644 --- a/detections/application/splunk_authentication_token_exposure_in_debug_log.yml +++ b/detections/application/splunk_authentication_token_exposure_in_debug_log.yml @@ -1,21 +1,28 @@ name: Splunk Authentication Token Exposure in Debug Log id: 9a67e749-d291-40dd-8376-d422e7ecf8b5 -version: 1 -date: '2024-03-18' +version: 2 +date: '2024-05-25' author: Rod Soto, Chase Franklin type: TTP status: production data_source: [] -description: This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG. -search: '`splunkd` component=JsonWebToken log_level=DEBUG eventtype="splunkd-log" event_message="Validating token:*" - | rex "Validating token: (?.*)\.$" - | search token!=None - | stats count min(_time) as firstTime max(_time) as lastTime values(log_level) as log_level values(event_message) as event_message by index, sourcetype, host, token - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies exposed authentication tokens in debug + logs within Splunk Enterprise. It leverages logs from the `splunkd` component with + a DEBUG log level, specifically searching for event messages that validate tokens. + This activity is significant because exposed tokens can be exploited by attackers + to gain unauthorized access to the Splunk environment. If confirmed malicious, this + exposure could lead to unauthorized data access, privilege escalation, and potential + compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability + is crucial for maintaining the security and integrity of the Splunk deployment. +search: '`splunkd` component=JsonWebToken log_level=DEBUG eventtype="splunkd-log" + event_message="Validating token:*" | rex "Validating token: (?.*)\.$" | search + token!=None | stats count min(_time) as firstTime max(_time) as lastTime values(log_level) + as log_level values(event_message) as event_message by index, sourcetype, host, + token | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `splunk_authentication_token_exposure_in_debug_log_filter`' -how_to_implement: Requires access to internal Splunk indexes. -known_false_positives: Only applies to affected versions of Splunk Enterprise below 9.2.1, 9.1.4, and 9.0.9 +how_to_implement: Requires access to internal Splunk indexes. +known_false_positives: Only applies to affected versions of Splunk Enterprise below + 9.2.1, 9.1.4, and 9.0.9 references: - https://advisory.splunk.com/advisories/SVD-2024-0301 tags: @@ -41,14 +48,15 @@ tags: - component - log_level - eventtype - - event_message + - event_message - host risk_score: 50 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1654/splunk/jsonwebtokenplaintokensvd_splunkd.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1654/splunk/jsonwebtokenplaintokensvd_splunkd.log source: /opt/splunk/var/log/splunk/splunkd.log sourcetype: splunkd custom_index: _internal diff --git a/detections/application/splunk_code_injection_via_custom_dashboard_leading_to_rce.yml b/detections/application/splunk_code_injection_via_custom_dashboard_leading_to_rce.yml index d65a5a89e0..5911352019 100644 --- a/detections/application/splunk_code_injection_via_custom_dashboard_leading_to_rce.yml +++ b/detections/application/splunk_code_injection_via_custom_dashboard_leading_to_rce.yml @@ -1,14 +1,18 @@ name: Splunk Code Injection via custom dashboard leading to RCE id: b06b41d7-9570-4985-8137-0784f582a1b3 -version: 1 -date: '2022-10-11' +version: 2 +date: '2024-05-24' author: Rod Soto status: experimental type: Hunting -description: This hunting search provides information about a vulnerability in Splunk - Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can - execute arbitrary code via the dashboard pdf generation component. Please review - events with file=export in the _internal index for the potential targets of exploitation. +description: The following analytic identifies attempts to exploit a vulnerability + in Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, where an authenticated + user can execute arbitrary code via the dashboard PDF generation component. It detects + this activity by analyzing events in the _internal index with the file=export parameter. + This behavior is significant because it indicates a potential code injection attack, + which could lead to remote code execution (RCE). If confirmed malicious, an attacker + could gain unauthorized access, execute arbitrary commands, and potentially compromise + the entire Splunk environment. data_source: [] search: '`splunkd_ui` uri_path=*/data/ui/views/* OR uri_path=*saved/searches/* | dedup uri_path | eval URL=urldecode("uri_path")| rex field=URL "\/saved\/searches\/(?[^\/]*)" @@ -56,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_code_injection_via_custom_dashboard_leading_to_rce.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_code_injection_via_custom_dashboard_leading_to_rce.txt source: /opt/splunk/var/log/splunk/splunkd_ui_access.log sourcetype: splunkd_ui_access custom_index: _internal diff --git a/detections/application/splunk_command_and_scripting_interpreter_delete_usage.yml b/detections/application/splunk_command_and_scripting_interpreter_delete_usage.yml index c840f4d69c..4398016fff 100644 --- a/detections/application/splunk_command_and_scripting_interpreter_delete_usage.yml +++ b/detections/application/splunk_command_and_scripting_interpreter_delete_usage.yml @@ -1,15 +1,19 @@ name: Splunk Command and Scripting Interpreter Delete Usage id: 8d3d5d5e-ca43-42be-aa1f-bc64375f6b04 -version: 1 -date: '2022-05-27' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the use of the risky command - Delete - - that may be utilized in Splunk to delete some or all data queried for. In order - to use Delete in Splunk, one must be assigned the role. This is typically not used - and should generate an anomaly if it is used. -data_source: +description: The following analytic detects the use of the 'delete' command in Splunk, + which can be used to remove queried data. This detection leverages the Splunk Audit + data model, specifically monitoring ad-hoc searches containing the 'delete' command + by non-system users. This activity is significant because the 'delete' command is + rarely used and can indicate potential data tampering or unauthorized data removal. + If confirmed malicious, this activity could lead to the loss of critical log data, + hindering incident investigations and compromising the integrity of the monitoring + environment. +data_source: - Splunk search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search @@ -59,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/splunk_command_and_scripting_interpreter_risky_commands.yml b/detections/application/splunk_command_and_scripting_interpreter_risky_commands.yml index 142c4bf3d0..07ce527149 100644 --- a/detections/application/splunk_command_and_scripting_interpreter_risky_commands.yml +++ b/detections/application/splunk_command_and_scripting_interpreter_risky_commands.yml @@ -1,30 +1,19 @@ name: Splunk Command and Scripting Interpreter Risky Commands id: 1cf58ae1-9177-40b8-a26c-8966040f11ae -version: 1 -date: '2022-05-23' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: Hunting -description: The Splunk platform contains built-in search processing language (SPL) - safeguards to warn you when you are about to unknowingly run a search that contains - commands that might be a security risk. This warning appears when you click a link - or type a URL that loads a search that contains risky commands. The warning does - not appear when you create ad hoc searches. This warning alerts you to the possibility - of unauthorized actions by a malicious user. Unauthorized actions include - Copying - or transferring data (data exfiltration), Deleting data and Overwriting data. All - risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga. - A possible scenario when this might occur is when a malicious actor creates a search - that includes commands that exfiltrate or damage data. The malicious actor then - sends an unsuspecting user a link to the search. The URL contains a query string - (q) and a search identifier (sid), but the sid is not valid. The malicious actor - hopes the user will use the link and the search will run. During analysis, pivot - based on user name and filter any user or queries not needed. Queries ran from a - dashboard are seen as adhoc queries. When a query runs from a dashboard it will - not show in audittrail logs the source dashboard name. The query defaults to adhoc - and no Splunk system user activity. In addition, modify this query by removing key - commands that generate too much noise, or too little, and create separate queries - with higher confidence to alert on. -data_source: +description: The following analytic identifies the execution of risky commands within + the Splunk platform, such as `runshellscript`, `delete`, and `sendemail`. It leverages + the Search_Activity data model to detect ad hoc searches containing these commands, + excluding those run by the splunk-system-user. This activity is significant because + it may indicate attempts at data exfiltration, deletion, or other unauthorized actions + by a malicious user. If confirmed malicious, this could lead to data loss, unauthorized + data transfer, or system compromise, severely impacting the organization's security + posture. +data_source: - Splunk search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search @@ -84,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/splunk_command_and_scripting_interpreter_risky_spl_mltk.yml b/detections/application/splunk_command_and_scripting_interpreter_risky_spl_mltk.yml index 2451dbadf5..cfaee91656 100644 --- a/detections/application/splunk_command_and_scripting_interpreter_risky_spl_mltk.yml +++ b/detections/application/splunk_command_and_scripting_interpreter_risky_spl_mltk.yml @@ -1,18 +1,19 @@ name: Splunk Command and Scripting Interpreter Risky SPL MLTK id: 19d0146c-2eae-4e53-8d39-1198a78fa9ca -version: 1 -date: '2022-05-27' +version: 2 +date: '2024-05-15' author: Abhinav Mishra, Kumar Sharad and Xiao Lin, Splunk status: production type: Anomaly -description: This detection utilizes machine learning model named "risky_command_abuse" - trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline". - It should be scheduled to run hourly to detect whether a user has run searches containing - risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga - with abnormally long running time in the past one hour, comparing with his/her past - seven days history. This search uses the trained baseline to infer whether a search - is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0) -data_source: +description: The following analytic identifies the execution of risky SPL commands + with abnormally long run times by leveraging a machine learning model named "risky_command_abuse." + It uses the Splunk Audit data model to compare current search activities against + a baseline of the past seven days. This activity is significant for a SOC as it + can indicate potential misuse or abuse of powerful SPL commands, which could lead + to unauthorized data access or system manipulation. If confirmed malicious, this + activity could allow an attacker to execute arbitrary scripts, delete data, or exfiltrate + sensitive information. +data_source: - Splunk search: '| tstats sum(Search_Activity.total_run_time) AS run_time, values(Search_Activity.search) as searches, count FROM datamodel=Splunk_Audit.Search_Activity WHERE (Search_Activity.user!="") @@ -65,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt + - data: + https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/splunk_csrf_in_the_ssg_kvstore_client_endpoint.yml b/detections/application/splunk_csrf_in_the_ssg_kvstore_client_endpoint.yml index f449501b18..c4a186e320 100644 --- a/detections/application/splunk_csrf_in_the_ssg_kvstore_client_endpoint.yml +++ b/detections/application/splunk_csrf_in_the_ssg_kvstore_client_endpoint.yml @@ -1,18 +1,19 @@ name: Splunk csrf in the ssg kvstore client endpoint id: 4742d5f7-ce00-45ce-9c79-5e98b43b4410 -version: 1 -date: '2023-02-14' +version: 2 +date: '2024-05-11' author: Rod Soto status: production type: TTP -description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site - request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint - allows for updating SSG KV store collections via a GET request. SSG is a Splunk - Built app included by default with Splunk Enterprise. The vulnerability affects - instances with SSG and Splunk Web enabled. This hunting search provides information - on affected server specific method and post data that may reveal exploitation of - this vulnerability. -data_source: +description: The following analytic identifies attempts to exploit a cross-site request + forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client + endpoint. It detects GET requests to the vulnerable endpoint using internal index + data, focusing on specific URI paths and HTTP methods. This activity is significant + because it can allow unauthorized updates to SSG KV store collections, potentially + leading to data manipulation or unauthorized access. If confirmed malicious, this + could enable attackers to alter critical configurations or exfiltrate sensitive + information, compromising the integrity and security of the Splunk environment. +data_source: - Splunk search: '`splunkda` uri_path="/en-US/splunkd/__raw/services/ssg/kvstore_client" method="GET" delete_field_value="spacebridge_server" status="200" | table splunk_server status @@ -56,7 +57,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_csrf_in_the_ssg_kvstore_client_endpoint_data.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_csrf_in_the_ssg_kvstore_client_endpoint_data.log source: splunkd_access.log sourcetype: splunkd_access custom_index: _internal diff --git a/detections/application/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.yml b/detections/application/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.yml index edde6b1e80..2e53d18f26 100644 --- a/detections/application/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.yml +++ b/detections/application/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.yml @@ -1,16 +1,19 @@ name: Splunk Data exfiltration from Analytics Workspace using sid query id: b6d77c6c-f011-4b03-8650-8f10edb7c4a8 -version: 1 -date: '2022-11-01' +version: 2 +date: '2024-05-25' author: Rod Soto, Eric McGinnis status: production type: Hunting -description: This hunting search allows operator to discover attempts to exfiltrate - data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk - Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires - the attacker to compel a victim to initiate a request within their browser (phishing). - The attacker cannot exploit the vulnerability at will. -data_source: +description: The following analytic identifies attempts to exfiltrate data by executing + a prepositioned malicious search ID in Splunk's Analytic Workspace. It leverages + the `audit_searches` data source to detect suspicious `mstats` commands indicative + of injection attempts. This activity is significant as it may indicate a phishing-based + attack where an attacker compels a victim to initiate a malicious request, potentially + leading to unauthorized data access. If confirmed malicious, this could result in + significant data exfiltration, compromising sensitive information and impacting + the organization's security posture. +data_source: - Splunk search: '`audit_searches` info=granted search NOT ("audit_searches") search NOT ("security_content_summariesonly") AND ((search="*mstats*[*]*" AND provenance="N/A") OR (search="*mstats*\\\"*[*]*\\\"*"))| @@ -59,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1567/splunk/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1567/splunk/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.txt source: audittrail sourcetype: audittrail custom_index: _audit diff --git a/detections/application/splunk_digital_certificates_infrastructure_version.yml b/detections/application/splunk_digital_certificates_infrastructure_version.yml index 00aec63786..15c43c0e3b 100644 --- a/detections/application/splunk_digital_certificates_infrastructure_version.yml +++ b/detections/application/splunk_digital_certificates_infrastructure_version.yml @@ -1,15 +1,19 @@ name: Splunk Digital Certificates Infrastructure Version id: 3c162281-7edb-4ebc-b9a4-5087aaf28fa7 -version: 1 -date: '2022-05-26' +version: 2 +date: '2024-05-27' author: Lou Stella, Splunk status: production type: Hunting -description: This search will check the TLS validation is properly configured on the - search head it is run from as well as its search peers after Splunk version 9. Other - components such as additional search heads or anything this rest command cannot - be distributed to will need to be manually checked. -data_source: +description: The following analytic identifies improper TLS validation configuration + on Splunk search heads and peers post version 9. It leverages REST API calls to + retrieve server information and SSL configuration settings, checking fields like + `sslVerifyServerCert` and `sslVerifyServerName`. This activity is significant for + a SOC as improper TLS settings can expose the infrastructure to man-in-the-middle + attacks and data breaches. If confirmed malicious, attackers could intercept or + manipulate data, compromising the integrity and confidentiality of communications + within the Splunk environment. +data_source: - Splunk search: '| rest /services/server/info | table splunk_server version server_roles | join splunk_server [| rest /servicesNS/nobody/search/configs/conf-server/ search="sslConfig"| @@ -58,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/splunk_digital_certificates_lack_of_encryption.yml b/detections/application/splunk_digital_certificates_lack_of_encryption.yml index feccdd2a72..edaab43ed3 100644 --- a/detections/application/splunk_digital_certificates_lack_of_encryption.yml +++ b/detections/application/splunk_digital_certificates_lack_of_encryption.yml @@ -1,19 +1,18 @@ name: Splunk Digital Certificates Lack of Encryption id: 386a7ebc-737b-48cf-9ca8-5405459ed508 -version: 1 -date: '2022-05-26' +version: 2 +date: '2024-05-18' author: Lou Stella, Splunk status: production type: Anomaly -description: On June 14th, 2022, Splunk released a security advisory relating to the - authentication that happens between Universal Forwarders and Deployment Servers. - In some circumstances, an unauthenticated client can download forwarder bundles - from the Deployment Server. In other circumstances, a client may be allowed to publish - a forwarder bundle to other clients, which may allow for arbitrary code execution. - The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as - well. This is a great opportunity to configure TLS across the environment. This - search looks for forwarders that are not using TLS and adds risk to those entities. -data_source: +description: The following analytic identifies Splunk forwarder connections that are + not using TLS encryption. It leverages data from the `splunkd` logs, specifically + looking for connections where the `ssl` field is set to "false". This activity is + significant because unencrypted connections can expose sensitive data and allow + unauthorized access, posing a security risk. If confirmed malicious, an attacker + could exploit this vulnerability to download or publish forwarder bundles, potentially + leading to arbitrary code execution and further compromise of the environment. +data_source: - Splunk search: '`splunkd` group="tcpin_connections" ssl="false" | stats values(sourceIp) latest(fwdType) latest(version) by hostname | `splunk_digital_certificates_lack_of_encryption_filter`' @@ -65,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.003/splunk_fwder/splunkd.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.003/splunk_fwder/splunkd.log source: /opt/splunk/var/log/splunk/metrics.log sourcetype: splunkd update_timestamp: false diff --git a/detections/application/splunk_dos_using_malformed_saml_request.yml b/detections/application/splunk_dos_using_malformed_saml_request.yml index 94b4a37f9e..669a282909 100644 --- a/detections/application/splunk_dos_using_malformed_saml_request.yml +++ b/detections/application/splunk_dos_using_malformed_saml_request.yml @@ -1,21 +1,31 @@ name: Splunk DoS Using Malformed SAML Request id: 8e8a86d5-f323-4567-95be-8e817e2baee6 -version: 1 -date: '2023-09-05' +version: 2 +date: '2024-05-29' author: Rod Soto status: production type: Hunting -data_source: +data_source: - Splunk -description: In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang. -search: '`splunkd` event_message=*error* expr=*xpointer* | stats count min(_time) as firstTime max(_time) as lastTime by component expr splunk_server event_message | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_dos_using_malformed_saml_request_filter`' -how_to_implement: To run this search, you must have access to the _internal index. -known_false_positives: This search will show false positives. The analyst must look for errors and a pointer indicating a malicious file. +description: The following analytic detects a denial of service (DoS) attempt using + a malformed SAML request targeting the /saml/acs REST endpoint in Splunk Enterprise + versions lower than 9.0.6 and 8.2.12. It leverages `splunkd` logs, specifically + looking for error messages containing "xpointer" in the `expr` field. This activity + is significant because it can cause the Splunk daemon to crash or hang, disrupting + service availability. If confirmed malicious, this attack could lead to prolonged + downtime, impacting the organization's ability to monitor and respond to security + events. +search: '`splunkd` event_message=*error* expr=*xpointer* | stats count min(_time) + as firstTime max(_time) as lastTime by component expr splunk_server event_message + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_dos_using_malformed_saml_request_filter`' +how_to_implement: To run this search, you must have access to the _internal index. +known_false_positives: This search will show false positives. The analyst must look + for errors and a pointer indicating a malicious file. references: - https://advisory.splunk.com/advisories/SVD-2023-0802 tags: analytic_story: - - Splunk Vulnerabilities + - Splunk Vulnerabilities asset_type: Endpoint confidence: 30 impact: 50 @@ -34,14 +44,15 @@ tags: risk_score: 15 required_fields: - component - - expr - - host - - event_message + - expr + - host + - event_message security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk/splunk_dos_using_malformed_saml_request_splunkd.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk/splunk_dos_using_malformed_saml_request_splunkd.log source: splunkd.log sourcetype: splunkd - custom_index: _internal \ No newline at end of file + custom_index: _internal diff --git a/detections/application/splunk_dos_via_malformed_s2s_request.yml b/detections/application/splunk_dos_via_malformed_s2s_request.yml index 75b3515bc7..a195ee0823 100644 --- a/detections/application/splunk_dos_via_malformed_s2s_request.yml +++ b/detections/application/splunk_dos_via_malformed_s2s_request.yml @@ -1,15 +1,19 @@ name: Splunk DoS via Malformed S2S Request id: fc246e56-953b-40c1-8634-868f9e474cbd -version: 2 -date: '2022-03-24' +version: 3 +date: '2024-05-27' author: Lou Stella, Splunk status: production type: TTP -description: On March 24th, 2022, Splunk published a security advisory for a possible - Denial of Service stemming from the lack of validation in a specific key-value field - in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation - in patched versions of Splunk. -data_source: +description: The following analytic identifies attempts to exploit a Denial of Service + (DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed + S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level + logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread" + and the message "Invalid _meta atom." This activity is significant as it targets + a known vulnerability that could disrupt Splunk services. If confirmed malicious, + this could lead to service outages, impacting the availability and reliability of + Splunk for monitoring and analysis. +data_source: - Splunk search: '`splunkd` log_level="ERROR" component="TcpInputProc" thread_name="FwdDataReceiverThread" "Invalid _meta atom" | table host, src | `splunk_dos_via_malformed_s2s_request_filter`' @@ -55,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk_indexer_dos/splunkd.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk_indexer_dos/splunkd.log source: /opt/splunk/var/log/splunk/splunkd.log sourcetype: splunkd update_timestamp: true diff --git a/detections/application/splunk_dos_via_printf_search_function.yml b/detections/application/splunk_dos_via_printf_search_function.yml index bc058bd7b1..2b7d790800 100644 --- a/detections/application/splunk_dos_via_printf_search_function.yml +++ b/detections/application/splunk_dos_via_printf_search_function.yml @@ -1,18 +1,28 @@ name: Splunk DOS via printf search function id: 78b48d08-075c-4eac-bd07-e364c3780867 -version: 1 -date: '2023-08-30' +version: 2 +date: '2024-05-25' author: Rod Soto, Eric McGinnis, Splunk status: production type: Hunting -data_source: +data_source: - Splunk -description: This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance. -search: '`audit_searches` "*makeresults * eval * fieldformat *printf*" user!="splunk_system_user" search!="*audit_searches*" - | stats count by user splunk_server host search - | convert ctime(*time) |`splunk_dos_via_printf_search_function_filter`' -how_to_implement: This search requires the ability to search internal indexes. -known_false_positives: This search may produces false positives, analyst most focuse in the use of printf conversion function of eval to craft an expression that splunkd cannot interpret correctly causing it to crash. +description: The following analytic identifies the use of the `printf` SPL function + in Splunk searches, which can be exploited for a denial of service (DoS) attack. + It detects this activity by querying the `audit_searches` data source for specific + patterns involving `makeresults`, `eval`, `fieldformat`, and `printf` functions, + excluding searches by the `splunk_system_user`. This activity is significant because + it targets a known vulnerability in Splunk Enterprise versions lower than 8.1.14, + 8.2.12, 9.0.6, and 9.1.1, potentially disrupting the availability of the Splunk + instance. If confirmed malicious, this could lead to service outages and impact + the monitoring and logging capabilities of the organization. +search: '`audit_searches` "*makeresults * eval * fieldformat *printf*" user!="splunk_system_user" + search!="*audit_searches*" | stats count by user splunk_server host search | convert + ctime(*time) |`splunk_dos_via_printf_search_function_filter`' +how_to_implement: This search requires the ability to search internal indexes. +known_false_positives: This search may produces false positives, analyst most focuse + in the use of printf conversion function of eval to craft an expression that splunkd + cannot interpret correctly causing it to crash. references: - https://advisory.splunk.com/ tags: @@ -37,15 +47,16 @@ tags: - Splunk Cloud risk_score: 100 required_fields: - - user + - user - splunk_server - host - - search + - search security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499.004/splunk/splunk_printf_abuse.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499.004/splunk/splunk_printf_abuse.log source: audittrail sourcetype: audittrail custom_index: _audit diff --git a/detections/application/splunk_endpoint_denial_of_service_dos_zip_bomb.yml b/detections/application/splunk_endpoint_denial_of_service_dos_zip_bomb.yml index 58e274e716..f3e483dc5d 100644 --- a/detections/application/splunk_endpoint_denial_of_service_dos_zip_bomb.yml +++ b/detections/application/splunk_endpoint_denial_of_service_dos_zip_bomb.yml @@ -1,18 +1,19 @@ name: Splunk Endpoint Denial of Service DoS Zip Bomb id: b237d393-2f57-4531-aad7-ad3c17c8b041 -version: 1 -date: '2022-08-02' +version: 2 +date: '2024-05-27' author: Marissa Bower, Rod Soto, Splunk status: production type: TTP -description: This search allows operator to identify Splunk search app crashes resulting - from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 - and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before - crash. This search will provide Universal Forwarder errors from uploaded binary - files (zip compression) which are used for this attack. If an analyst sees results - from this search we suggest you investigate and triage what zip file was uploaded, - zip compressed files may have different extensions. -data_source: +description: The following analytic identifies crashes in the Splunk search app caused + by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and + 8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder + error logs for specific messages indicating invalid or binary file issues. This + activity is significant because it can disrupt Splunk operations, leading to potential + data loss or monitoring gaps. If confirmed malicious, this attack could result in + a denial of service, hindering the organization's ability to monitor and respond + to other security incidents effectively. +data_source: - Splunk search: '`splunkd` component=FileClassifierManager event_message=*invalid* event_message=*binary* |stats count by host component event_message | `splunk_endpoint_denial_of_service_dos_zip_bomb_filter`' @@ -52,7 +53,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_zip_bomb_vulnerability.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_zip_bomb_vulnerability.log source: /opt/splunkforwarder/var/log/splunk/splunkd.log sourcetype: splunkd custom_index: _internal diff --git a/detections/application/splunk_enterprise_kv_store_incorrect_authorization.yml b/detections/application/splunk_enterprise_kv_store_incorrect_authorization.yml index 85b6d110a8..d9a3f8b1ab 100644 --- a/detections/application/splunk_enterprise_kv_store_incorrect_authorization.yml +++ b/detections/application/splunk_enterprise_kv_store_incorrect_authorization.yml @@ -1,20 +1,28 @@ name: Splunk Enterprise KV Store Incorrect Authorization id: 8f0e8380-a835-4f2b-b749-9ce119364df0 -version: 1 -date: '2024-01-18' +version: 2 +date: '2024-05-10' author: Rod Soto, Eric McGinnis, Chase Franklin status: production type: Hunting -data_source: +data_source: - Splunk -description: In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections. -search: '`splunkda` uri=/servicesNS/nobody/search/admin/collections-conf/_reload status=2* method="POST" user=* file=_reload - | stats count min(_time) as firstTime max(_time) as lastTime values(status) as status by host clientip file method - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `splunk_enterprise_kv_store_incorrect_authorization_filter`' -how_to_implement: Requires access to internal indexes and REST API enabled instances. -known_false_positives: This is a hunting search and will produce false positives. Operator must follow results into instances where curl requests coming from actual users may indicate intent of exploitation. +description: The following analytic detects unauthorized attempts to reload Splunk + KV Store collections via the REST API. It leverages internal index logs to identify + POST requests to the `/servicesNS/nobody/search/admin/collections-conf/_reload` + endpoint, focusing on status codes starting with '2'. This activity is significant + as it may indicate improper permission handling, potentially leading to unauthorized + deletion of KV Store collections. If confirmed malicious, this could result in data + loss or unauthorized data manipulation, impacting the integrity and availability + of critical Splunk data. +search: '`splunkda` uri=/servicesNS/nobody/search/admin/collections-conf/_reload status=2* + method="POST" user=* file=_reload | stats count min(_time) as firstTime max(_time) + as lastTime values(status) as status by host clientip file method | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `splunk_enterprise_kv_store_incorrect_authorization_filter`' +how_to_implement: Requires access to internal indexes and REST API enabled instances. +known_false_positives: This is a hunting search and will produce false positives. + Operator must follow results into instances where curl requests coming from actual + users may indicate intent of exploitation. references: - https://advisory.splunk.com/advisories/SVD-2024-0105 tags: @@ -39,16 +47,17 @@ tags: risk_score: 25 required_fields: - uri - - status - - method - - file - - clientip - - host + - status + - method + - file + - clientip + - host security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/splunk/splunk_enterprise_kv_store_incorrect_authorization_splunkd_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/splunk/splunk_enterprise_kv_store_incorrect_authorization_splunkd_access.log source: /opt/splunk/var/log/splunk/splunkd_access.log - sourcetype: splunkd_access - custom_index: _internal + sourcetype: splunkd_access + custom_index: _internal diff --git a/detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml b/detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml index ef84370bb5..b4fd15ff4f 100644 --- a/detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml +++ b/detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml @@ -1,19 +1,30 @@ name: Splunk ES DoS Investigations Manager via Investigation Creation id: 7f6a07bd-82ef-46b8-8eba-802278abd00e -version: 1 -date: '2024-01-04' +version: 2 +date: '2024-05-25' author: Rod Soto, Eric McGinnis, Chase Franklin status: production type: TTP -data_source: +data_source: - Splunk -description: In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted. -search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error | stats count min(_time) as firstTime max(_time) as lastTime by user host method msg - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `splunk_es_dos_investigations_manager_via_investigation_creation_filter`' -how_to_implement: This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2. -known_false_positives: The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event. +description: The following analytic detects the creation of malformed Investigations + in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to + a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring + the `splunkd_investigation_rest_handler` with error statuses during investigation + creation. This activity is significant as it can disrupt the functionality of the + Investigations manager, hindering incident response efforts. If confirmed malicious, + this could prevent security teams from accessing critical investigation data, severely + impacting their ability to manage and respond to security incidents effectively. +search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error + | stats count min(_time) as firstTime max(_time) as lastTime by user host method + msg | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | + `splunk_es_dos_investigations_manager_via_investigation_creation_filter`' +how_to_implement: This search requires access to internal indexes. Only affects Splunk + Enterprise Security versions lower than 7.1.2. +known_false_positives: The vulnerability requires an authenticated session and access + to create an Investigation. It only affects the availability of the Investigations + manager, but without the manager, the Investigations functionality becomes unusable + for most users. This search gives the exact offending event. references: - https://advisory.splunk.com/advisories/SVD-2024-0102 tags: @@ -29,7 +40,7 @@ tags: - T1499 observable: - name: user - type: User + type: User role: - Victim - name: host @@ -41,14 +52,15 @@ tags: risk_score: 100 required_fields: - method - - msg - - status - - user + - msg + - status + - user security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log source: /opt/splunk/var/log/splunk/investigation_handler.log sourcetype: investigation_rest_handler custom_index: _internal diff --git a/detections/application/splunk_es_dos_through_investigation_attachments.yml b/detections/application/splunk_es_dos_through_investigation_attachments.yml index e80d24e9aa..4cb6dfc441 100644 --- a/detections/application/splunk_es_dos_through_investigation_attachments.yml +++ b/detections/application/splunk_es_dos_through_investigation_attachments.yml @@ -1,20 +1,31 @@ name: Splunk ES DoS Through Investigation Attachments id: bb85b25e-2d6b-4e39-bd27-50db42edcb8f -version: 1 -date: '2024-01-04' +version: 2 +date: '2024-05-29' author: Rod Soto, Eric McGinnis, Chase Franklin status: production type: TTP -data_source: +data_source: - Splunk -description: In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible. -search: '`splunkd_investigation_rest_handler` status=error object=investigation - | stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg) as msg values(id) as investigation_id by user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `splunk_es_dos_through_investigation_attachments_filter`' -how_to_implement: This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2. -known_false_positives: This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager. +description: The following analytic detects attempts to perform a denial of service + (DoS) attack through investigation attachments in Splunk Enterprise Security (ES) + versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring + the `splunkd_investigation_rest_handler` for error statuses related to investigation + objects. This activity is significant because it can render the Investigation feature + inaccessible, disrupting incident response and forensic analysis. If confirmed malicious, + this attack could prevent security teams from effectively managing and investigating + security incidents, leading to prolonged exposure and potential data breaches. +search: '`splunkd_investigation_rest_handler` status=error object=investigation | + stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg) + as msg values(id) as investigation_id by user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `splunk_es_dos_through_investigation_attachments_filter`' +how_to_implement: This search requires access to internal indexes, only affects Enterprise + Security versions below 7.1.2. +known_false_positives: This search will show the exact DoS event via error message + and investigation id. The error however does not point exactly at the uploader as + any users associated with the investigation will be affected. Operator must investigate + using investigation id the possible origin of the malicious upload. Attack only + affects specific investigation not the investigation manager. references: - https://advisory.splunk.com/advisories/SVD-2024-0101 tags: @@ -30,23 +41,24 @@ tags: - T1499 observable: - name: user - type: User + type: User role: - Victim product: - Splunk Enterprise Security risk_score: 100 required_fields: - - user - - status - - msg - - id - - object + - user + - status + - msg + - id + - object security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log source: /opt/splunk/var/log/splunk/investigation_handler.log sourcetype: investigation_rest_handler custom_index: _internal diff --git a/detections/application/splunk_http_response_splitting_via_rest_spl_command.yml b/detections/application/splunk_http_response_splitting_via_rest_spl_command.yml index c189b55d1f..283e7c0c90 100644 --- a/detections/application/splunk_http_response_splitting_via_rest_spl_command.yml +++ b/detections/application/splunk_http_response_splitting_via_rest_spl_command.yml @@ -1,21 +1,34 @@ name: Splunk HTTP Response Splitting Via Rest SPL Command id: e615a0e1-a1b2-4196-9865-8aa646e1708c -version: 1 -date: '2023-05-23' +version: 2 +date: '2024-05-27' author: Rod Soto, Chase Franklin status: production type: Hunting data_source: - Splunk -description: A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will. -search: '`audit_searches` AND search IN ("*|*rest*POST*","*|*rest*PUT*","*|*rest*PATCH*","*|*rest*DELETE*") AND NOT search="*audit_searches*" | table user info has_error_msg search _time | `splunk_http_response_splitting_via_rest_spl_command_filter`' -how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This search may assist in detecting possible http response splitting exploitation attemptss. -known_false_positives: This search may have produce false positives as malformed or erroneous requests made to this endpoint may be executed willingly or erroneously by operators. +description: The following analytic identifies attempts to exploit an HTTP response + splitting vulnerability via the rest SPL command in Splunk. It detects this activity + by analyzing audit logs for specific search commands that include REST methods like + POST, PUT, PATCH, or DELETE. This behavior is significant because it indicates a + potential attempt to access restricted REST endpoints, which could lead to unauthorized + access to sensitive information. If confirmed malicious, this activity could allow + an attacker to access restricted content, such as password files, by injecting commands + into HTTP requests. +search: '`audit_searches` AND search IN ("*|*rest*POST*","*|*rest*PUT*","*|*rest*PATCH*","*|*rest*DELETE*") + AND NOT search="*audit_searches*" | table user info has_error_msg search _time | + `splunk_http_response_splitting_via_rest_spl_command_filter`' +how_to_implement: This detection does not require you to ingest any new data. The + detection does require the ability to search the _audit index. This search may assist + in detecting possible http response splitting exploitation attemptss. +known_false_positives: This search may have produce false positives as malformed or + erroneous requests made to this endpoint may be executed willingly or erroneously + by operators. references: - https://advisory.splunk.com/ tags: analytic_story: - - Splunk Vulnerabilities + - Splunk Vulnerabilities asset_type: Endpoint atomic_guid: [] confidence: 50 @@ -33,14 +46,15 @@ tags: risk_score: 25 required_fields: - search - - testing_endpoint - - info + - testing_endpoint + - info - has_error_msg security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.006/splunk/splunk_http_response_splitting_via_rest_spl_command.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.006/splunk/splunk_http_response_splitting_via_rest_spl_command.log source: audittrail sourcetype: audittrail custom_index: _audit diff --git a/detections/application/splunk_list_all_nonstandard_admin_accounts.yml b/detections/application/splunk_list_all_nonstandard_admin_accounts.yml index ceeea9fa1a..ef97675e46 100644 --- a/detections/application/splunk_list_all_nonstandard_admin_accounts.yml +++ b/detections/application/splunk_list_all_nonstandard_admin_accounts.yml @@ -1,18 +1,18 @@ name: Splunk list all nonstandard admin accounts id: 401d689c-8596-4c6b-a710-7b6fdca296d3 -version: 1 -date: '2023-02-07' +version: 2 +date: '2024-05-21' author: Rod Soto status: experimental type: Hunting -description: 'This search will enumerate all Splunk Accounts with administrative rights - on this instance. It deliberately ignores the default admin account since this - is assumed to be present. This search may help in a detection the Cross-Site Scripting - Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a - View allows for Cross-Site Scripting in an XML View through the ''layoutPanel'' - attribute in the ''module'' tag. The vulnerability affects instances with Splunk - Web enabled.' -data_source: +description: 'The following analytic identifies nonstandard Splunk accounts with administrative + rights on the instance, excluding the default admin account. It uses REST API calls + to retrieve user data and filters for accounts with admin capabilities. This activity + is significant as unauthorized admin accounts can indicate potential security breaches + or misconfigurations. If confirmed malicious, attackers could leverage these accounts + to execute commands, escalate privileges, or persist within the environment, posing + a significant risk to the integrity and security of the Splunk instance.' +data_source: - Splunk search: '| rest splunk_server=local /services/authentication/users |search capabilities=admin* OR imported_capabilities=admin* title!=admin | table title roles capabilities splunk_server diff --git a/detections/application/splunk_low_privilege_user_can_view_hashed_splunk_password.yml b/detections/application/splunk_low_privilege_user_can_view_hashed_splunk_password.yml index 019a5a4b51..e58f7adafe 100644 --- a/detections/application/splunk_low_privilege_user_can_view_hashed_splunk_password.yml +++ b/detections/application/splunk_low_privilege_user_can_view_hashed_splunk_password.yml @@ -1,17 +1,29 @@ name: Splunk Low Privilege User Can View Hashed Splunk Password id: a1be424d-e59c-4583-b6f9-2dcc23be4875 -version: 1 -date: '2023-05-09' +version: 2 +date: '2024-05-29' author: Rod Soto, Eric McGinnis, Chase Franklin status: production type: Hunting data_source: - Splunk -description: In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance. -search: '`splunkd_web` uri="*/servicesNS/nobody/system/configs/conf-user-seed*" | stats earliest(_time) as event_time values(method) as method values(status) as - status values(clientip) as clientip values(useragent) as useragent values(file) as file by user | convert ctime(*time) | `splunk_low_privilege_user_can_view_hashed_splunk_password_filter`' -how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover attempts to access con-user-seed file content. -known_false_positives: This search may produce false positives as accounts with high privileges may access this file. Operator will need to investigate these actions in order to discern exploitation attempts. +description: The following analytic identifies low-privilege users attempting to view + hashed Splunk passwords by querying the conf-user-seed REST endpoint. It leverages + data from the `splunkd_web` logs, specifically monitoring access to the conf-user-seed + endpoint. This activity is significant because it can indicate an attempt to escalate + privileges by obtaining hashed credentials, potentially leading to admin account + takeover. If confirmed malicious, this could allow an attacker to gain administrative + control over the Splunk instance, compromising the entire environment's security. +search: '`splunkd_web` uri="*/servicesNS/nobody/system/configs/conf-user-seed*" | + stats earliest(_time) as event_time values(method) as method values(status) as status + values(clientip) as clientip values(useragent) as useragent values(file) as file + by user | convert ctime(*time) | `splunk_low_privilege_user_can_view_hashed_splunk_password_filter`' +how_to_implement: This detection does not require you to ingest any new data. The + detection does require the ability to search the _audit index. This detection may + assist in efforts to discover attempts to access con-user-seed file content. +known_false_positives: This search may produce false positives as accounts with high + privileges may access this file. Operator will need to investigate these actions + in order to discern exploitation attempts. references: - https://advisory.splunk.com/ tags: @@ -28,23 +40,24 @@ tags: - name: clientip type: IP Address role: - - Attacker + - Attacker product: - Splunk Enterprise risk_score: 81 required_fields: - - _time - - clientip - - useragent - - file - - user - - method - - status + - _time + - clientip + - useragent + - file + - user + - method + - status security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1212/splunk/splunk_low_privilege_user_can_view_hashed_splunk_password.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1212/splunk/splunk_low_privilege_user_can_view_hashed_splunk_password.log source: /opt/splunk/var/log/splunk/web_access.log sourcetype: splunk_web_access custom_index: _internal diff --git a/detections/application/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.yml b/detections/application/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.yml index a9d1e37322..5ca71945e7 100644 --- a/detections/application/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.yml +++ b/detections/application/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.yml @@ -1,23 +1,35 @@ name: Splunk Path Traversal In Splunk App For Lookup File Edit id: 8ed58987-738d-4917-9e44-b8ef6ab948a6 -version: 1 -date: '2023-05-11' +version: 2 +date: '2024-05-22' author: Rod Soto, Eric McGinnis status: production type: Hunting data_source: - Splunk -description: In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance. -search: '`splunkda` uri_query=*lookup_file* | table clientip uri_query lookup_file owner namespace version | stats count by clientip namespace lookup_file uri_query | `splunk_path_traversal_in_splunk_app_for_lookup_file_edit_filter`' -how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection is meant for on premise environments, - and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests. -known_false_positives: This search may find additional path traversal exploitation attempts or malformed requests. +description: The following analytic identifies path traversal attempts in the Splunk + App for Lookup File Editing. It detects specially crafted web requests targeting + lookup files by analyzing the `uri_query` field in the `_internal` index. This activity + is significant because it allows low-privilege users to read and write to restricted + areas of the Splunk installation directory, potentially accessing sensitive files + like password hashes. If confirmed malicious, this could lead to unauthorized access, + data breaches, and further exploitation of the Splunk environment. +search: '`splunkda` uri_query=*lookup_file* | table clientip uri_query lookup_file + owner namespace version | stats count by clientip namespace lookup_file uri_query + | `splunk_path_traversal_in_splunk_app_for_lookup_file_edit_filter`' +how_to_implement: This detection does not require you to ingest any new data. The + detection does require the ability to search the _internal index. This detection + is meant for on premise environments, and if executed on internet facing servers + without a WAF may produce a lot of results. This detection will not work against + obfuscated path traversal requests. +known_false_positives: This search may find additional path traversal exploitation + attempts or malformed requests. references: - https://advisory.splunk.com/ tags: analytic_story: - Splunk Vulnerabilities - asset_type: Endpoint + asset_type: Endpoint atomic_guid: [] confidence: 80 impact: 50 @@ -34,17 +46,18 @@ tags: risk_score: 40 required_fields: - clientip - - uri_query - - event_message - - lookup_file - - owner - - method + - uri_query + - event_message + - lookup_file + - owner + - method - user security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.log - source: splunkd_access + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.log + source: splunkd_access sourcetype: splunkd_access custom_index: _internal diff --git a/detections/application/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.yml b/detections/application/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.yml index 1c76eb13d8..70038513f5 100644 --- a/detections/application/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.yml +++ b/detections/application/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.yml @@ -1,16 +1,29 @@ name: Splunk Persistent XSS Via URL Validation Bypass W Dashboard id: 8a43558f-a53c-4ee4-86c1-30b1e8ef3606 -version: 1 -date: '2023-05-09' +version: 2 +date: '2024-05-20' author: Rod Soto status: production type: Hunting data_source: - Splunk -description: In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user. The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone. -search: '`splunkd_web` method=GET uri_path="*bootstrap-2.3.1*" file="*.js" | table _time clientip uri_path file status | `splunk_persistent_xss_via_url_validation_bypass_w_dashboard_filter`' -how_to_implement: This search does not require additional data to be ingested. This search requires ability to search _internal index. This search helps discover access to vulnerable bootstrap versions. -known_false_positives: This search will produce numerous false positives as it shows ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files occur during normal Splunk usage. To reduce or eliminate false positives, update the a version of Splunk which has addressed the vulnerability. +description: The following analytic detects attempts to bypass URL validation in Splunk + Enterprise versions below 9.0.4, 8.2.10, and 8.1.13 by targeting the vulnerable + bootstrap version 2.3.1. It leverages `splunkd_web` logs, specifically monitoring + GET requests to JavaScript files within the vulnerable bootstrap path. This activity + is significant as it can allow a low-privileged user to perform path traversal, + potentially accessing restricted and confidential information. If confirmed malicious, + this could lead to unauthorized data access and compromise of sensitive information, + including targeting admin users. +search: '`splunkd_web` method=GET uri_path="*bootstrap-2.3.1*" file="*.js" | table + _time clientip uri_path file status | `splunk_persistent_xss_via_url_validation_bypass_w_dashboard_filter`' +how_to_implement: This search does not require additional data to be ingested. This + search requires ability to search _internal index. This search helps discover access + to vulnerable bootstrap versions. +known_false_positives: This search will produce numerous false positives as it shows + ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files + occur during normal Splunk usage. To reduce or eliminate false positives, update + the a version of Splunk which has addressed the vulnerability. references: - https://advisory.splunk.com/ tags: @@ -20,9 +33,9 @@ tags: atomic_guid: [] confidence: 20 impact: 80 - cve: + cve: - CVE-2019-8331 - message: Attempted access to vulnerable bootstrap file by $clientip$ + message: Attempted access to vulnerable bootstrap file by $clientip$ mitre_attack_id: - T1189 observable: @@ -34,15 +47,16 @@ tags: - Splunk Enterprise risk_score: 16 required_fields: - - file - - uri - - clientip - - user + - file + - uri + - clientip + - user security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.log source: /opt/splunk/var/log/splunk/web_access.log sourcetype: splunk_web_access custom_index: _internal diff --git a/detections/application/splunk_process_injection_forwarder_bundle_downloads.yml b/detections/application/splunk_process_injection_forwarder_bundle_downloads.yml index e57945fd6b..522879fb7d 100644 --- a/detections/application/splunk_process_injection_forwarder_bundle_downloads.yml +++ b/detections/application/splunk_process_injection_forwarder_bundle_downloads.yml @@ -1,19 +1,19 @@ name: Splunk Process Injection Forwarder Bundle Downloads id: 8ea57d78-1aac-45d2-a913-0cd603fb6e9e -version: 1 -date: '2022-05-26' +version: 2 +date: '2024-05-23' author: Lou Stella, Splunk status: production type: Hunting -description: On June 14th, 2022, Splunk released a security advisory relating to the - authentication that happens between Universal Forwarders and Deployment Servers. - In some circumstances, an unauthenticated client can download forwarder bundles - from the Deployment Server. This hunting search pulls a full list of forwarder bundle - downloads where the peer column is the forwarder, the host column is the Deployment - Server, and then you have a list of the apps downloaded and the serverclasses in - which the peer is a member of. You should look for apps or clients that you do not - recognize as being part of your environment. -data_source: +description: The following analytic identifies unauthorized forwarder bundle downloads + from Splunk Deployment Servers. It leverages native Splunk logs, specifically the + `splunkd` component "PackageDownloadRestHandler," to detect instances where an unauthenticated + client may have downloaded forwarder bundles. This activity is significant because + it could indicate a potential security breach, allowing unauthorized access to sensitive + configurations and applications. If confirmed malicious, an attacker could gain + insights into the deployment server's environment, potentially leading to further + exploitation or lateral movement within the network. +data_source: - Splunk search: '`splunkd` component="PackageDownloadRestHandler" | stats values(app) values(serverclass) by peer, host | `splunk_process_injection_forwarder_bundle_downloads_filter`' @@ -60,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/splunk_ds/splunkd.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/splunk_ds/splunkd.log source: /opt/splunk/var/log/splunk/splunkd.log sourcetype: splunkd update_timestamp: false diff --git a/detections/application/splunk_protocol_impersonation_weak_encryption_configuration.yml b/detections/application/splunk_protocol_impersonation_weak_encryption_configuration.yml index 4b58fc9be3..0af3c5f19f 100644 --- a/detections/application/splunk_protocol_impersonation_weak_encryption_configuration.yml +++ b/detections/application/splunk_protocol_impersonation_weak_encryption_configuration.yml @@ -1,19 +1,19 @@ name: Splunk Protocol Impersonation Weak Encryption Configuration id: 900892bf-70a9-4787-8c99-546dd98ce461 -version: 1 -date: '2022-05-25' +version: 2 +date: '2024-05-28' author: Lou Stella, Splunk status: production type: Hunting -description: On June 14th, 2022, Splunk released a security advisory relating to TLS - validation occuring within the httplib and urllib python libraries shipped with - Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration - settings need to be set. This search will check those configurations on the search - head it is run from as well as its search peers. In addition to these settings, - the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be - enabled as well. Other components such as additional search heads or anything this - rest command cannot be distributed to will need to be manually checked. -data_source: +description: The following analytic identifies weak encryption configurations in Splunk + related to TLS validation within the httplib and urllib Python libraries. It uses + REST API calls to check specific configuration settings on the search head and its + peers, ensuring compliance with security advisories. This activity is significant + for a SOC as weak encryption can be exploited for protocol impersonation attacks, + leading to unauthorized access. If confirmed malicious, attackers could intercept + and manipulate data, compromising the integrity and confidentiality of the Splunk + environment. +data_source: - Splunk search: '| rest /services/server/info | table splunk_server version server_roles | join splunk_server [| rest /servicesNS/nobody/search/configs/conf-server/ search="PythonSslClientConfig" @@ -66,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log source: audittrail sourcetype: audittrail update_timestamp: true diff --git a/detections/application/splunk_rce_via_serialized_session_payload.yml b/detections/application/splunk_rce_via_serialized_session_payload.yml index 94ac2224a4..e7e417f810 100644 --- a/detections/application/splunk_rce_via_serialized_session_payload.yml +++ b/detections/application/splunk_rce_via_serialized_session_payload.yml @@ -1,25 +1,26 @@ name: Splunk RCE via Serialized Session Payload id: d1d8fda6-874a-400f-82cf-dcbb59d8e4db -version: 1 -date: '2023-10-02' +version: 2 +date: '2024-05-26' author: Chase Franklin, Rod Soto, Eric McGinnis, Splunk status: production type: Hunting -description: In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that - they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use - of the 'collect' SPL command which writes a file within the Splunk Enterprise installation. The attacker can then use this file to - submit a serialized payload that can result in execution of code within the payload. Please refer to the - following URL for additional information on these disclosures - https://advisory.splunk.com -data_source: +description: The following analytic detects the execution of a specially crafted query + using the 'collect' SPL command in Splunk Enterprise versions lower than 8.2.12, + 9.0.6, and 9.1.1. It leverages audit logs to identify searches containing both 'makeresults' + and 'collect' commands. This activity is significant because it can indicate an + attempt to serialize untrusted data, potentially leading to arbitrary code execution. + If confirmed malicious, this could allow an attacker to execute code within the + Splunk environment, leading to unauthorized access and control over the system. +data_source: - Splunk -search: '`audit_searches` file=* (search="*makeresults*" AND search="*collect*") - | stats count min(_time) as firstTime max(_time) as lastTime by action file user splunk_server search - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`audit_searches` file=* (search="*makeresults*" AND search="*collect*") | + stats count min(_time) as firstTime max(_time) as lastTime by action file user splunk_server + search | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `splunk_rce_via_serialized_session_payload_filter`' how_to_implement: Requires access to the _audit index. -known_false_positives: There are numerous many uses of the 'makeresults' and 'collect' SPL commands. - Please evaluate the results of this search for potential abuse. +known_false_positives: There are numerous many uses of the 'makeresults' and 'collect' + SPL commands. Please evaluate the results of this search for potential abuse. references: - https://www.splunk.com/en_us/product-security.html tags: @@ -30,7 +31,8 @@ tags: cve: - CVE-2023-40595 impact: 50 - message: Potential abuse of the 'collect' SPL command against $splunk_server$ by detected by $user$ + message: Potential abuse of the 'collect' SPL command against $splunk_server$ by + detected by $user$ mitre_attack_id: - T1190 observable: @@ -57,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/splunk_rce_via_serialized_session_payload_audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/splunk_rce_via_serialized_session_payload_audittrail.log source: audittrail sourcetype: audittrail custom_index: _audit diff --git a/detections/application/splunk_rce_via_splunk_secure_gateway__splunk_mobile_alerts_feature.yml b/detections/application/splunk_rce_via_splunk_secure_gateway__splunk_mobile_alerts_feature.yml index 6c9e582108..0786aaca54 100644 --- a/detections/application/splunk_rce_via_splunk_secure_gateway__splunk_mobile_alerts_feature.yml +++ b/detections/application/splunk_rce_via_splunk_secure_gateway__splunk_mobile_alerts_feature.yml @@ -1,16 +1,18 @@ name: Splunk RCE via Splunk Secure Gateway Splunk Mobile alerts feature id: baa41f09-df48-4375-8991-520beea161be -version: 1 -date: '2022-10-11' +version: 2 +date: '2024-05-16' author: Rod Soto status: production type: Hunting -description: This hunting search provides information on possible exploitation attempts - against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0, - 8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands - remotely through the use of specially crafted requests to the mobile alerts feature - in the Splunk Secure Gateway app. -data_source: +description: The following analytic identifies potential exploitation attempts against + the Splunk Secure Gateway App's Mobile Alerts feature in Splunk versions 9.0, 8.2.x, + and 8.1.x. It detects suspicious activity by monitoring requests to the mobile alerts + endpoint using specific URI paths and query parameters. This activity is significant + because an authenticated user could exploit this vulnerability to execute arbitrary + operating system commands remotely. If confirmed malicious, this could lead to unauthorized + code execution, compromising the integrity and security of the Splunk environment. +data_source: - Splunk search: '`splunkda` uri_path="/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" sort="notification.created_at:-1" | table clientip file host method uri_query sort @@ -19,7 +21,8 @@ how_to_implement: This search only applies if Splunk Mobile Gateway is deployed the vulnerable Splunk versions. known_false_positives: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. Focus of this - search is "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" + search is + "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" which is the injection point. references: - https://www.splunk.com/en_us/product-security.html @@ -55,7 +58,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_rce_via_secure_gateway_splunk_mobile_alerts_feature.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_rce_via_secure_gateway_splunk_mobile_alerts_feature.txt source: /opt/splunk/var/log/splunk/splunkd_access.log sourcetype: splunkd_access custom_index: _internal diff --git a/detections/application/splunk_rce_via_user_xslt.yml b/detections/application/splunk_rce_via_user_xslt.yml index ba34faf90f..f6bd1063f7 100644 --- a/detections/application/splunk_rce_via_user_xslt.yml +++ b/detections/application/splunk_rce_via_user_xslt.yml @@ -20,8 +20,8 @@ search: '`splunkd_ui` ((uri="*NO_BINARY_CHECK=1*" AND "*input.path=*.xsl*") OR u | stats count min(_time) as firstTime max(_time) as lastTime by clientip useragent uri decoded_field action host | rename clientip as src, uri as dest_uri | iplocation src | fillnull value="N/A" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | table firstTime, lastTime src, useragent, action, count, Country, Region, City, - dest_uri, decoded_field' + | table firstTime, lastTime src, useragent, action, count, Country, Region, City, dest_uri, decoded_field + | `splunk_rce_via_user_xslt_filter`' how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. known_false_positives: This search will provide information for investigation and diff --git a/detections/application/splunk_reflected_xss_on_app_search_table_endpoint.yml b/detections/application/splunk_reflected_xss_on_app_search_table_endpoint.yml index a0d0db7a0b..012f3aa620 100644 --- a/detections/application/splunk_reflected_xss_on_app_search_table_endpoint.yml +++ b/detections/application/splunk_reflected_xss_on_app_search_table_endpoint.yml @@ -1,16 +1,29 @@ name: Splunk Reflected XSS on App Search Table Endpoint id: 182f9080-4137-4629-94ac-cb1083ac981a -version: 1 -date: '2023-09-05' +version: 2 +date: '2024-05-23' author: Rod Soto status: production type: Hunting -data_source: +data_source: - Splunk -description: In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function. -search: '`splunkd_web` (dataset_commands="*makeresults*" AND dataset_commands="*count*" AND dataset_commands="*eval*" AND dataset_commands="*baseSPL*") | stats count min(_time) as firstTime max(_time) as lastTime by clientip status user view root uri_path | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_reflected_xss_on_app_search_table_endpoint_filter`' -how_to_implement: Need access to the internal indexes. -known_false_positives: This search will produce false positives. It is necessary to also look at uri_query parameter to determine the possible malicious intention of inserting makeresults within the uri string. +description: The following analytic identifies attempts to exploit a reflected cross-site + scripting (XSS) vulnerability on the app search table endpoint in Splunk Enterprise + versions below 9.1.1, 9.0.6, and 8.2.12. It detects this activity by analyzing web + request logs for specific dataset commands (`makeresults`, `count`, `eval`, `baseSPL`) + within the `splunkd_web` index. This activity is significant because successful + exploitation can lead to the execution of arbitrary commands on the Splunk platform, + potentially compromising the entire instance. If confirmed malicious, attackers + could gain unauthorized access, execute arbitrary code, and manipulate data within + the Splunk environment. +search: '`splunkd_web` (dataset_commands="*makeresults*" AND dataset_commands="*count*" + AND dataset_commands="*eval*" AND dataset_commands="*baseSPL*") | stats count min(_time) + as firstTime max(_time) as lastTime by clientip status user view root uri_path | + `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_reflected_xss_on_app_search_table_endpoint_filter`' +how_to_implement: Need access to the internal indexes. +known_false_positives: This search will produce false positives. It is necessary to + also look at uri_query parameter to determine the possible malicious intention of + inserting makeresults within the uri string. references: - https://advisory.splunk.com/advisories/SVD-2023-0801 tags: @@ -34,17 +47,18 @@ tags: risk_score: 12 required_fields: - dataset_commands - - clientip - - status - - user - - view - - root - - uri_path + - clientip + - status + - user + - view + - root + - uri_path security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_reflected_xss_on_app_search_table_endpoint_splunk_web_access.log - source: web_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_reflected_xss_on_app_search_table_endpoint_splunk_web_access.log + source: web_access.log sourcetype: splunk_web_access custom_index: _internal diff --git a/detections/application/splunk_stored_xss_via_data_model_objectname_field.yml b/detections/application/splunk_stored_xss_via_data_model_objectname_field.yml index f7930178b9..ce012d31e8 100644 --- a/detections/application/splunk_stored_xss_via_data_model_objectname_field.yml +++ b/detections/application/splunk_stored_xss_via_data_model_objectname_field.yml @@ -1,15 +1,19 @@ name: Splunk Stored XSS via Data Model objectName field id: 062bff76-5f9c-496e-a386-cb1adcf69871 -version: 1 -date: '2022-10-11' +version: 2 +date: '2024-05-17' author: Rod Soto status: production type: Hunting -description: Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent - cross site scripting via Data Model object name. An authenticated user can inject - and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) - in the object name Data Model. -data_source: +description: The following analytic identifies attempts to exploit a stored cross-site + scripting (XSS) vulnerability in Splunk Enterprise via the Data Model object name + field. It detects this activity by analyzing web access logs (`splunkd_webx`) for + specific URI patterns and non-null query parameters. This activity is significant + because it allows authenticated users to inject and store malicious scripts, leading + to persistent XSS attacks. If confirmed malicious, this could enable attackers to + execute arbitrary scripts in the context of other users, potentially leading to + data theft, session hijacking, or further compromise of the Splunk environment. +data_source: - Splunk search: '`splunkd_webx` uri=/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model* uri_query!=null | stats count by _time host status clientip user uri | `splunk_stored_xss_via_data_model_objectname_field_filter`' @@ -56,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_stored_xss_via_data_model_objectname_field.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_stored_xss_via_data_model_objectname_field.txt source: /opt/splunk/var/log/splunk/web_access.log sourcetype: splunk_web_access custom_index: _internal diff --git a/detections/application/splunk_unauthenticated_log_injection_web_service_log.yml b/detections/application/splunk_unauthenticated_log_injection_web_service_log.yml index 1d91b02d5b..b69f9adcfb 100644 --- a/detections/application/splunk_unauthenticated_log_injection_web_service_log.yml +++ b/detections/application/splunk_unauthenticated_log_injection_web_service_log.yml @@ -1,26 +1,37 @@ name: Splunk Unauthenticated Log Injection Web Service Log id: de3908dc-1298-446d-84b9-fa81d37e959b -version: 1 -date: '2023-07-13' +version: 2 +date: '2024-05-19' author: Rod Soto status: production type: Hunting -data_source: +data_source: - Splunk -description: An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server. -search: '`splunkd_webx` uri_path IN ("*\x1B*", "*\u001b*", "*\033*", "*\0x9*", "*\0x8*") | stats count by uri_path method host status clientip | `splunk_unauthenticated_log_injection_web_service_log_filter`' -how_to_implement: This only affects web enabled Splunk instances. The detection does require the ability to search the _internal index. -known_false_positives: This hunting search will produce false positives if ANSI escape characters are included in URLs either voluntarily or by accident. This search will not detect obfuscated ANSI characters. +description: The following analytic identifies potential log injection attempts into + the Splunk server via specially crafted web URLs. It detects ANSI escape codes within + the `uri_path` field of `splunkd_webx` logs. This activity is significant as it + can lead to log file manipulation, potentially obfuscating malicious actions or + misleading analysts. If confirmed malicious, an attacker could manipulate log files + to hide their tracks or execute further attacks, compromising the integrity of the + logging system and making incident response more challenging. +search: '`splunkd_webx` uri_path IN ("*\x1B*", "*\u001b*", "*\033*", "*\0x9*", "*\0x8*") + | stats count by uri_path method host status clientip | `splunk_unauthenticated_log_injection_web_service_log_filter`' +how_to_implement: This only affects web enabled Splunk instances. The detection does + require the ability to search the _internal index. +known_false_positives: This hunting search will produce false positives if ANSI escape + characters are included in URLs either voluntarily or by accident. This search will + not detect obfuscated ANSI characters. references: -- https://advisory.splunk.com/advisories/SVD-2023-0606 +- https://advisory.splunk.com/advisories/SVD-2023-0606 tags: analytic_story: - Splunk Vulnerabilities asset_type: Endpoint confidence: 30 impact: 30 - message: Possible Splunk unauthenticated log injection web service log exploitation attempt against $host$ from $clientip$ - cve: + message: Possible Splunk unauthenticated log injection web service log exploitation + attempt against $host$ from $clientip$ + cve: - CVE-2023-32712 mitre_attack_id: - T1190 @@ -41,15 +52,16 @@ tags: required_fields: - method - uri_path - - host - - status - - clientip + - host + - status + - clientip security_domain: endpoint tests: - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/web_access.log + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/web_access.log source: /opt/splunk/var/log/splunk/web_access.log custom_index: _internal sourcetype: splunk_web_access - + diff --git a/detections/application/splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads.yml b/detections/application/splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads.yml index e21ddae906..e54983f982 100644 --- a/detections/application/splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads.yml +++ b/detections/application/splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads.yml @@ -1,56 +1,67 @@ name: Splunk unnecessary file extensions allowed by lookup table uploads id: b7d1293f-e78f-415e-b5f6-443df3480082 -version: 1 -date: "2023-02-14" +version: 2 +date: "2024-05-28" author: Rod Soto, Splunk type: TTP status: production -data_source: +data_source: - Splunk -description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads. -search: - '`splunkda` method IN ("POST", "DELETE") uri_path=/servicesNS/*/ui/views/* - | eval activity = case( method=="POST" AND like( uri_path , "%/acl" ) , "Permissions Update", method=="POST" AND NOT like( uri_path , "%/acl" ) , "Edited" , method=="DELETE" , "Deleted" ) - | rex field=uri_path "(?.*?)\/ui\/views/(?.*)" - | eval dashboard = urldecode( dashboard_encoded ) - | table _time, uri_path, user, dashboard, activity, uri_path - | `splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads_filter`' +description: The following analytic identifies user activity related to uploading + lookup tables with unnecessary filename extensions in Splunk Enterprise versions + below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods + (POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This + behavior is significant because it can indicate attempts to upload potentially malicious + files disguised as lookup tables. If confirmed malicious, this activity could allow + an attacker to execute unauthorized code or manipulate data within the Splunk environment, + leading to potential data breaches or system compromise. +search: '`splunkda` method IN ("POST", "DELETE") uri_path=/servicesNS/*/ui/views/* + | eval activity = case( method=="POST" AND like( uri_path , "%/acl" ) , "Permissions + Update", method=="POST" AND NOT like( uri_path , "%/acl" ) , "Edited" , method=="DELETE" + , "Deleted" ) | rex field=uri_path "(?.*?)\/ui\/views/(?.*)" + | eval dashboard = urldecode( dashboard_encoded ) | table _time, uri_path, user, + dashboard, activity, uri_path | `splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads_filter`' how_to_implement: Requires access to internal splunkd_access. -known_false_positives: This is a hunting search, the search provides information on upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary after executing search. This search will produce false positives as payload cannot be directly discerned. +known_false_positives: This is a hunting search, the search provides information on + upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary + after executing search. This search will produce false positives as payload cannot + be directly discerned. references: - - https://www.splunk.com/en_us/product-security.html +- https://www.splunk.com/en_us/product-security.html tags: analytic_story: - - Splunk Vulnerabilities + - Splunk Vulnerabilities asset_type: Endpoint cve: - - CVE-2023-22937 + - CVE-2023-22937 confidence: 50 dataset: - - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log impact: 50 - message: Potential lookup template injection attempt from $user$ on lookup table at path $uri_path$ + message: Potential lookup template injection attempt from $user$ on lookup table + at path $uri_path$ mitre_attack_id: - - T1189 + - T1189 observable: - - name: user - type: User - role: - - Victim + - name: user + type: User + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - user - - method - - uri_path + - user + - method + - uri_path risk_score: 25 security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log source: /opt/splunk/var/log/splunk/splunkd_access.log sourcetype: splunkd_access - custom_index: _internal \ No newline at end of file + custom_index: _internal diff --git a/detections/application/splunk_user_enumeration_attempt.yml b/detections/application/splunk_user_enumeration_attempt.yml index fab150417e..d4fcbacb3a 100644 --- a/detections/application/splunk_user_enumeration_attempt.yml +++ b/detections/application/splunk_user_enumeration_attempt.yml @@ -1,19 +1,22 @@ name: Splunk User Enumeration Attempt id: 25625cb4-1c4d-4463-b0f9-7cb462699cde -version: 2 -date: '2024-03-19' +version: 3 +date: '2024-05-21' author: Lou Stella, Splunk status: production type: TTP -description: On May 3rd, 2022, Splunk published a security advisory for username - enumeration stemming from verbose login failure messages present on some REST endpoints. - This detection will alert on attempted exploitation in patched versions of Splunk - as well as actual exploitation in unpatched version of Splunk. -data_source: +description: The following analytic identifies attempts to enumerate usernames in + Splunk by detecting multiple failed authentication attempts from the same source. + It leverages data from the `_audit` index, specifically focusing on failed authentication + events. This activity is significant for a SOC because it can indicate an attacker + trying to discover valid usernames, which is a precursor to more targeted attacks + like password spraying or brute force attempts. If confirmed malicious, this activity + could lead to unauthorized access, compromising the security of the Splunk environment + and potentially exposing sensitive data. +data_source: - Splunk search: ' `splunkd_failed_auths` | stats count(user) as auths by user, src | where - auths>5 | stats values(user) as user, sum(auths) as TotalFailedAuths by src | - `splunk_user_enumeration_attempt_filter`' + auths>5 | stats values(user) as user, sum(auths) as TotalFailedAuths by src | `splunk_user_enumeration_attempt_filter`' how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to find password spraying or brute force authorization attempts @@ -56,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/splunkd_auth/audittrail.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/splunkd_auth/audittrail.log source: audittrail sourcetype: audittrail custom_index: _audit diff --git a/detections/application/splunk_xss_in_highlighted_json_events.yml b/detections/application/splunk_xss_in_highlighted_json_events.yml index 739b61e97b..b9dafdd9f8 100644 --- a/detections/application/splunk_xss_in_highlighted_json_events.yml +++ b/detections/application/splunk_xss_in_highlighted_json_events.yml @@ -1,28 +1,34 @@ name: Splunk XSS in Highlighted JSON Events id: 1030bc63-0b37-4ac9-9ae0-9361c955a3cc -version: 1 -date: '2023-11-16' +version: 2 +date: '2024-05-28' author: Rod Soto, Splunk status: production type: Hunting -data_source: +data_source: - Splunk -description: This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2. - The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript - in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the - logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment. -search: '`splunkd_ui` "/en-US/splunkd/__raw/servicesNS/nobody/search/authentication/users" status=201 - | stats count min(_time) as firstTime max(_time) as lastTime by clientip, uri_path, method - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies potential exploitation of a Cross-Site + Scripting (XSS) vulnerability in Splunk Enterprise 9.1.2. It detects suspicious + requests to the Splunk web GUI that may execute JavaScript within script tags. This + detection leverages logs from the `splunkd_ui` data source, focusing on specific + URI paths and HTTP methods. This activity is significant as it can allow attackers + to execute arbitrary JavaScript, potentially accessing the API with the logged-in + user's permissions. If the user is an admin, the attacker could create an admin + account, leading to full control over the Splunk environment. +search: '`splunkd_ui` "/en-US/splunkd/__raw/servicesNS/nobody/search/authentication/users" + status=201 | stats count min(_time) as firstTime max(_time) as lastTime by clientip, + uri_path, method | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `splunk_xss_in_highlighted_json_events_filter`' -how_to_implement: This search only applies to web-GUI-enabled Splunk instances and operator must have access to internal indexes. -known_false_positives: This is a hunting search and will produce false positives as it is not possible to view contents of a request - payload. It shows the artifact resulting from a potential exploitation payload (the creation of a user with admin privileges). +how_to_implement: This search only applies to web-GUI-enabled Splunk instances and + operator must have access to internal indexes. +known_false_positives: This is a hunting search and will produce false positives as + it is not possible to view contents of a request payload. It shows the artifact + resulting from a potential exploitation payload (the creation of a user with admin + privileges). references: -- https://advisory.splunk.com/advisories +- https://advisory.splunk.com/advisories cve: - - CVE-2023-46213 +- CVE-2023-46213 tags: analytic_story: - Splunk Vulnerabilities @@ -31,27 +37,28 @@ tags: impact: 30 message: Possible XSS exploitation from $clientip$ mitre_attack_id: - - T1189 + - T1189 observable: - - name: clientip - type: IP Address - role: - - Attacker + - name: clientip + type: IP Address + role: + - Attacker product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud risk_score: 15 required_fields: - - clientip - - uri_path - - method - - status + - clientip + - uri_path + - method + - status security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_highlighted_json_events_splunkd_ui_access.log - source: splunkd_ui_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_highlighted_json_events_splunkd_ui_access.log + source: splunkd_ui_access.log sourcetype: splunkd_ui_access - custom_index: _internal \ No newline at end of file + custom_index: _internal diff --git a/detections/application/splunk_xss_in_monitoring_console.yml b/detections/application/splunk_xss_in_monitoring_console.yml index fe1b93e156..33c0828bd7 100644 --- a/detections/application/splunk_xss_in_monitoring_console.yml +++ b/detections/application/splunk_xss_in_monitoring_console.yml @@ -1,15 +1,17 @@ name: Splunk XSS in Monitoring Console id: b11accac-6fa3-4103-8a1a-7210f1a67087 -version: 1 -date: '2022-04-27' +version: 2 +date: '2024-05-17' author: Lou Stella, Splunk status: experimental type: TTP -description: On May 3rd, 2022, Splunk published a security advisory for a reflective - Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation - in the Distributed Monitoring Console app. This detection will alert on attempted - exploitation in patched versions of Splunk as well as actual exploitation in unpatched - version of Splunk. +description: The following analytic identifies attempts to exploit a reflective Cross-Site + Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app. + It detects GET requests with suspicious query parameters by analyzing `splunkd_web` + logs in the _internal index. This activity is significant because it targets a known + vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts + in the context of the user's browser. If confirmed malicious, this could lead to + unauthorized actions, data theft, or further compromise of the Splunk environment. data_source: [] search: ' `splunkd_web` method="GET" uri_query="description=%3C*" | table _time host status clientip user uri | `splunk_xss_in_monitoring_console_filter`' @@ -52,6 +54,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/xss/splunk_web_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/xss/splunk_web_access.log source: /opt/splunk/var/log/splunk/web_access.log sourcetype: splunk_web_access diff --git a/detections/application/splunk_xss_in_save_table_dialog_header_in_search_page.yml b/detections/application/splunk_xss_in_save_table_dialog_header_in_search_page.yml index 5402027fba..0170ae5774 100644 --- a/detections/application/splunk_xss_in_save_table_dialog_header_in_search_page.yml +++ b/detections/application/splunk_xss_in_save_table_dialog_header_in_search_page.yml @@ -1,15 +1,19 @@ name: Splunk XSS in Save table dialog header in search page id: a974d1ee-ddca-4837-b6ad-d55a8a239c20 -version: 1 -date: '2022-10-11' +version: 2 +date: '2024-05-27' author: Rod Soto status: production type: Hunting -description: This is a hunting search to find persistent cross-site scripting XSS - code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise - (8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code - that can lead to persistent cross site scripting. -data_source: +description: The following analytic identifies persistent cross-site scripting (XSS) + attempts in the 'Save Table' dialog on the Splunk search page. It detects POST requests + to the endpoint `/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model` + containing potential XSS payloads. This activity is significant because it can allow + a remote user with the "power" role to inject malicious scripts, leading to persistent + XSS vulnerabilities. If confirmed malicious, this could enable attackers to execute + arbitrary scripts in the context of the affected user, potentially leading to data + theft, session hijacking, or further exploitation within the Splunk environment. +data_source: - Splunk search: '`splunkd_webx` method=POST uri=/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model | table _time host status clientip user uri | `splunk_xss_in_save_table_dialog_header_in_search_page_filter`' @@ -55,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_save_table_dialog_in_search_page.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_save_table_dialog_in_search_page.txt source: /opt/splunk/var/log/splunk/web_access.log sourcetype: splunk_web_access custom_index: _internal diff --git a/detections/application/splunk_xss_via_view.yml b/detections/application/splunk_xss_via_view.yml index 183f530cef..c4271c50a6 100644 --- a/detections/application/splunk_xss_via_view.yml +++ b/detections/application/splunk_xss_via_view.yml @@ -1,16 +1,20 @@ name: Splunk XSS via View id: 9ac2bfea-a234-4a18-9d37-6d747e85c2e4 -version: 1 -date: '2023-02-07' +version: 2 +date: '2024-05-13' author: Rod Soto, Eric McGinnis, Splunk status: production type: Hunting -description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View - allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute - in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. - This hunting search shows users action, application and role used for creating views - related to this vulnerability. -data_source: +description: The following analytic identifies potential Cross-Site Scripting (XSS) + attempts via the 'layoutPanel' attribute in the 'module' tag within XML Views in + Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It leverages internal + logs from "splunk_web_service" and "splunk_python" sourcetypes, focusing on messages + containing "loadParams." This activity is significant as it can lead to unauthorized + script execution within the Splunk Web interface, potentially compromising the security + of the instance. If confirmed malicious, attackers could execute arbitrary scripts, + leading to data theft, session hijacking, or further exploitation of the Splunk + environment. +data_source: - Splunk search: 'index = _internal sourcetype IN ("splunk_web_service", "splunk_python") message="*loadParams*" | `security_content_ctime(_time)` | table _time message fileName | `splunk_xss_via_view_filter`' @@ -52,7 +56,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_via_view.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_via_view.log source: /opt/splunk/var/log/splunk/web_service.log sourcetype: splunk_web_service custom_index: _internal diff --git a/detections/application/suspicious_email_attachment_extensions.yml b/detections/application/suspicious_email_attachment_extensions.yml index deda2074fd..964deb407c 100644 --- a/detections/application/suspicious_email_attachment_extensions.yml +++ b/detections/application/suspicious_email_attachment_extensions.yml @@ -1,18 +1,18 @@ name: Suspicious Email Attachment Extensions id: 473bd65f-06ca-4dfe-a2b8-ba04ab4a0084 -version: 3 -date: '2023-04-14' +version: 4 +date: '2024-05-29' author: David Dorsey, Splunk status: experimental type: Anomaly description: |- - The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack. + The following analytic detects emails containing attachments with suspicious file extensions. It leverages the Email data model in Splunk, using the tstats command to identify emails where the attachment filename is not empty. This detection is significant for SOC analysts as it highlights potential phishing or malware delivery attempts, which are common vectors for data breaches and malware infections. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, system compromise, or data exfiltration. Immediate review and analysis of the identified emails and attachments are crucial to mitigate these risks. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Email where All_Email.file_name="*" by All_Email.src_user, All_Email.file_name All_Email.message_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Email")` | `suspicious_email_attachments` - | `suspicious_email_attachment_extensions_filter` ' + | `suspicious_email_attachment_extensions_filter`' how_to_implement: You need to ingest data from emails. Specifically, the sender's address and the file names of any attachments must be mapped to the Email data model. diff --git a/detections/application/web_servers_executing_suspicious_processes.yml b/detections/application/web_servers_executing_suspicious_processes.yml index f3541da280..f9cd51422a 100644 --- a/detections/application/web_servers_executing_suspicious_processes.yml +++ b/detections/application/web_servers_executing_suspicious_processes.yml @@ -1,12 +1,12 @@ name: Web Servers Executing Suspicious Processes id: ec3b7601-689a-4463-94e0-c9f45638efb9 -version: 1 -date: '2019-04-01' +version: 2 +date: '2024-05-11' author: David Dorsey, Splunk status: experimental type: TTP description: |- - The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack. + The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats. data_source: - Sysmon Event ID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/cloud/abnormally_high_number_of_cloud_instances_destroyed.yml b/detections/cloud/abnormally_high_number_of_cloud_instances_destroyed.yml index 725b0e7dcd..aea878fa80 100644 --- a/detections/cloud/abnormally_high_number_of_cloud_instances_destroyed.yml +++ b/detections/cloud/abnormally_high_number_of_cloud_instances_destroyed.yml @@ -1,13 +1,18 @@ name: Abnormally High Number Of Cloud Instances Destroyed id: ef629fc9-1583-4590-b62a-f2247fbf7bbf -version: 1 -date: '2020-08-21' +version: 2 +date: '2024-05-27' author: David Dorsey, Splunk status: experimental type: Anomaly -description: This search finds for the number successfully destroyed cloud instances - for every 4 hour block. This is split up between weekdays and the weekend. It then - applies the probability densitiy model previously created and alerts on any outliers. +description: The following analytic identifies an abnormally high number of cloud + instances being destroyed within a 4-hour period. It leverages cloud infrastructure + logs and applies a probability density model to detect outliers. This activity is + significant for a SOC because a sudden spike in destroyed instances could indicate + malicious activity, such as an insider threat or a compromised account attempting + to disrupt services. If confirmed malicious, this could lead to significant operational + disruptions, data loss, and potential financial impact due to the destruction of + critical cloud resources. data_source: [] search: '| tstats count as instances_destroyed values(All_Changes.object_id) as object_id from datamodel=Change where All_Changes.action=deleted AND All_Changes.status=success diff --git a/detections/cloud/abnormally_high_number_of_cloud_instances_launched.yml b/detections/cloud/abnormally_high_number_of_cloud_instances_launched.yml index 3562a72081..21ab397c4f 100644 --- a/detections/cloud/abnormally_high_number_of_cloud_instances_launched.yml +++ b/detections/cloud/abnormally_high_number_of_cloud_instances_launched.yml @@ -1,13 +1,17 @@ name: Abnormally High Number Of Cloud Instances Launched id: f2361e9f-3928-496c-a556-120cd4223a65 -version: 2 -date: '2020-08-21' +version: 3 +date: '2024-05-16' author: David Dorsey, Splunk status: experimental type: Anomaly -description: This search finds for the number successfully created cloud instances - for every 4 hour block. This is split up between weekdays and the weekend. It then - applies the probability densitiy model previously created and alerts on any outliers. +description: The following analytic detects an abnormally high number of cloud instances + launched within a 4-hour period. It leverages cloud infrastructure logs and applies + a probability density model to identify outliers based on historical data. This + activity is significant for a SOC because a sudden spike in instance creation could + indicate unauthorized access or misuse of cloud resources. If confirmed malicious, + this behavior could lead to resource exhaustion, increased costs, or provide attackers + with additional compute resources to further their objectives. data_source: [] search: '| tstats count as instances_launched values(All_Changes.object_id) as object_id from datamodel=Change where (All_Changes.action=created) AND All_Changes.status=success diff --git a/detections/cloud/amazon_eks_kubernetes_cluster_scan_detection.yml b/detections/cloud/amazon_eks_kubernetes_cluster_scan_detection.yml index cdf7ea4299..f9ea6826ae 100644 --- a/detections/cloud/amazon_eks_kubernetes_cluster_scan_detection.yml +++ b/detections/cloud/amazon_eks_kubernetes_cluster_scan_detection.yml @@ -18,7 +18,7 @@ search: '`aws_cloudwatchlogs_eks` "user.username"="system:anonymous" userAgent!= max(_time) as lastTime values(responseStatus.reason) values(source) as cluster_name values(responseStatus.code) values(userAgent) as http_user_agent values(verb) values(requestURI) by src_ip user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` - |`amazon_eks_kubernetes_cluster_scan_detection_filter` ' + |`amazon_eks_kubernetes_cluster_scan_detection_filter`' how_to_implement: You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudWatch EKS Logs inputs. diff --git a/detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml b/detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml index 02d44cdb96..fade7ab0fe 100644 --- a/detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml +++ b/detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml @@ -1,19 +1,19 @@ name: Amazon EKS Kubernetes Pod scan detection id: dbfca1dd-b8e5-4ba4-be0e-e565e5d62002 -version: 1 -date: '2020-04-15' +version: 2 +date: '2024-05-29' author: Rod Soto, Splunk status: experimental type: Hunting description: |- - The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action. Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts. + The following analytic detects unauthenticated requests made against the Kubernetes Pods API, indicating potential unauthorized access attempts. It leverages the `aws_cloudwatchlogs_eks` data source, filtering for events where `user.username` is "system:anonymous", `verb` is "list", and `objectRef.resource` is "pods", with `requestURI` set to "/api/v1/pods". This activity is significant as it may signal attempts to access sensitive resources or execute unauthorized commands within the Kubernetes environment. If confirmed malicious, such access could lead to data compromise, unauthorized command execution, or lateral movement within the cluster. data_source: [] search: '`aws_cloudwatchlogs_eks` "user.username"="system:anonymous" verb=list objectRef.resource=pods requestURI="/api/v1/pods" | rename source as cluster_name sourceIPs{} as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason) values(responseStatus.code) values(userAgent) values(verb) values(requestURI) by src_ip cluster_name user.username user.groups{} | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter` ' + | `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter`' how_to_implement: You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on forAWS (version 4.4.0 or later), then configure your AWS CloudWatch EKS Logs.Please also customize the `kubernetes_pods_aws_scan_fingerprint_detection` diff --git a/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml b/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml index b3e2636cd3..2edc3ae569 100644 --- a/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml +++ b/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml @@ -1,21 +1,19 @@ name: ASL AWS Concurrent Sessions From Different Ips id: b3424bbe-3204-4469-887b-ec144483a336 -version: 2 -date: '2024-02-13' +version: 3 +date: '2024-05-24' author: Patrick Bareiss, Splunk status: production type: Anomaly description: The following analytic identifies an AWS IAM account with concurrent - sessions coming from more than one unique IP address within the span of 5 minutes. - This behavior could represent a session hijacking attack whereby an adversary has - extracted cookies from a victims browser and is using them from a different location - to access corporate online resources. When a user navigates the AWS Console after - authentication, the API call with the event name `DescribeEventAggregates` is registered - in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event - name to identify 2 concurrent sessions. The presence of this event occurring from - two different IP addresses is highly unlikely. As users may behave differently across - organizations, security teams should test and customize this detection to fit their - environments. + sessions originating from more than one unique IP address within a 5-minute span. + This detection leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` + API call, to identify multiple IP addresses associated with the same user session. + This behavior is significant as it may indicate a session hijacking attack, where + an adversary uses stolen session cookies to access AWS resources from a different + location. If confirmed malicious, this activity could allow unauthorized access + to sensitive corporate resources, leading to potential data breaches or further + exploitation. data_source: [] search: ' `amazon_security_lake` api.operation=DescribeEventAggregates "http_request.user_agent"!="AWS Internal" "src_endpoint.domain"!="health.amazonaws.com" | eval time = time/pow(10,3) @@ -24,7 +22,7 @@ search: ' `amazon_security_lake` api.operation=DescribeEventAggregates "http_req | stats values(src_endpoint.ip) as src_ip dc(src_endpoint.ip) as distinct_ip_count values(cloud.region) as cloud.region by time api.operation actor.user.account_uid actor.user.uid | where distinct_ip_count > 1 | rename cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id, actor.user.uid as user -| `aws_concurrent_sessions_from_different_ips_filter`' +| `asl_aws_concurrent_sessions_from_different_ips_filter`' how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or @@ -43,7 +41,8 @@ tags: asset_type: AWS Account confidence: 60 impact: 70 - message: User $user$ has concurrent sessions from more than one unique IP address in the span of 5 minutes. + message: User $user$ has concurrent sessions from more than one unique IP address + in the span of 5 minutes. mitre_attack_id: - T1185 observable: @@ -61,8 +60,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -73,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/asl_aws_defense_evasion_delete_cloudtrail.yml b/detections/cloud/asl_aws_defense_evasion_delete_cloudtrail.yml index 34ed4b08e8..4b958baf05 100644 --- a/detections/cloud/asl_aws_defense_evasion_delete_cloudtrail.yml +++ b/detections/cloud/asl_aws_defense_evasion_delete_cloudtrail.yml @@ -1,26 +1,30 @@ name: ASL AWS Defense Evasion Delete Cloudtrail id: 1f0b47e5-0134-43eb-851c-e3258638945e -version: 3 -date: '2024-02-12' +version: 4 +date: '2024-05-29' author: Patrick Bareiss, Splunk status: production type: TTP -description: The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate - an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps - in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries - to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a - Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks, - making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, - as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts. +description: The following analytic detects AWS `DeleteTrail` events within CloudTrail + logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema + Framework (OCSF) format to identify when a CloudTrail is deleted. This activity + is significant because adversaries may delete CloudTrail logs to evade detection + and operate with stealth. If confirmed malicious, this action could allow attackers + to cover their tracks, making it difficult to trace their activities and investigate + other potential compromises within the AWS environment. data_source: [] -search: '`amazon_security_lake` api.operation=DeleteTrail | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`| +search: '`amazon_security_lake` api.operation=DeleteTrail | fillnull | stats count + min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid + actor.user.uid http_request.user_agent src_endpoint.ip cloud.region | rename actor.user.uid + as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent + as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| `asl_aws_defense_evasion_delete_cloudtrail_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity. references: @@ -50,8 +54,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/asl_aws_defense_evasion_delete_cloudwatch_log_group.yml b/detections/cloud/asl_aws_defense_evasion_delete_cloudwatch_log_group.yml index 30ccae16b4..c9b279013a 100644 --- a/detections/cloud/asl_aws_defense_evasion_delete_cloudwatch_log_group.yml +++ b/detections/cloud/asl_aws_defense_evasion_delete_cloudwatch_log_group.yml @@ -1,26 +1,31 @@ name: ASL AWS Defense Evasion Delete CloudWatch Log Group id: 0f701b38-a0fb-43fd-a83d-d12265f71f33 -version: 2 -date: '2024-02-12' +version: 3 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: production type: TTP -description: The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs. - This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch. - By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a - compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an - attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments. - The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities, - hindering incident response and forensics efforts. +description: The following analytic detects the deletion of CloudWatch log groups + in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method + leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant + because attackers may delete log groups to evade detection and disrupt logging capabilities, + hindering incident response efforts. If confirmed malicious, this action could allow + attackers to cover their tracks, making it difficult to trace their activities and + potentially leading to undetected data breaches or further malicious actions within + the compromised AWS environment. data_source: [] -search: '`amazon_security_lake` api.operation=DeleteLogGroup | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`| +search: '`amazon_security_lake` api.operation=DeleteLogGroup | fillnull | stats count + min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid + actor.user.uid http_request.user_agent src_endpoint.ip cloud.region | rename actor.user.uid + as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent + as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| `asl_aws_defense_evasion_delete_cloudwatch_log_group_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity. references: @@ -50,8 +55,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/asl_ocsf_cloudtrail.json source: aws_asl sourcetype: aws:cloudtrail:lake diff --git a/detections/cloud/asl_aws_defense_evasion_impair_security_services.yml b/detections/cloud/asl_aws_defense_evasion_impair_security_services.yml index ea859b18fa..5dd6005f28 100644 --- a/detections/cloud/asl_aws_defense_evasion_impair_security_services.yml +++ b/detections/cloud/asl_aws_defense_evasion_impair_security_services.yml @@ -1,27 +1,31 @@ name: ASL AWS Defense Evasion Impair Security Services id: 5029b681-0462-47b7-82e7-f7e3d37f5a2d -version: 2 -date: '2024-02-12' +version: 3 +date: '2024-05-13' author: Patrick Bareiss, Bhavin Patel, Gowthamaraj Rajendran, Splunk status: production type: Hunting -description: The following analytic detects the deletion of critical AWS Security Services configurations through specific API calls - to services like CloudWatch, GuardDuty, and Web Application Firewalls. By monitoring for these deletion actions, the analytic aims - to identify attempts by adversaries to undermine security defenses, such as erasing logging configurations or removing detection mechanisms. - This behavior is crucial for a Security Operations Center (SOC) to identify as it can indicate an attacker's intent to operate - undetected by eliminating evidence of their presence and activities. The impact of such attacks is significant, potentially leaving - the environment vulnerable to further exploitation without any traceable logs or alerts. +description: The following analytic detects the deletion of critical AWS Security + Services configurations, such as CloudWatch alarms, GuardDuty detectors, and Web + Application Firewall rules. It leverages Amazon Security Lake logs to identify specific + API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant + because adversaries often use these actions to disable security monitoring and evade + detection. If confirmed malicious, this could allow attackers to operate undetected, + leading to potential data breaches, unauthorized access, and prolonged persistence + within the AWS environment. data_source: [] -search: '`amazon_security_lake` api.operation IN ("DeleteLogStream","DeleteDetector","DeleteIPSet","DeleteWebACL","DeleteRule","DeleteRuleGroup","DeleteLoggingConfiguration","DeleteAlarms") | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `asl_aws_defense_evasion_impair_security_services_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +search: '`amazon_security_lake` api.operation IN ("DeleteLogStream","DeleteDetector","DeleteIPSet","DeleteWebACL","DeleteRule","DeleteRuleGroup","DeleteLoggingConfiguration","DeleteAlarms") + | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by api.operation + actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region + | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, + http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_defense_evasion_impair_security_services_filter`' +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. @@ -55,8 +59,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -66,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/asl_aws_iam_delete_policy.yml b/detections/cloud/asl_aws_iam_delete_policy.yml index 411e5c45f1..102a00c7cf 100644 --- a/detections/cloud/asl_aws_iam_delete_policy.yml +++ b/detections/cloud/asl_aws_iam_delete_policy.yml @@ -1,24 +1,29 @@ name: ASL AWS IAM Delete Policy id: 609ced68-d420-4ff7-8164-ae98b4b4018c -version: 2 -date: '2024-02-13' +version: 3 +date: '2024-05-22' author: Patrick Bareiss, Splunk status: production type: Hunting -description: The following analytic detects the deletion of an AWS policy, a critical action that could indicate an attempt to alter permissions - or reduce security controls. By monitoring AWS logs for `DeletePolicy` events, this analytic identifies both successful and attempted deletions, - providing insights into potentially malicious activities. Identifying such behavior is crucial for a Security Operations Center (SOC) as it may - signal an adversary's effort to escalate privileges or evade detection. The impact of unauthorized policy deletion is significant, - potentially leading to compromised accounts or data exposure. +description: The following analytic identifies when a policy is deleted in AWS. It + leverages Amazon Security Lake logs to detect the DeletePolicy API operation. Monitoring + policy deletions is crucial as it can indicate unauthorized attempts to weaken security + controls. If confirmed malicious, this activity could allow an attacker to remove + critical security policies, potentially leading to privilege escalation or unauthorized + access to sensitive resources. data_source: [] -search: '`amazon_security_lake` api.operation=DeletePolicy | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id +search: '`amazon_security_lake` api.operation=DeletePolicy | fillnull | stats count + min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid + actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region + | rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region, + http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_iam_delete_policy_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to @@ -51,8 +56,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -62,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/asl_aws_multi_factor_authentication_disabled.yml b/detections/cloud/asl_aws_multi_factor_authentication_disabled.yml index 687dad9523..eb58b23a3a 100644 --- a/detections/cloud/asl_aws_multi_factor_authentication_disabled.yml +++ b/detections/cloud/asl_aws_multi_factor_authentication_disabled.yml @@ -1,26 +1,31 @@ name: ASL AWS Multi-Factor Authentication Disabled id: 4d2df5e0-1092-4817-88a8-79c7fa054668 -version: 2 -date: '2024-02-13' +version: 3 +date: '2024-05-22' author: Patrick Bareiss, Splunk status: production type: TTP -description: The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for - specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a - Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more - vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with - less risk of detection, facilitating further malicious activities. +description: The following analytic detects attempts to disable multi-factor authentication + (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically + monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. + This activity is significant as disabling MFA can indicate an adversary attempting + to weaken account security to maintain persistence using a compromised account. + If confirmed malicious, this action could allow attackers to retain access to the + AWS environment without detection, potentially leading to unauthorized access to + sensitive resources and prolonged compromise. data_source: [] -search: '`amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.operation=DeactivateMFADevice) | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `asl_aws_multi_factor_authentication_disabled_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +search: '`amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.operation=DeactivateMFADevice) + | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by api.operation + actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region + | rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, + http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_multi_factor_authentication_disabled_filter`' +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company references: @@ -54,8 +59,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -65,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/asl_aws_new_mfa_method_registered_for_user.yml b/detections/cloud/asl_aws_new_mfa_method_registered_for_user.yml index 065fbc79b7..526f66fd1c 100644 --- a/detections/cloud/asl_aws_new_mfa_method_registered_for_user.yml +++ b/detections/cloud/asl_aws_new_mfa_method_registered_for_user.yml @@ -1,26 +1,31 @@ name: ASL AWS New MFA Method Registered For User id: 33ae0931-2a03-456b-b1d7-b016c5557fbd -version: 2 -date: '2024-02-13' +version: 3 +date: '2024-05-18' author: Patrick Bareiss, Splunk status: experimental type: TTP -description: The following analytic detects when a new Multi-Factor Authentication (MFA) method is registered for an AWS account, as logged - through Amazon Security Lake (ASL). This behavior is detected by monitoring ASL logs for specific API calls associated with MFA registration. - Identifying this activity is crucial for a Security Operations Center (SOC) because unauthorized registration of a new MFA method can indicate - an adversary's attempt to establish or maintain access to a compromised account. The impact of such an attack is significant as it can enable - persistent access for the attacker, potentially leading to further compromise and exploitation of cloud resources. +description: The following analytic identifies the registration of a new Multi-Factor + Authentication (MFA) method for an AWS account, as logged through Amazon Security + Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` + API operation within ASL logs. This behavior is significant because adversaries + who gain unauthorized access to an AWS account may register a new MFA method to + maintain persistence. If confirmed malicious, this activity could allow attackers + to secure their access, making it harder to detect and remove their presence from + the compromised environment. data_source: [] -search: ' `amazon_security_lake` api.operation=CreateVirtualMFADevice | fillnull - | stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region - | rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `asl_aws_new_mfa_method_registered_for_user_filter`' -how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides - security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, - ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or - the Federated Analytics App. +search: ' `amazon_security_lake` api.operation=CreateVirtualMFADevice | fillnull | + stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid + actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region + | rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region, + http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_new_mfa_method_registered_for_user_filter`' +how_to_implement: The detection is based on Amazon Security Lake events from Amazon + Web Services (AWS), which is a centralized data lake that provides security-related + data from AWS services. To use this detection, you must ingest CloudTrail logs from + Amazon Security Lake into Splunk. To run this search, ensure that you ingest events + using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) + or the Federated Analytics App. known_false_positives: Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. references: @@ -53,8 +58,8 @@ tags: - Splunk Cloud required_fields: - api.operation - - actor.user.account_uid - - actor.user.name + - actor.user.account_uid + - actor.user.name - actor.user.uid - http_request.user_agent - src_endpoint.ip @@ -64,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/aws_new_mfa_method_registered_for_user/asl_ocsf_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/aws_new_mfa_method_registered_for_user/asl_ocsf_cloudtrail.json sourcetype: aws:cloudtrail:lake source: aws_asl diff --git a/detections/cloud/aws_ami_attribute_modification_for_exfiltration.yml b/detections/cloud/aws_ami_attribute_modification_for_exfiltration.yml index aa56819462..6737f239da 100644 --- a/detections/cloud/aws_ami_attribute_modification_for_exfiltration.yml +++ b/detections/cloud/aws_ami_attribute_modification_for_exfiltration.yml @@ -1,19 +1,27 @@ name: AWS AMI Attribute Modification for Exfiltration id: f2132d74-cf81-4c5e-8799-ab069e67dc9f -version: 2 -date: '2023-03-31' +version: 3 +date: '2024-05-09' author: Bhavin Patel, Splunk status: production type: TTP -data_source: +data_source: - AWS CloudTrail ModifyImageAttribute -description: This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs. -search: '`cloudtrail` eventName=ModifyImageAttribute (requestParameters.launchPermission.add.items{}.userId = * OR requestParameters.launchPermission.add.items{}.group = all) - | rename requestParameters.launchPermission.add.items{}.group as group_added - | rename requestParameters.launchPermission.add.items{}.userId as accounts_added - | eval ami_status=if(match(group_added,"all") ,"Public AMI", "Not Public") | stats - count min(_time) as firstTime max(_time) as lastTime values(group_added) values(accounts_added) as accounts_added values(ami_status) by src_ip region eventName userAgent user_arn aws_account_id userIdentity.principalId - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `aws_ami_attribute_modification_for_exfiltration_filter`' +description: The following analytic detects suspicious modifications to AWS AMI attributes, + such as sharing an AMI with another AWS account or making it publicly accessible. + It leverages AWS CloudTrail logs to identify these changes by monitoring specific + API calls. This activity is significant because adversaries can exploit these modifications + to exfiltrate sensitive data stored in AWS resources. If confirmed malicious, this + could lead to unauthorized access and potential data breaches, compromising the + confidentiality and integrity of organizational information. +search: '`cloudtrail` eventName=ModifyImageAttribute (requestParameters.launchPermission.add.items{}.userId + = * OR requestParameters.launchPermission.add.items{}.group = all) | rename requestParameters.launchPermission.add.items{}.group + as group_added | rename requestParameters.launchPermission.add.items{}.userId as + accounts_added | eval ami_status=if(match(group_added,"all") ,"Public AMI", "Not + Public") | stats count min(_time) as firstTime max(_time) as lastTime values(group_added) + values(accounts_added) as accounts_added values(ami_status) by src_ip region eventName + userAgent user_arn aws_account_id userIdentity.principalId | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)` | `aws_ami_attribute_modification_for_exfiltration_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. known_false_positives: It is possible that an AWS admin has legitimately shared a @@ -29,7 +37,8 @@ tags: asset_type: EC2 Snapshot confidence: 80 impact: 100 - message: AWS AMI from account $aws_account_id$ is shared externally with $accounts_added$ from $src_ip$ or AMI made is made Public. + message: AWS AMI from account $aws_account_id$ is shared externally with $accounts_added$ + from $src_ip$ or AMI made is made Public. mitre_attack_id: - T1537 observable: @@ -64,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_ami_shared_public/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_ami_shared_public/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_concurrent_sessions_from_different_ips.yml b/detections/cloud/aws_concurrent_sessions_from_different_ips.yml index 275fdb61de..7ba859e18e 100644 --- a/detections/cloud/aws_concurrent_sessions_from_different_ips.yml +++ b/detections/cloud/aws_concurrent_sessions_from_different_ips.yml @@ -1,22 +1,19 @@ name: AWS Concurrent Sessions From Different Ips id: 51c04fdb-2746-465a-b86e-b413a09c9085 -version: 1 -date: '2023-02-01' +version: 2 +date: '2024-05-15' author: Bhavin Patel, Splunk status: production type: TTP description: The following analytic identifies an AWS IAM account with concurrent - sessions coming from more than one unique IP address within the span of 5 minutes. - This behavior could represent a session hijacking attack whereby an adversary has - extracted cookies from a victims browser and is using them from a different location - to access corporate online resources. When a user navigates the AWS Console after - authentication, the API call with the event name `DescribeEventAggregates` is registered - in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event - name to identify 2 concurrent sessions. The presence of this event occurring from - two different IP addresses is highly unlikely. As users may behave differently across - organizations, security teams should test and customize this detection to fit their - environments. -data_source: + sessions originating from more than one unique IP address within a 5-minute window. + It leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` event, + to detect this behavior. This activity is significant as it may indicate a session + hijacking attack, where an adversary uses stolen session cookies to access AWS resources + from a different location. If confirmed malicious, this could allow unauthorized + access to sensitive corporate resources, leading to potential data breaches or further + exploitation within the AWS environment. +data_source: - AWS CloudTrail DescribeEventAggregates search: ' `cloudtrail` eventName = DescribeEventAggregates src_ip!="AWS Internal" | bin span=5m _time | stats values(userAgent) values(eventName) values(src_ip) as @@ -68,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_console_login_failed_during_mfa_challenge.yml b/detections/cloud/aws_console_login_failed_during_mfa_challenge.yml index f392e64283..49099d57ac 100644 --- a/detections/cloud/aws_console_login_failed_during_mfa_challenge.yml +++ b/detections/cloud/aws_console_login_failed_during_mfa_challenge.yml @@ -1,17 +1,19 @@ name: AWS Console Login Failed During MFA Challenge id: 55349868-5583-466f-98ab-d3beb321961e -version: 1 -date: '2022-10-03' +version: 2 +date: '2024-05-29' author: Bhavin Patel, Splunk status: production type: TTP -description: The following analytic identifies an authentication attempt event against - an AWS Console that fails during the Multi Factor Authentication challenge. AWS - Cloudtrail logs provide a a very useful field called `additionalEventData` that - logs information regarding usage of MFA. This behavior may represent an adversary - trying to authenticate with compromised credentials for an account that has multi-factor - authentication enabled. -data_source: +description: The following analytic identifies failed authentication attempts to the + AWS Console during the Multi-Factor Authentication (MFA) challenge. It leverages + AWS CloudTrail logs, specifically the `additionalEventData` field, to detect when + MFA was used but the login attempt still failed. This activity is significant as + it may indicate an adversary attempting to access an account with compromised credentials + but being thwarted by MFA. If confirmed malicious, this could suggest an ongoing + attempt to breach the account, potentially leading to unauthorized access and further + attacks if MFA is bypassed. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName= ConsoleLogin errorMessage="Failed authentication" additionalEventData.MFAUsed = "Yes" | stats count min(_time) as firstTime max(_time) @@ -68,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_failed_mfa/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_failed_mfa/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_create_policy_version_to_allow_all_resources.yml b/detections/cloud/aws_create_policy_version_to_allow_all_resources.yml index 570543068f..e769fabfc5 100644 --- a/detections/cloud/aws_create_policy_version_to_allow_all_resources.yml +++ b/detections/cloud/aws_create_policy_version_to_allow_all_resources.yml @@ -1,13 +1,18 @@ name: AWS Create Policy Version to allow all resources id: 2a9b80d3-6340-4345-b5ad-212bf3d0dac4 -version: 4 -date: '2024-04-16' +version: 5 +date: '2024-05-10' author: Bhavin Patel, Splunk status: production type: TTP -description: This search looks for AWS CloudTrail events where a user created a policy - version that allows them to access any resource in their account. -data_source: +description: The following analytic identifies the creation of a new AWS IAM policy + version that allows access to all resources. It detects this activity by analyzing + AWS CloudTrail logs for the CreatePolicyVersion event with a policy document that + grants broad permissions. This behavior is significant because it violates the principle + of least privilege, potentially exposing the environment to misuse or abuse. If + confirmed malicious, an attacker could gain extensive access to AWS resources, leading + to unauthorized actions, data exfiltration, or further compromise of the AWS environment. +data_source: - AWS CloudTrail CreatePolicyVersion search: '`cloudtrail` eventName=CreatePolicyVersion eventSource = iam.amazonaws.com errorCode = success | spath input=requestParameters.policyDocument output=key_policy_statements @@ -61,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_create_policy_version/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_create_policy_version/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_createaccesskey.yml b/detections/cloud/aws_createaccesskey.yml index 52a140e0b3..f9bc4065ea 100644 --- a/detections/cloud/aws_createaccesskey.yml +++ b/detections/cloud/aws_createaccesskey.yml @@ -1,21 +1,18 @@ name: AWS CreateAccessKey id: 2a9b80d3-6340-4345-11ad-212bf3d0d111 -version: 3 -date: '2022-03-03' +version: 4 +date: '2024-05-12' author: Bhavin Patel, Splunk status: production type: Hunting -description: This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. - An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. - While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative - of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to - establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS - services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. - Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with - unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user - creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed - manual during threat hunting. -data_source: +description: The following analytic identifies the creation of AWS IAM access keys + by a user for another user, which can indicate privilege escalation. It leverages + AWS CloudTrail logs to detect instances where the user creating the access key is + different from the user for whom the key is created. This activity is significant + because unauthorized access key creation can allow attackers to establish persistence + or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized + access to AWS services, data exfiltration, and long-term persistence in the environment. +data_source: - AWS CloudTrail CreateAccessKey search: '`cloudtrail` eventName = CreateAccessKey userAgent !=console.amazonaws.com errorCode = success | eval match=if(match(userIdentity.userName,requestParameters.userName),1,0) @@ -65,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_createaccesskey/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_createaccesskey/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_createloginprofile.yml b/detections/cloud/aws_createloginprofile.yml index d63d30cc18..ab82917ec6 100644 --- a/detections/cloud/aws_createloginprofile.yml +++ b/detections/cloud/aws_createloginprofile.yml @@ -1,15 +1,18 @@ name: AWS CreateLoginProfile id: 2a9b80d3-6340-4345-11ad-212bf444d111 -version: 2 -date: '2021-07-19' +version: 3 +date: '2024-05-16' author: Bhavin Patel, Splunk status: production type: TTP -description: This search looks for AWS CloudTrail events where a user A(victim A) - creates a login profile for user B, followed by a AWS Console login event from user - B from the same src_ip as user B. This correlated event can be indicative of privilege - escalation since both events happened from the same src_ip -data_source: +description: The following analytic identifies the creation of a login profile for + one AWS user by another, followed by a console login from the same source IP. It + uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` + events based on the source IP and user identity. This activity is significant as + it may indicate privilege escalation, where an attacker creates a new login profile + to gain unauthorized access. If confirmed malicious, this could allow the attacker + to escalate privileges and maintain persistent access to the AWS environment. +data_source: - AWS CloudTrail CreateLoginProfile - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName = CreateLoginProfile | rename requestParameters.userName @@ -62,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_createloginprofile/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_createloginprofile/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_credential_access_failed_login.yml b/detections/cloud/aws_credential_access_failed_login.yml index 2236880be6..502061bce0 100644 --- a/detections/cloud/aws_credential_access_failed_login.yml +++ b/detections/cloud/aws_credential_access_failed_login.yml @@ -1,15 +1,19 @@ name: AWS Credential Access Failed Login id: a19b354d-0d7f-47f3-8ea6-1a7c36434968 -version: 1 -date: '2022-08-07' +version: 2 +date: '2024-05-16' author: Gowthamaraj Rajendran, Bhavin Patel, Splunk status: production type: TTP -description: It shows that there have been an unsuccessful attempt to log in using - the user identity to the AWS management console. Since the user identity has access - to AWS account services and resources, an attacker might try to brute force the - password for that identity. -data_source: +description: The following analytic identifies unsuccessful login attempts to the + AWS Management Console using a specific user identity. It leverages AWS CloudTrail + logs to detect failed authentication events associated with the AWS ConsoleLogin + action. This activity is significant for a SOC because repeated failed login attempts + may indicate a brute force attack or unauthorized access attempts. If confirmed + malicious, an attacker could potentially gain access to AWS account services and + resources, leading to data breaches, resource manipulation, or further exploitation + within the AWS environment. +data_source: - AWS CloudTrail search: '| tstats count earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Authentication where Authentication.action = failure Authentication.app=AwsConsoleSignIn @@ -61,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/aws_login_failure/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/aws_login_failure/aws_cloudtrail_events.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_credential_access_rds_password_reset.yml b/detections/cloud/aws_credential_access_rds_password_reset.yml index ca998bd4e8..542a8622a7 100644 --- a/detections/cloud/aws_credential_access_rds_password_reset.yml +++ b/detections/cloud/aws_credential_access_rds_password_reset.yml @@ -1,16 +1,19 @@ name: AWS Credential Access RDS Password reset id: 6153c5ea-ed30-4878-81e6-21ecdb198189 -version: 2 -date: '2024-03-19' +version: 3 +date: '2024-05-09' author: Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The master user password for Amazon RDS DB instance can be reset using - the Amazon RDS console. Using this technique, the attacker can get access to the - sensitive data from the DB. Usually, the production databases may have sensitive - data like Credit card information, PII, Health care Data. This event should be investigated - further. -data_source: +description: The following analytic detects the resetting of the master user password + for an Amazon RDS DB instance. It leverages AWS CloudTrail logs to identify events + where the `ModifyDBInstance` API call includes a new `masterUserPassword` parameter. + This activity is significant because unauthorized password resets can grant attackers + access to sensitive data stored in production databases, such as credit card information, + PII, and healthcare data. If confirmed malicious, this could lead to data breaches, + regulatory non-compliance, and significant reputational damage. Immediate investigation + is required to determine the legitimacy of the password reset. +data_source: - AWS CloudTrail ModifyDBInstance search: '`cloudtrail` eventSource="rds.amazonaws.com" eventName=ModifyDBInstance "requestParameters.masterUserPassword"=* | stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.dBInstanceIdentifier) @@ -58,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.002/aws_rds_password_reset/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.002/aws_rds_password_reset/aws_cloudtrail_events.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_defense_evasion_delete_cloudtrail.yml b/detections/cloud/aws_defense_evasion_delete_cloudtrail.yml index b00004005a..e06a095bef 100644 --- a/detections/cloud/aws_defense_evasion_delete_cloudtrail.yml +++ b/detections/cloud/aws_defense_evasion_delete_cloudtrail.yml @@ -1,16 +1,19 @@ name: AWS Defense Evasion Delete Cloudtrail id: 82092925-9ca1-4e06-98b8-85a2d3889552 -version: 1 -date: '2022-07-13' +version: 2 +date: '2024-05-14' author: Bhavin Patel, Splunk status: production type: TTP -description: This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. - Adversaries often try to impair their target's defenses by stopping their malicious - activity from being logged, so that they may operate with stealth and avoid detection. - When the adversary has the right type of permissions in the compromised AWS environment, - they may delete the the entire cloudtrail that is logging activities in the environment. -data_source: +description: The following analytic detects the deletion of AWS CloudTrail logs by + identifying `DeleteTrail` events within CloudTrail logs. This detection leverages + CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those + initiated from the AWS console. This activity is significant because adversaries + may delete CloudTrail logs to evade detection and operate stealthily within the + compromised environment. If confirmed malicious, this action could allow attackers + to cover their tracks, making it difficult to trace their activities and potentially + leading to prolonged unauthorized access and further exploitation. +data_source: - AWS CloudTrail DeleteTrail search: '`cloudtrail` eventName = DeleteTrail eventSource = cloudtrail.amazonaws.com userAgent !=console.amazonaws.com errorCode = success| stats count min(_time) as @@ -61,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail diff --git a/detections/cloud/aws_defense_evasion_delete_cloudwatch_log_group.yml b/detections/cloud/aws_defense_evasion_delete_cloudwatch_log_group.yml index 5e30979e6a..3867484e20 100644 --- a/detections/cloud/aws_defense_evasion_delete_cloudwatch_log_group.yml +++ b/detections/cloud/aws_defense_evasion_delete_cloudwatch_log_group.yml @@ -1,16 +1,19 @@ name: AWS Defense Evasion Delete CloudWatch Log Group id: d308b0f1-edb7-4a62-a614-af321160710f -version: 1 -date: '2022-07-17' +version: 2 +date: '2024-05-26' author: Gowthamaraj Rajendran, Splunk status: production type: TTP -description: This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. - Attackers may evade the logging capability by deleting the log group in CloudWatch. - This will stop sending the logs and metrics to CloudWatch. When the adversary has - the right type of permissions within the compromised AWS environment, they may delete - the CloudWatch log group that is logging activities in the environment. -data_source: +description: The following analytic detects the deletion of CloudWatch log groups + in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This detection + leverages CloudTrail data to monitor for successful log group deletions, excluding + console-based actions. This activity is significant as it indicates potential attempts + to evade logging and monitoring, which is crucial for maintaining visibility into + AWS activities. If confirmed malicious, this could allow attackers to hide their + tracks, making it difficult to detect further malicious actions or investigate incidents + within the compromised AWS environment. +data_source: - AWS CloudTrail DeleteLogGroup search: '`cloudtrail` eventName = DeleteLogGroup eventSource = logs.amazonaws.com userAgent !=console.amazonaws.com errorCode = success| stats count min(_time) as @@ -61,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/aws_cloudtrail_events.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_defense_evasion_impair_security_services.yml b/detections/cloud/aws_defense_evasion_impair_security_services.yml index c4b768bf04..a9a0b4337e 100644 --- a/detections/cloud/aws_defense_evasion_impair_security_services.yml +++ b/detections/cloud/aws_defense_evasion_impair_security_services.yml @@ -1,17 +1,19 @@ name: AWS Defense Evasion Impair Security Services id: b28c4957-96a6-47e0-a965-6c767aac1458 -version: 1 -date: '2022-07-26' +version: 2 +date: '2024-05-26' author: Bhavin Patel, Gowthamaraj Rajendran, Splunk status: production type: Hunting -description: This analytic looks for several delete specific API calls made to AWS - Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These - API calls are often leveraged by adversaries to weaken existing security defenses - by deleting logging configurations in the CloudWatch alarm, delete a set of detectors - from your Guardduty environment or simply delete a bunch of CloudWatch alarms to - remain stealthy and avoid detection. -data_source: +description: The following analytic detects attempts to delete critical AWS security + service configurations, such as CloudWatch alarms, GuardDuty detectors, and Web + Application Firewall rules. It leverages CloudTrail logs to identify specific API + calls like "DeleteLogStream" and "DeleteDetector." This activity is significant + because it indicates potential efforts to disable security monitoring and evade + detection. If confirmed malicious, this could allow attackers to operate undetected, + escalate privileges, or exfiltrate data without triggering security alerts, severely + compromising the security posture of the AWS environment. +data_source: - AWS CloudTrail DeleteLogStream - AWS CloudTrail DeleteDetector - AWS CloudTrail DeleteIPSet @@ -73,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_defense_evasion_putbucketlifecycle.yml b/detections/cloud/aws_defense_evasion_putbucketlifecycle.yml index 85a7f532ca..acb04a8e34 100644 --- a/detections/cloud/aws_defense_evasion_putbucketlifecycle.yml +++ b/detections/cloud/aws_defense_evasion_putbucketlifecycle.yml @@ -1,16 +1,18 @@ name: AWS Defense Evasion PutBucketLifecycle id: ce1c0e2b-9303-4903-818b-0d9002fc6ea4 -version: 1 -date: '2022-07-25' +version: 2 +date: '2024-05-28' author: Bhavin Patel status: production type: Hunting -description: This analytic identifies `PutBucketLifecycle` events in CloudTrail logs - where a user has created a new lifecycle rule for an S3 bucket with a short expiration - period. Attackers may use this API call to impair the CloudTrail logging by removing - logs from the S3 bucket by changing the object expiration day to 1 day, in which - case the CloudTrail logs will be deleted. -data_source: +description: The following analytic detects `PutBucketLifecycle` events in AWS CloudTrail + logs where a user sets a lifecycle rule for an S3 bucket with an expiration period + of fewer than three days. This detection leverages CloudTrail logs to identify suspicious + lifecycle configurations. This activity is significant because attackers may use + it to delete CloudTrail logs quickly, thereby evading detection and impairing forensic + investigations. If confirmed malicious, this could allow attackers to cover their + tracks, making it difficult to trace their actions and respond to the breach effectively. +data_source: - AWS CloudTrail PutBucketLifecycle search: '`cloudtrail` eventName=PutBucketLifecycle user_type=IAMUser errorCode=success | spath path=requestParameters{}.LifecycleConfiguration{}.Rule{}.Expiration{}.Days @@ -66,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/put_bucketlifecycle/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/put_bucketlifecycle/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_defense_evasion_stop_logging_cloudtrail.yml b/detections/cloud/aws_defense_evasion_stop_logging_cloudtrail.yml index ffccb9af65..67ff658ff1 100644 --- a/detections/cloud/aws_defense_evasion_stop_logging_cloudtrail.yml +++ b/detections/cloud/aws_defense_evasion_stop_logging_cloudtrail.yml @@ -1,16 +1,19 @@ name: AWS Defense Evasion Stop Logging Cloudtrail id: 8a2f3ca2-4eb5-4389-a549-14063882e537 -version: 1 -date: '2022-07-12' +version: 2 +date: '2024-05-15' author: Bhavin Patel, Splunk status: production type: TTP -description: This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries - often try to impair their target's defenses by stopping their macliious activity - from being logged, so that they may operate with stealth and avoid detection. When - the adversary has the right type of permissions in the compromised AWS environment, - they may easily stop logging. -data_source: +description: The following analytic detects `StopLogging` events in AWS CloudTrail + logs. It leverages CloudTrail event data to identify when logging is intentionally + stopped, excluding console-based actions and focusing on successful attempts. This + activity is significant because adversaries may stop logging to evade detection + and operate stealthily within the compromised environment. If confirmed malicious, + this action could allow attackers to perform further activities without being logged, + hindering incident response and forensic investigations, and potentially leading + to unauthorized access or data exfiltration. +data_source: - AWS CloudTrail StopLogging search: '`cloudtrail` eventName = StopLogging eventSource = cloudtrail.amazonaws.com userAgent !=console.amazonaws.com errorCode = success| stats count min(_time) as @@ -61,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail diff --git a/detections/cloud/aws_defense_evasion_update_cloudtrail.yml b/detections/cloud/aws_defense_evasion_update_cloudtrail.yml index 249b246495..98568672ed 100644 --- a/detections/cloud/aws_defense_evasion_update_cloudtrail.yml +++ b/detections/cloud/aws_defense_evasion_update_cloudtrail.yml @@ -1,17 +1,19 @@ name: AWS Defense Evasion Update Cloudtrail id: 7c921d28-ef48-4f1b-85b3-0af8af7697db -version: 1 -date: '2022-07-17' +version: 2 +date: '2024-05-17' author: Gowthamaraj Rajendran, Splunk status: production type: TTP -description: This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers - may evade the logging capability by updating the settings and impairing them with - wrong parameters. For example, Attackers may change the multi-regional log into - a single region logs, which evades the logging for other regions. When the adversary - has the right type of permissions in the compromised AWS environment, they may update - the CloudTrail settings that is logging activities in your environment. -data_source: +description: The following analytic detects `UpdateTrail` events in AWS CloudTrail + logs. It identifies attempts to modify CloudTrail settings, potentially to evade + logging. The detection leverages CloudTrail logs, focusing on `UpdateTrail` events + where the user agent is not the AWS console and the operation is successful. This + activity is significant because altering CloudTrail settings can disable or limit + logging, hindering visibility into AWS account activities. If confirmed malicious, + this could allow attackers to operate undetected, compromising the integrity and + security of the AWS environment. +data_source: - AWS CloudTrail UpdateTrail search: '`cloudtrail` eventName = UpdateTrail eventSource = cloudtrail.amazonaws.com userAgent !=console.amazonaws.com errorCode = success| stats count min(_time) as @@ -62,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/update_cloudtrail/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/update_cloudtrail/aws_cloudtrail_events.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_detect_role_creation.yml b/detections/cloud/aws_detect_role_creation.yml index e7290d0ec9..7e70f272a7 100644 --- a/detections/cloud/aws_detect_role_creation.yml +++ b/detections/cloud/aws_detect_role_creation.yml @@ -1,14 +1,16 @@ name: aws detect role creation id: 5f04081e-ddee-4353-afe4-504f288de9ad -version: 1 -date: '2020-07-27' +version: 2 +date: '2024-05-15' author: Rod Soto, Splunk status: experimental type: Hunting -description: This search provides detection of role creation by IAM users. Role creation - is an event by itself if user is creating a new role with trust policies different - than the available in AWS and it can be used for lateral movement and escalation - of privileges. +description: The following analytic identifies the creation of new IAM roles by users + in AWS. It leverages CloudWatch logs to detect events where the `CreateRole` action + is performed, focusing on roles with specific trust policies. This activity is significant + as unauthorized role creation can facilitate lateral movement and privilege escalation + within the AWS environment. If confirmed malicious, attackers could gain elevated + permissions, potentially compromising sensitive resources and data. data_source: [] search: '`aws_cloudwatchlogs_eks` event_name=CreateRole action=created userIdentity.type=AssumedRole requestParameters.description=Allows* | table sourceIPAddress userIdentity.principalId diff --git a/detections/cloud/aws_detect_users_creating_keys_with_encrypt_policy_without_mfa.yml b/detections/cloud/aws_detect_users_creating_keys_with_encrypt_policy_without_mfa.yml index 63a8838e4e..3546a2c397 100644 --- a/detections/cloud/aws_detect_users_creating_keys_with_encrypt_policy_without_mfa.yml +++ b/detections/cloud/aws_detect_users_creating_keys_with_encrypt_policy_without_mfa.yml @@ -1,15 +1,19 @@ name: AWS Detect Users creating keys with encrypt policy without MFA id: c79c164f-4b21-4847-98f9-cf6a9f49179e -version: 1 -date: '2021-01-11' +version: 2 +date: '2024-05-28' author: Rod Soto, Patrick Bareiss Splunk status: production type: TTP -description: This search provides detection of KMS keys where action kms:Encrypt is - accessible for everyone (also outside of your organization). This is an indicator - that your account is compromised and the attacker uses the encryption key to compromise - another company. -data_source: +description: The following analytic detects the creation of AWS KMS keys with an encryption + policy accessible to everyone, including external entities. It leverages AWS CloudTrail + logs to identify `CreateKey` or `PutKeyPolicy` events where the `kms:Encrypt` action + is granted to all principals. This activity is significant as it may indicate a + compromised account, allowing an attacker to misuse the encryption key to target + other organizations. If confirmed malicious, this could lead to unauthorized data + encryption, potentially disrupting operations and compromising sensitive information + across multiple entities. +data_source: - AWS CloudTrail CreateKey - AWS CloudTrail PutKeyPolicy search: '`cloudtrail` eventName=CreateKey OR eventName=PutKeyPolicy | spath input=requestParameters.policy @@ -34,8 +38,8 @@ tags: asset_type: AWS Account confidence: 50 impact: 50 - message: AWS account is potentially compromised and user $user$ - is trying to compromise other accounts. + message: AWS account is potentially compromised and user $user$ is trying to compromise + other accounts. mitre_attack_id: - T1486 observable: @@ -60,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1486/aws_kms_key/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1486/aws_kms_key/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_disable_bucket_versioning.yml b/detections/cloud/aws_disable_bucket_versioning.yml index febfa08d41..a130e3a2ab 100644 --- a/detections/cloud/aws_disable_bucket_versioning.yml +++ b/detections/cloud/aws_disable_bucket_versioning.yml @@ -1,18 +1,28 @@ name: AWS Disable Bucket Versioning id: 657902a9-987d-4879-a1b2-e7a65512824b -version: 1 -date: '2023-05-01' +version: 2 +date: '2024-05-24' author: Bhavin Patel, Splunk status: production type: Anomaly -data_source: +data_source: - AWS CloudTrail PutBucketVersioning -description: The following analytic detects AWS CloudTrail events where bucket versioning is suspended by a user. Versioning allows the AWS Administrators to maintain different version of the S3 bucket which can be used to recover deleted data. Adversaries have leveraged this technique in the wild during a ransomware incident to disable versioning so the client cannot recover the data. -search: '`cloudtrail` eventName= PutBucketVersioning "requestParameters.VersioningConfiguration.Status"=Suspended - | stats count values(requestParameters.bucketName) as bucket_name values(resources{}.ARN) as resource_arn by src_ip aws_account_id awsRegion eventName userAgent user_arn userIdentity.principalId errorCode | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `aws_disable_bucket_versioning_filter`' +description: The following analytic detects when AWS S3 bucket versioning is suspended + by a user. It leverages AWS CloudTrail logs to identify `PutBucketVersioning` events + with the `VersioningConfiguration.Status` set to `Suspended`. This activity is significant + because disabling versioning can prevent recovery of deleted or modified data, which + is a common tactic in ransomware attacks. If confirmed malicious, this action could + lead to data loss and hinder recovery efforts, severely impacting data integrity + and availability. +search: '`cloudtrail` eventName= PutBucketVersioning "requestParameters.VersioningConfiguration.Status"=Suspended + | stats count values(requestParameters.bucketName) as bucket_name values(resources{}.ARN) + as resource_arn by src_ip aws_account_id awsRegion eventName userAgent user_arn + userIdentity.principalId errorCode | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `aws_disable_bucket_versioning_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. -known_false_positives: It is possible that an AWS Administrator has legitimately disabled versioning on certain buckets to avoid costs. +known_false_positives: It is possible that an AWS Administrator has legitimately disabled + versioning on certain buckets to avoid costs. references: - https://invictus-ir.medium.com/ransomware-in-the-cloud-7f14805bbe82 - https://bleemb.medium.com/data-exfiltration-with-native-aws-s3-features-c94ae4d13436 @@ -23,7 +33,8 @@ tags: asset_type: AWS Account confidence: 80 impact: 80 - message: Bucket Versioning is suspended for S3 buckets- $bucket_name$ by user $user_arn$ from IP address $src_ip$ + message: Bucket Versioning is suspended for S3 buckets- $bucket_name$ by user $user_arn$ + from IP address $src_ip$ mitre_attack_id: - T1490 observable: @@ -58,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1490/aws_bucket_version/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1490/aws_bucket_version/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_ec2_snapshot_shared_externally.yml b/detections/cloud/aws_ec2_snapshot_shared_externally.yml index 1b534a82b2..e87c9dcd55 100644 --- a/detections/cloud/aws_ec2_snapshot_shared_externally.yml +++ b/detections/cloud/aws_ec2_snapshot_shared_externally.yml @@ -19,7 +19,7 @@ search: '`cloudtrail` eventName=ModifySnapshotAttribute | rename requestParamete as requested_account_id | search requested_account_id != NULL | eval match=if(requested_account_id==aws_account_id,"Match","No Match") | table _time user_arn src_ip requestParameters.attributeType requested_account_id aws_account_id match vendor_region user_agent userIdentity.principalId | where match - = "No Match" | `aws_ec2_snapshot_shared_externally_filter` ' + = "No Match" | `aws_ec2_snapshot_shared_externally_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. known_false_positives: It is possible that an AWS admin has legitimately shared a diff --git a/detections/cloud/aws_ecr_container_upload_outside_business_hours.yml b/detections/cloud/aws_ecr_container_upload_outside_business_hours.yml index bd42472c8a..a716f748f7 100644 --- a/detections/cloud/aws_ecr_container_upload_outside_business_hours.yml +++ b/detections/cloud/aws_ecr_container_upload_outside_business_hours.yml @@ -1,16 +1,26 @@ name: AWS ECR Container Upload Outside Business Hours id: d4c4d4eb-3994-41ca-a25e-a82d64e125bb -version: 2 -date: '2023-11-09' +version: 3 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: This search looks for AWS CloudTrail events from AWS Elastic Container - Service (ECR). A upload of a new container is normally done during business hours. - When done outside business hours, we want to take a look into it. -data_source: +description: The following analytic detects the upload of a new container image to + AWS Elastic Container Registry (ECR) outside of standard business hours. It leverages + AWS CloudTrail logs to identify `PutImage` events occurring between 8 PM and 8 AM + or on weekends. This activity is significant because container uploads outside business + hours can indicate unauthorized or suspicious activity, potentially pointing to + a compromised account or insider threat. If confirmed malicious, this could allow + an attacker to deploy unauthorized or malicious containers, leading to potential + data breaches or service disruptions. +data_source: - AWS CloudTrail PutImage -search: '`cloudtrail` eventSource=ecr.amazonaws.com eventName=PutImage date_hour>=20 OR date_hour<8 OR date_wday=saturday OR date_wday=sunday | rename requestParameters.* as * | rename repositoryName AS repository | eval phase="release" | eval severity="medium" | stats min(_time) as firstTime max(_time) as lastTime by awsRegion, eventName, eventSource, user, userName, src_ip, imageTag, registryId, repository, phase, severity | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_ecr_container_upload_outside_business_hours_filter`' +search: '`cloudtrail` eventSource=ecr.amazonaws.com eventName=PutImage date_hour>=20 + OR date_hour<8 OR date_wday=saturday OR date_wday=sunday | rename requestParameters.* + as * | rename repositoryName AS repository | eval phase="release" | eval severity="medium" + | stats min(_time) as firstTime max(_time) as lastTime by awsRegion, eventName, + eventSource, user, userName, src_ip, imageTag, registryId, repository, phase, severity + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_ecr_container_upload_outside_business_hours_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. known_false_positives: When your development is spreaded in different time zones, @@ -55,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.003/aws_ecr_container_upload/aws_ecr_container_upload.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.003/aws_ecr_container_upload/aws_ecr_container_upload.json sourcetype: aws:cloudtrail source: aws_cloudtrail diff --git a/detections/cloud/aws_ecr_container_upload_unknown_user.yml b/detections/cloud/aws_ecr_container_upload_unknown_user.yml index a8ad8290d9..3f9a5c86ae 100644 --- a/detections/cloud/aws_ecr_container_upload_unknown_user.yml +++ b/detections/cloud/aws_ecr_container_upload_unknown_user.yml @@ -1,15 +1,18 @@ name: AWS ECR Container Upload Unknown User id: 300688e4-365c-4486-a065-7c884462b31d -version: 1 -date: '2021-08-19' +version: 2 +date: '2024-05-28' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: This search looks for AWS CloudTrail events from AWS Elastic Container - Service (ECR). A upload of a new container is normally done from only a few known - users. When the user was never seen before, we should have a closer look into the - event. -data_source: +description: The following analytic detects the upload of a new container image to + AWS Elastic Container Registry (ECR) by an unknown user. It leverages AWS CloudTrail + logs to identify `PutImage` events from the ECR service, filtering out known users. + This activity is significant because container uploads should typically be performed + by a limited set of authorized users. If confirmed malicious, this could indicate + unauthorized access, potentially leading to the deployment of malicious containers, + data exfiltration, or further compromise of the AWS environment. +data_source: - AWS CloudTrail PutImage search: '`cloudtrail` eventSource=ecr.amazonaws.com eventName=PutImage NOT `aws_ecr_users` | rename requestParameters.* as * | rename repositoryName AS image | eval phase="release" @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.003/aws_ecr_container_upload/aws_ecr_container_upload.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.003/aws_ecr_container_upload/aws_ecr_container_upload.json sourcetype: aws:cloudtrail source: aws_cloudtrail diff --git a/detections/cloud/aws_exfiltration_via_anomalous_getobject_api_activity.yml b/detections/cloud/aws_exfiltration_via_anomalous_getobject_api_activity.yml index 34fc41b58c..3124872c30 100644 --- a/detections/cloud/aws_exfiltration_via_anomalous_getobject_api_activity.yml +++ b/detections/cloud/aws_exfiltration_via_anomalous_getobject_api_activity.yml @@ -1,17 +1,28 @@ name: AWS Exfiltration via Anomalous GetObject API Activity id: e4384bbf-5835-4831-8d85-694de6ad2cc6 -version: 1 -date: '2023-04-10' +version: 2 +date: '2024-05-15' author: Bhavin Patel, Splunk status: production type: Anomaly -data_source: +data_source: - AWS CloudTrail GetObject -description: This search uses built in Splunk command `| anomalydetection` to detect anomalies with respect to users making high number of GetObject API calls to download objects from S3 in a 10 minute time window. The field `probable_cause` is the name of the field that best explains why the event is anomalous. This command identifies anomalous events by computing a probability for each GetObject event by "count" "user_type" "user_arn" and detects anomaly based on the frequencies. -search: '`cloudtrail` eventName=GetObject | bin _time span=10m | stats count values(requestParameters.bucketName) as bucketName by _time src_ip aws_account_id user_type user_arn userIdentity.principalId - | anomalydetection "count" "user_type" "user_arn" action=annotate | search probable_cause=* |`aws_exfiltration_via_anomalous_getobject_api_activity_filter`' -how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. -known_false_positives: It is possible that a user downloaded these files to use them locally and there are AWS services in configured that perform these activities for a legitimate reason. Filter is needed. +description: The following analytic identifies anomalous GetObject API activity in + AWS, indicating potential data exfiltration attempts. It leverages AWS CloudTrail + logs and uses the `anomalydetection` command to detect unusual patterns in the frequency + of GetObject API calls by analyzing fields such as "count," "user_type," and "user_arn" + within a 10-minute window. This activity is significant as it may indicate unauthorized + data access or exfiltration from S3 buckets. If confirmed malicious, attackers could + exfiltrate sensitive data, leading to data breaches and compliance violations. +search: '`cloudtrail` eventName=GetObject | bin _time span=10m | stats count values(requestParameters.bucketName) + as bucketName by _time src_ip aws_account_id user_type user_arn userIdentity.principalId + | anomalydetection "count" "user_type" "user_arn" action=annotate | search probable_cause=* + |`aws_exfiltration_via_anomalous_getobject_api_activity_filter`' +how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This + search works with AWS CloudTrail logs. +known_false_positives: It is possible that a user downloaded these files to use them + locally and there are AWS services in configured that perform these activities for + a legitimate reason. Filter is needed. references: - https://labs.nettitude.com/blog/how-to-exfiltrate-aws-ec2-data/ - https://docs.splunk.com/Documentation/Splunk/9.0.4/SearchReference/Anomalydetection @@ -55,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1530/aws_exfil_high_no_getobject/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1530/aws_exfil_high_no_getobject/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_exfiltration_via_batch_service.yml b/detections/cloud/aws_exfiltration_via_batch_service.yml index 00c7bb19bc..5bbdcec9a0 100644 --- a/detections/cloud/aws_exfiltration_via_batch_service.yml +++ b/detections/cloud/aws_exfiltration_via_batch_service.yml @@ -1,17 +1,29 @@ name: AWS Exfiltration via Batch Service id: 04455dd3-ced7-480f-b8e6-5469b99e98e2 -version: 1 -date: '2023-04-24' +version: 2 +date: '2024-05-23' author: Bhavin Patel, Splunk status: production type: TTP -data_source: +data_source: - AWS CloudTrail JobCreated -description: This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job. -search: '`cloudtrail` eventName = JobCreated | stats count min(_time) as firstTime max(_time) as lastTime values(serviceEventDetails.jobArn) as job_arn values(serviceEventDetails.status) as status by src_ip aws_account_id eventName errorCode userAgent| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_exfiltration_via_datasync_task_filter`' +description: The following analytic identifies the creation of AWS Batch jobs that + could potentially abuse the AWS Bucket Replication feature on S3 buckets. It leverages + AWS CloudTrail logs to detect the `JobCreated` event, analyzing job details and + their status. This activity is significant because attackers can exploit this feature + to exfiltrate data by creating malicious batch jobs. If confirmed malicious, this + could lead to unauthorized data transfer between S3 buckets, resulting in data breaches + and loss of sensitive information. +search: '`cloudtrail` eventName = JobCreated | stats count min(_time) as firstTime + max(_time) as lastTime values(serviceEventDetails.jobArn) as job_arn values(serviceEventDetails.status) + as status by src_ip aws_account_id eventName errorCode userAgent + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `aws_exfiltration_via_batch_service_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. -known_false_positives: It is possible that an AWS Administrator or a user has legitimately created this job for some tasks. +known_false_positives: It is possible that an AWS Administrator or a user has legitimately + created this job for some tasks. references: - https://hackingthe.cloud/aws/exploitation/s3-bucket-replication-exfiltration/ - https://bleemb.medium.com/data-exfiltration-with-native-aws-s3-features-c94ae4d13436 @@ -49,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_exfiltration_via_bucket_replication.yml b/detections/cloud/aws_exfiltration_via_bucket_replication.yml index 538c04408c..aa548db71f 100644 --- a/detections/cloud/aws_exfiltration_via_bucket_replication.yml +++ b/detections/cloud/aws_exfiltration_via_bucket_replication.yml @@ -1,21 +1,27 @@ name: AWS Exfiltration via Bucket Replication id: eeb432d6-2212-43b6-9e89-fcd753f7da4c -version: 1 -date: '2023-04-28' +version: 2 +date: '2024-05-11' author: Bhavin Patel, Splunk status: production type: TTP -data_source: +data_source: - AWS CloudTrail PutBucketReplication -description: The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region. - - S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account. +description: The following analytic detects API calls to enable S3 bucket replication + services. It leverages AWS CloudTrail logs to identify `PutBucketReplication` events, + focusing on fields like `bucketName`, `ReplicationConfiguration.Rule.Destination.Bucket`, + and user details. This activity is significant as it can indicate unauthorized data + replication, potentially leading to data exfiltration. If confirmed malicious, attackers + could replicate sensitive data to external accounts, leading to data breaches and + compliance violations. search: '`cloudtrail` eventName = PutBucketReplication eventSource = s3.amazonaws.com | rename requestParameters.* as * - | stats count values(bucketName) as source_bucket values(ReplicationConfiguration.Rule.ID) as rule_id values(ReplicationConfiguration.Rule.Destination.Bucket) as destination_bucket by _time user_arn userName user_type src_ip aws_account_id userIdentity.principalId user_agent | `aws_exfiltration_via_ec2_snapshot_filter`' + | stats count values(bucketName) as source_bucket values(ReplicationConfiguration.Rule.ID) as rule_id values(ReplicationConfiguration.Rule.Destination.Bucket) as destination_bucket by _time user_arn userName user_type src_ip aws_account_id userIdentity.principalId user_agent | `aws_exfiltration_via_bucket_replication_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. -known_false_positives: It is possible that an AWS admin has legitimately implemented data replication to ensure data availability and improve data protection/backup strategies. +known_false_positives: It is possible that an AWS admin has legitimately implemented + data replication to ensure data availability and improve data protection/backup + strategies. references: - https://hackingthe.cloud/aws/exploitation/s3-bucket-replication-exfiltration/ tags: @@ -25,7 +31,8 @@ tags: asset_type: EC2 Snapshot confidence: 80 impact: 80 - message: AWS Bucket Replication rule $rule_id$ added on $source_bucket$ to $destination_bucket$ by user $user_arn$ from IP Address - $src_ip$ + message: AWS Bucket Replication rule $rule_id$ added on $source_bucket$ to $destination_bucket$ + by user $user_arn$ from IP Address - $src_ip$ mitre_attack_id: - T1537 observable: @@ -61,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_exfiltration_via_datasync_task.yml b/detections/cloud/aws_exfiltration_via_datasync_task.yml index 87f691c6ac..1de0cebcc1 100644 --- a/detections/cloud/aws_exfiltration_via_datasync_task.yml +++ b/detections/cloud/aws_exfiltration_via_datasync_task.yml @@ -1,17 +1,29 @@ name: AWS Exfiltration via DataSync Task id: 05c4b09f-ea28-4c7c-a7aa-a246f665c8a2 -version: 1 -date: '2023-04-10' +version: 2 +date: '2024-05-28' author: Bhavin Patel, Splunk status: production type: TTP -data_source: +data_source: - AWS CloudTrail CreateTask -description: This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data. -search: '`cloudtrail` eventName = CreateTask eventSource="datasync.amazonaws.com" | rename requestParameters.* as * | stats count min(_time) as firstTime max(_time) as lastTime by src_ip aws_account_id awsRegion eventName destinationLocationArn sourceLocationArn userAgent user_arn userIdentity.principalId errorCode | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_exfiltration_via_datasync_task_filter`' +description: The following analytic detects the creation of an AWS DataSync task, + which could indicate potential data exfiltration. It leverages AWS CloudTrail logs + to identify the `CreateTask` event from the DataSync service. This activity is significant + because attackers can misuse DataSync to transfer sensitive data from a private + AWS location to a public one, leading to data compromise. If confirmed malicious, + this could result in unauthorized access to sensitive information, causing severe + data breaches and compliance violations. +search: '`cloudtrail` eventName = CreateTask eventSource="datasync.amazonaws.com" + | rename requestParameters.* as * | stats count min(_time) as firstTime max(_time) + as lastTime by src_ip aws_account_id awsRegion eventName destinationLocationArn + sourceLocationArn userAgent user_arn userIdentity.principalId errorCode | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `aws_exfiltration_via_datasync_task_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. -known_false_positives: It is possible that an AWS Administrator has legitimately created this task for creating backup. Please check the `sourceLocationArn` and `destinationLocationArn` of this task +known_false_positives: It is possible that an AWS Administrator has legitimately created + this task for creating backup. Please check the `sourceLocationArn` and `destinationLocationArn` + of this task references: - https://labs.nettitude.com/blog/how-to-exfiltrate-aws-ec2-data/ - https://www.shehackske.com/how-to/data-exfiltration-on-cloud-1606/ @@ -22,7 +34,8 @@ tags: asset_type: AWS Account confidence: 80 impact: 80 - message: DataSync task created on account id - $aws_account_id$ by user $user_arn$ from src_ip $src_ip$ + message: DataSync task created on account id - $aws_account_id$ by user $user_arn$ + from src_ip $src_ip$ mitre_attack_id: - T1119 observable: @@ -57,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1119/aws_exfil_datasync/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_exfiltration_via_ec2_snapshot.yml b/detections/cloud/aws_exfiltration_via_ec2_snapshot.yml index 9e4d67edf4..11f1b6109f 100644 --- a/detections/cloud/aws_exfiltration_via_ec2_snapshot.yml +++ b/detections/cloud/aws_exfiltration_via_ec2_snapshot.yml @@ -1,20 +1,36 @@ name: AWS Exfiltration via EC2 Snapshot id: ac90b339-13fc-4f29-a18c-4abbba1f2171 -version: 1 -date: '2023-03-22' +version: 2 +date: '2024-05-10' author: Bhavin Patel, Splunk status: production type: TTP -data_source: +data_source: - AWS CloudTrail CreateSnapshot - AWS CloudTrail DescribeSnapshotAttribute - AWS CloudTrail ModifySnapshotAttribute - AWS CloudTrail DeleteSnapshot -description: This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information. -search: '`cloudtrail` eventName IN ("CreateSnapshot", "DescribeSnapshotAttribute", "ModifySnapshotAttribute", "DeleteSnapshot") src_ip !="guardduty.amazonaws.com" | bin _time span=5m | stats count dc(eventName) as distinct_api_calls values(eventName) values(requestParameters.attributeType) as attributeType values(requestParameters.createVolumePermission.add.items{}.userId) as aws_account_id_added values(userAgent) as userAgent by _time userName src_ip aws_account_id | where distinct_api_calls >= 2 | `aws_exfiltration_via_ec2_snapshot_filter`' +description: The following analytic detects a series of AWS API calls related to EC2 + snapshots within a short time window, indicating potential exfiltration via EC2 + Snapshot modifications. It leverages AWS CloudTrail logs to identify actions such + as creating, describing, and modifying snapshot attributes. This activity is significant + as it may indicate an attacker attempting to exfiltrate data by sharing EC2 snapshots + externally. If confirmed malicious, the attacker could gain access to sensitive + information stored in the snapshots, leading to data breaches and potential compliance + violations. +search: '`cloudtrail` eventName IN ("CreateSnapshot", "DescribeSnapshotAttribute", + "ModifySnapshotAttribute", "DeleteSnapshot") src_ip !="guardduty.amazonaws.com" + | bin _time span=5m | stats count dc(eventName) as distinct_api_calls values(eventName) values(requestParameters.attributeType) + as attributeType values(requestParameters.createVolumePermission.add.items{}.userId) + as aws_account_id_added values(userAgent) as userAgent by _time userName src_ip + aws_account_id | where distinct_api_calls >= 2 | `aws_exfiltration_via_ec2_snapshot_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This - search works with AWS CloudTrail logs. We have intentionally removed `guardduty.amazonaws.com` from src_ip to remove false positives caused by guard duty. We recommend you adjust the time window as per your environment. -known_false_positives: It is possible that an AWS admin has legitimately shared a snapshot with an other account for a specific purpose. Please check any recent change requests filed in your organization. + search works with AWS CloudTrail logs. We have intentionally removed `guardduty.amazonaws.com` + from src_ip to remove false positives caused by guard duty. We recommend you adjust + the time window as per your environment. +known_false_positives: It is possible that an AWS admin has legitimately shared a + snapshot with an other account for a specific purpose. Please check any recent change + requests filed in your organization. references: - https://labs.nettitude.com/blog/how-to-exfiltrate-aws-ec2-data/ - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html @@ -27,7 +43,8 @@ tags: asset_type: EC2 Snapshot confidence: 80 impact: 80 - message: Potential AWS EC2 Exfiltration detected on account id - $aws_account_id$ by user $userName$ from src_ip $src_ip$ + message: Potential AWS EC2 Exfiltration detected on account id - $aws_account_id$ + by user $userName$ from src_ip $src_ip$ mitre_attack_id: - T1537 observable: @@ -63,7 +80,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_snapshot_exfil/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_snapshot_exfil/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/aws_high_number_of_failed_authentications_for_user.yml b/detections/cloud/aws_high_number_of_failed_authentications_for_user.yml index 2f7a9d4d25..5069058793 100644 --- a/detections/cloud/aws_high_number_of_failed_authentications_for_user.yml +++ b/detections/cloud/aws_high_number_of_failed_authentications_for_user.yml @@ -1,15 +1,18 @@ name: AWS High Number Of Failed Authentications For User id: e3236f49-daf3-4b70-b808-9290912ac64d -version: 1 -date: '2023-01-27' +version: 2 +date: '2024-05-25' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies an AWS account with more than 20 failed - authentication events in the span of 5 minutes. This behavior could represent a - brute force attack against the account. As environments differ across organizations, - security teams should customize the threshold of this detection. -data_source: +description: The following analytic detects an AWS account experiencing more than + 20 failed authentication attempts within a 5-minute window. It leverages AWS CloudTrail + logs to identify multiple failed ConsoleLogin events. This behavior is significant + as it may indicate a brute force attack targeting the account. If confirmed malicious, + the attacker could potentially gain unauthorized access, leading to data breaches + or further exploitation of the AWS environment. Security teams should consider adjusting + the threshold based on their specific environment to reduce false positives. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _time | stats dc(_raw) AS failed_attempts values(src_ip) as src_ip values(user_agent) @@ -56,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_multiple_login_fail_per_user/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_multiple_login_fail_per_user/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_high_number_of_failed_authentications_from_ip.yml b/detections/cloud/aws_high_number_of_failed_authentications_from_ip.yml index 3f57313282..91eb702c21 100644 --- a/detections/cloud/aws_high_number_of_failed_authentications_from_ip.yml +++ b/detections/cloud/aws_high_number_of_failed_authentications_from_ip.yml @@ -1,16 +1,18 @@ name: AWS High Number Of Failed Authentications From Ip id: f75b7f1a-b8eb-4975-a214-ff3e0a944757 -version: 1 -date: '2023-01-30' +version: 2 +date: '2024-05-23' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies an IP address failing to authenticate - 20 or more times to the AWS Web Console in the span of 5 minutes. This behavior - could represent a brute force attack against an AWS tenant to obtain initial access - or elevate privileges. As environments differ across organizations, security teams - should customize the threshold of this detection. -data_source: +description: The following analytic detects an IP address with 20 or more failed authentication + attempts to the AWS Web Console within a 5-minute window. This detection leverages + CloudTrail logs, aggregating failed login events by IP address and time span. This + activity is significant as it may indicate a brute force attack aimed at gaining + unauthorized access or escalating privileges within an AWS environment. If confirmed + malicious, this could lead to unauthorized access, data breaches, or further exploitation + of AWS resources. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName=ConsoleLogin action=failure | bucket span=5m _time | stats dc(_raw) AS failed_attempts values(user_name) as tried_accounts values(user_agent) @@ -32,7 +34,8 @@ tags: asset_type: AWS Account confidence: 90 impact: 60 - message: 'Multiple failed console login attempts (Count: $failed_attempts$) against users from IP Address - $src_ip$' + message: 'Multiple failed console login attempts (Count: $failed_attempts$) against + users from IP Address - $src_ip$' mitre_attack_id: - T1110 - T1110.003 @@ -57,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_iam_accessdenied_discovery_events.yml b/detections/cloud/aws_iam_accessdenied_discovery_events.yml index d3eba284d3..774352e523 100644 --- a/detections/cloud/aws_iam_accessdenied_discovery_events.yml +++ b/detections/cloud/aws_iam_accessdenied_discovery_events.yml @@ -1,15 +1,18 @@ name: AWS IAM AccessDenied Discovery Events id: 3e1f1568-9633-11eb-a69c-acde48001122 -version: 2 -date: '2021-11-12' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Anomaly -description: The following detection identifies excessive AccessDenied events within - an hour timeframe. It is possible that an access key to AWS may have been stolen - and is being misused to perform discovery events. In these instances, the access - is not available with the key stolen therefore these events will be generated. -data_source: +description: The following analytic identifies excessive AccessDenied events within + an hour timeframe for IAM users in AWS. It leverages AWS CloudTrail logs to detect + multiple failed access attempts from the same source IP and user identity. This + activity is significant as it may indicate that an access key has been compromised + and is being misused for unauthorized discovery actions. If confirmed malicious, + this could allow attackers to gather information about the AWS environment, potentially + leading to further exploitation or privilege escalation. +data_source: - AWS CloudTrail search: '`cloudtrail` (errorCode = "AccessDenied") user_type=IAMUser (userAgent!=*.amazonaws.com) | bucket _time span=1h | stats count as failures min(_time) as firstTime max(_time) @@ -58,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1580/aws_iam_accessdenied_discovery_events/aws_iam_accessdenied_discovery_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1580/aws_iam_accessdenied_discovery_events/aws_iam_accessdenied_discovery_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_iam_assume_role_policy_brute_force.yml b/detections/cloud/aws_iam_assume_role_policy_brute_force.yml index d7ed5fb0f9..63ae1f0062 100644 --- a/detections/cloud/aws_iam_assume_role_policy_brute_force.yml +++ b/detections/cloud/aws_iam_assume_role_policy_brute_force.yml @@ -1,17 +1,19 @@ name: AWS IAM Assume Role Policy Brute Force id: f19e09b0-9308-11eb-b7ec-acde48001122 -version: 1 -date: '2021-04-01' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies any malformed policy document exceptions - with a status of `failure`. A malformed policy document exception occurs in instances - where roles are attempted to be assumed, or brute forced. In a brute force attempt, - using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, - when an adversary is attempting to identify a role name, multiple failures will - occur. This detection focuses on the errors of a remote attempt that is failing. -data_source: +description: The following analytic detects multiple failed attempts to assume an + AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail + logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` + and filters out legitimate AWS services. This activity is significant as repeated + failures to assume roles can indicate an adversary attempting to guess role names, + which is a precursor to unauthorized access. If confirmed malicious, this could + lead to unauthorized access to AWS resources, potentially compromising sensitive + data and services. +data_source: - AWS CloudTrail search: '`cloudtrail` (errorCode=MalformedPolicyDocumentException) status=failure (userAgent!=*.amazonaws.com) | stats count min(_time) as firstTime max(_time) as @@ -64,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1580/aws_iam_assume_role_policy_brute_force/aws_iam_assume_role_policy_brute_force.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1580/aws_iam_assume_role_policy_brute_force/aws_iam_assume_role_policy_brute_force.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_iam_delete_policy.yml b/detections/cloud/aws_iam_delete_policy.yml index ad82abbf9f..c65260764b 100644 --- a/detections/cloud/aws_iam_delete_policy.yml +++ b/detections/cloud/aws_iam_delete_policy.yml @@ -1,16 +1,19 @@ name: AWS IAM Delete Policy id: ec3a9362-92fe-11eb-99d0-acde48001122 -version: 1 -date: '2021-04-01' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: Hunting -description: The following detection identifies when a policy is deleted on AWS. This - does not identify whether successful or failed, but the error messages tell a story - of suspicious attempts. There is a specific process to follow when deleting a policy. - First, detach the policy from all users, groups, and roles that the policy is attached - to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy. -data_source: +description: The following analytic detects the deletion of an IAM policy in AWS. + It leverages AWS CloudTrail logs to identify `DeletePolicy` events, excluding those + from AWS internal services. This activity is significant as unauthorized policy + deletions can disrupt access controls and weaken security postures. If confirmed + malicious, an attacker could remove critical security policies, potentially leading + to privilege escalation, unauthorized access, or data exfiltration. Monitoring this + behavior helps ensure that only authorized changes are made to IAM policies, maintaining + the integrity and security of the AWS environment. +data_source: - AWS CloudTrail DeletePolicy search: '`cloudtrail` eventName=DeletePolicy (userAgent!=*.amazonaws.com) | stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.policyArn) @@ -61,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/aws_iam_delete_policy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/aws_iam_delete_policy.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_iam_failure_group_deletion.yml b/detections/cloud/aws_iam_failure_group_deletion.yml index 755e336f8d..1897919347 100644 --- a/detections/cloud/aws_iam_failure_group_deletion.yml +++ b/detections/cloud/aws_iam_failure_group_deletion.yml @@ -1,16 +1,19 @@ name: AWS IAM Failure Group Deletion id: 723b861a-92eb-11eb-93b8-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: Anomaly -description: This detection identifies failure attempts to delete groups. We want - to identify when a group is attempting to be deleted, but either access is denied, - there is a conflict or there is no group. This is indicative of administrators performing - an action, but also could be suspicious behavior occurring. Review parallel IAM - events - recently added users, new groups and so forth. -data_source: +description: The following analytic identifies failed attempts to delete AWS IAM groups. + It leverages AWS CloudTrail logs to detect events where the DeleteGroup action fails + due to errors like NoSuchEntityException, DeleteConflictException, or AccessDenied. + This activity is significant as it may indicate unauthorized attempts to modify + IAM group configurations, which could be a precursor to privilege escalation or + other malicious actions. If confirmed malicious, this could allow an attacker to + disrupt IAM policies, potentially leading to unauthorized access or denial of service + within the AWS environment. +data_source: - AWS CloudTrail DeleteGroup search: '`cloudtrail` eventSource=iam.amazonaws.com eventName=DeleteGroup errorCode IN (NoSuchEntityException,DeleteConflictException, AccessDenied) (userAgent!=*.amazonaws.com) @@ -33,7 +36,8 @@ tags: asset_type: AWS Account confidence: 50 impact: 10 - message: User $user_arn$ has had mulitple failures while attempting to delete groups from $src$ + message: User $user_arn$ has had mulitple failures while attempting to delete groups + from $src$ mitre_attack_id: - T1098 observable: @@ -60,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_failure_group_deletion/aws_iam_failure_group_deletion.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_failure_group_deletion/aws_iam_failure_group_deletion.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_iam_successful_group_deletion.yml b/detections/cloud/aws_iam_successful_group_deletion.yml index aed09fb9bf..4f2f102188 100644 --- a/detections/cloud/aws_iam_successful_group_deletion.yml +++ b/detections/cloud/aws_iam_successful_group_deletion.yml @@ -1,15 +1,19 @@ name: AWS IAM Successful Group Deletion id: e776d06c-9267-11eb-819b-acde48001122 -version: 1 -date: '2021-03-31' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: Hunting -description: The following query uses IAM events to track the success of a group being - deleted on AWS. This is typically not indicative of malicious behavior, but a precurser - to additional events thay may unfold. Review parallel IAM events - recently added - users, new groups and so forth. Inversely, review failed attempts in a similar manner. -data_source: +description: The following analytic identifies the successful deletion of an IAM group + in AWS. It leverages CloudTrail logs to detect `DeleteGroup` events with a success + status. This activity is significant as it could indicate potential changes in user + permissions or access controls, which may be a precursor to further unauthorized + actions. If confirmed malicious, an attacker could disrupt access management, potentially + leading to privilege escalation or unauthorized access to sensitive resources. Analysts + should review related IAM events, such as recent user additions or new group creations, + to assess the broader context. +data_source: - AWS CloudTrail DeleteGroup search: '`cloudtrail` eventSource=iam.amazonaws.com eventName=DeleteGroup errorCode=success (userAgent!=*.amazonaws.com) | stats count min(_time) as firstTime max(_time) as @@ -65,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_successful_group_deletion/aws_iam_successful_group_deletion.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_successful_group_deletion/aws_iam_successful_group_deletion.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_lambda_updatefunctioncode.yml b/detections/cloud/aws_lambda_updatefunctioncode.yml index 785e603020..978dc2da1c 100644 --- a/detections/cloud/aws_lambda_updatefunctioncode.yml +++ b/detections/cloud/aws_lambda_updatefunctioncode.yml @@ -1,16 +1,18 @@ name: AWS Lambda UpdateFunctionCode id: 211b80d3-6340-4345-11ad-212bf3d0d111 -version: 1 -date: '2022-02-24' +version: 2 +date: '2024-05-13' author: Bhavin Patel, Splunk status: production type: Hunting -description: This analytic is designed to detect IAM users attempting to update/modify - AWS lambda code via the AWS CLI to gain persistence, futher access into your AWS - environment and to facilitate planting backdoors. In this instance, an attacker - may upload malicious code/binary to a lambda function which will be executed automatically - when the funnction is triggered. -data_source: +description: The following analytic identifies IAM users attempting to update or modify + AWS Lambda code via the AWS CLI. It leverages CloudTrail logs to detect successful + `UpdateFunctionCode` events initiated by IAM users. This activity is significant + as it may indicate an attempt to gain persistence, further access, or plant backdoors + within your AWS environment. If confirmed malicious, an attacker could upload and + execute malicious code automatically when the Lambda function is triggered, potentially + compromising the integrity and security of your AWS infrastructure. +data_source: - AWS CloudTrail search: '`cloudtrail` eventSource=lambda.amazonaws.com eventName=UpdateFunctionCode* errorCode = success user_type=IAMUser | stats count min(_time) as firstTime max(_time) as @@ -56,7 +58,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/aws_updatelambdafunctioncode/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/aws_updatelambdafunctioncode/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_multi_factor_authentication_disabled.yml b/detections/cloud/aws_multi_factor_authentication_disabled.yml index d28f7d9144..fdd8ede3df 100644 --- a/detections/cloud/aws_multi_factor_authentication_disabled.yml +++ b/detections/cloud/aws_multi_factor_authentication_disabled.yml @@ -1,15 +1,17 @@ name: AWS Multi-Factor Authentication Disabled id: 374832b1-3603-420c-b456-b373e24d34c0 -version: 1 -date: '2022-10-04' +version: 2 +date: '2024-05-15' author: Bhavin Patel, Splunk status: production type: TTP -description: The following analytic identifies an attempt to disable multi-factor - authentication for an AWS IAM user. An adversary who has obtained access to an AWS - tenant may disable multi-factor authentication as a way to plant a backdoor and - maintain persistence using a valid account. This way the attackers can keep persistance - in the environment without adding new users. +description: The following analytic detects attempts to disable multi-factor authentication + (MFA) for an AWS IAM user. It leverages AWS CloudTrail logs to identify events where + MFA devices are deleted or deactivated. This activity is significant because disabling + MFA can indicate an adversary attempting to weaken account security, potentially + to maintain persistence using a compromised account. If confirmed malicious, this + action could allow attackers to retain access to the AWS environment without detection, + posing a significant risk to the security and integrity of the cloud infrastructure. data_source: - AWS CloudTrail DeleteVirtualMFADevice - AWS CloudTrail DeactivateMFADevice @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/aws_multiple_failed_mfa_requests_for_user.yml index 6f2d7972eb..9252883794 100644 --- a/detections/cloud/aws_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/aws_multiple_failed_mfa_requests_for_user.yml @@ -1,23 +1,18 @@ name: AWS Multiple Failed MFA Requests For User id: 1fece617-e614-4329-9e61-3ba228c0f353 -version: 1 -date: '2022-10-03' +version: 2 +date: '2024-05-31' author: Bhavin Patel status: production type: Anomaly description: The following analytic identifies multiple failed multi-factor authentication - requests to an AWS Console for a single user. AWS CloudTrail logs provide a a very - useful field called `additionalEventData` that logs information regarding usage - of MFA. Specifically, the analytic triggers when more than 10 MFA user prompts fail - within 10 minutes. AWS Environments can be very different depending on the organization, - Security teams should test this detection and customize these arbitrary thresholds. - The detected behavior may represent an adversary who has obtained legitimate credentials - for a user and continuously repeats login attempts in order to bombard users with - MFA push notifications, SMS messages, and phone calls potentially resulting in the - user finally accepting the authentication request. Threat actors like the Lapsus - team and APT29 have leveraged this technique to bypass multi-factor authentication - controls as reported by Mandiant and others. -data_source: + (MFA) requests to an AWS Console for a single user. It leverages AWS CloudTrail + logs, specifically the `additionalEventData` field, to detect more than 10 failed + MFA prompts within 5 minutes. This activity is significant as it may indicate an + adversary attempting to bypass MFA by bombarding the user with repeated authentication + requests. If confirmed malicious, this could lead to unauthorized access to the + AWS environment, potentially compromising sensitive data and resources. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName= ConsoleLogin "additionalEventData.MFAUsed"=Yes errorMessage="Failed authentication" | bucket span=5m _time | stats dc(_raw) as mfa_prompts values(userAgent) @@ -72,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_failed_mfa/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_failed_mfa/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_multiple_users_failing_to_authenticate_from_ip.yml b/detections/cloud/aws_multiple_users_failing_to_authenticate_from_ip.yml index 0a54ea860a..4073132f6f 100644 --- a/detections/cloud/aws_multiple_users_failing_to_authenticate_from_ip.yml +++ b/detections/cloud/aws_multiple_users_failing_to_authenticate_from_ip.yml @@ -1,19 +1,23 @@ name: AWS Multiple Users Failing To Authenticate From Ip id: 71e1fb89-dd5f-4691-8523-575420de4630 -version: 1 -date: '2022-09-27' +version: 2 +date: '2024-05-10' author: Bhavin Patel status: production type: Anomaly -description: The following analytic identifies one source Ip failing to authenticate - into the AWS Console with 30 unique valid users within 10 minutes. This behavior - could represent an adversary performing a Password Spraying attack against an AWS - environment tenant to obtain initial access or elevate privileges. -data_source: +description: The following analytic identifies a single source IP failing to authenticate + into the AWS Console with 30 unique valid users within 10 minutes. It leverages + CloudTrail logs to detect multiple failed login attempts from the same IP address. + This behavior is significant as it may indicate a Password Spraying attack, where + an adversary attempts to gain unauthorized access or elevate privileges by trying + common passwords across many accounts. If confirmed malicious, this activity could + lead to unauthorized access, data breaches, or further exploitation within the AWS + environment. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _time - | stats dc(user_name) AS unique_accounts values(user_name) as tried_accounts by _time, - src_ip |`aws_unusual_number_of_failed_authentications_from_ip_filter`' + | stats dc(user_name) AS unique_accounts values(user_name) as tried_accounts by _time, src_ip + | `aws_multiple_users_failing_to_authenticate_from_ip_filter`' how_to_implement: You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment. @@ -30,7 +34,8 @@ tags: asset_type: AWS Account confidence: 90 impact: 60 - message: 'Multiple failed console login attempts (Count: $unique_accounts$) against users from IP Address - $src_ip$' + message: 'Multiple failed console login attempts (Count: $unique_accounts$) against + users from IP Address - $src_ip$' mitre_attack_id: - T1110 - T1110.003 @@ -56,10 +61,12 @@ tags: - src_ip risk_score: 54 security_domain: threat - manual_test: This search needs a specific number of events in a time window for the alert to trigger and events split up in CI testing while updating timestamp. + manual_test: This search needs a specific number of events in a time window for + the alert to trigger and events split up in CI testing while updating timestamp. tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json source: aws_cloudtrail sourcetype: aws:cloudtrail diff --git a/detections/cloud/aws_network_access_control_list_deleted.yml b/detections/cloud/aws_network_access_control_list_deleted.yml index 6d5ab5319c..f0c511b5a3 100644 --- a/detections/cloud/aws_network_access_control_list_deleted.yml +++ b/detections/cloud/aws_network_access_control_list_deleted.yml @@ -1,16 +1,18 @@ name: AWS Network Access Control List Deleted id: ada0f478-84a8-4641-a3f1-d82362d6fd75 -version: 2 -date: '2021-01-12' +version: 3 +date: '2024-05-15' author: Bhavin Patel, Patrick Bareiss, Splunk status: production type: Anomaly -description: Enforcing network-access controls is one of the defensive mechanisms - used by cloud administrators to restrict access to a cloud instance. After the attacker - has gained control of the AWS console by compromising an admin account, they can - delete a network ACL and gain access to the instance from anywhere. This search - will query the AWS CloudTrail logs to detect users deleting network ACLs. -data_source: +description: The following analytic detects the deletion of AWS Network Access Control + Lists (ACLs). It leverages AWS CloudTrail logs to identify events where a user deletes + a network ACL entry. This activity is significant because deleting a network ACL + can remove critical access restrictions, potentially allowing unauthorized access + to cloud instances. If confirmed malicious, this action could enable attackers to + bypass network security controls, leading to unauthorized access, data exfiltration, + or further compromise of the cloud environment. +data_source: - AWS CloudTrail DeleteNetworkAclEntry search: '`cloudtrail` eventName=DeleteNetworkAclEntry requestParameters.egress=false | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by user_arn @@ -59,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.007/aws_delete_acl/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.007/aws_delete_acl/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_password_policy_changes.yml b/detections/cloud/aws_password_policy_changes.yml index b44c1d4b65..af1c3de763 100644 --- a/detections/cloud/aws_password_policy_changes.yml +++ b/detections/cloud/aws_password_policy_changes.yml @@ -1,16 +1,18 @@ name: AWS Password Policy Changes id: aee4a575-7064-4e60-b511-246f9baf9895 -version: 1 -date: '2023-01-26' +version: 2 +date: '2024-05-10' author: Bhavin Patel, Splunk status: production type: Hunting -description: This search looks for AWS CloudTrail events where a user is making successful - API calls to view/update/delete the existing password policy in an AWS organization. - It is unlikely for a regular user to conduct this operation. These events may potentially - be malicious, adversaries often use this information to gain more understanding - of the password defenses in place and exploit them to increase their attack surface - when a user account is compromised. +description: The following analytic detects successful API calls to view, update, + or delete the password policy in an AWS organization. It leverages AWS CloudTrail + logs to identify events such as "UpdateAccountPasswordPolicy," "GetAccountPasswordPolicy," + and "DeleteAccountPasswordPolicy." This activity is significant because it is uncommon + for regular users to perform these actions, and such changes can indicate an adversary + attempting to understand or weaken password defenses. If confirmed malicious, this + could lead to compromised accounts and increased attack surface, potentially allowing + unauthorized access and control over AWS resources. data_source: - AWS CloudTrail UpdateAccountPasswordPolicy - AWS CloudTrail GetAccountPasswordPolicy @@ -66,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/aws_password_policy/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/aws_password_policy/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_s3_exfiltration_behavior_identified.yml b/detections/cloud/aws_s3_exfiltration_behavior_identified.yml index b00f8b1097..9c7d68f30e 100644 --- a/detections/cloud/aws_s3_exfiltration_behavior_identified.yml +++ b/detections/cloud/aws_s3_exfiltration_behavior_identified.yml @@ -1,18 +1,35 @@ name: AWS S3 Exfiltration Behavior Identified id: 85096389-a443-42df-b89d-200efbb1b560 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-13' author: Bhavin Patel, Splunk status: production type: Correlation -data_source: [] -description: This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. -search: '| 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 values(All_Risk.risk_message) as risk_message from datamodel=Risk.All_Risk where All_Risk.annotations.mitre_attack.mitre_tactic = "collection" OR All_Risk.annotations.mitre_attack.mitre_tactic = "exfiltration" source = *AWS* by All_Risk.risk_object - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | where source_count >= 2 and mitre_tactic_id_count>=2 | `aws_s3_exfiltration_behavior_identified_filter`' -how_to_implement: You must enable all the detection searches in the Data Exfiltration Analytic story to create risk events in Enterprise Security. -known_false_positives: alse positives may be present based on automated tooling or system administrators. Filter as needed. +data_source: [] +description: The following analytic identifies potential AWS S3 exfiltration behavior + by correlating multiple risk events related to Collection and Exfiltration techniques. + It leverages risk events from AWS sources, focusing on instances where two or more + unique analytics and distinct MITRE ATT&CK IDs are triggered for a specific risk + object. This activity is significant as it may indicate an ongoing data exfiltration + attempt, which is critical for security teams to monitor. If confirmed malicious, + this could lead to unauthorized access and theft of sensitive information, compromising + the organization's data integrity and confidentiality. +search: '| 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 values(All_Risk.risk_message) as risk_message from datamodel=Risk.All_Risk + where All_Risk.annotations.mitre_attack.mitre_tactic = "collection" OR All_Risk.annotations.mitre_attack.mitre_tactic + = "exfiltration" source = *AWS* by All_Risk.risk_object | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 2 and mitre_tactic_id_count>=2 | `aws_s3_exfiltration_behavior_identified_filter`' +how_to_implement: You must enable all the detection searches in the Data Exfiltration + Analytic story to create risk events in Enterprise Security. +known_false_positives: alse positives may be present based on automated tooling or + system administrators. Filter as needed. references: - https://labs.nettitude.com/blog/how-to-exfiltrate-aws-ec2-data/ - https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ebs-snapshot/ @@ -24,7 +41,8 @@ tags: asset_type: AWS Account confidence: 90 impact: 90 - message: Multiple AWS Exfiltration detections $source$ and techniques $annotations.mitre_attack.mitre_tactic_id$ trigged for risk object $risk_object$ + message: Multiple AWS Exfiltration detections $source$ and techniques $annotations.mitre_attack.mitre_tactic_id$ + trigged for risk object $risk_object$ mitre_attack_id: - T1537 observable: @@ -48,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_exfil_risk_events/aws_risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/aws_exfil_risk_events/aws_risk.log sourcetype: stash source: aws_exfil update_timestamp: true diff --git a/detections/cloud/aws_saml_access_by_provider_user_and_principal.yml b/detections/cloud/aws_saml_access_by_provider_user_and_principal.yml index de2a15b82c..949c17ac09 100644 --- a/detections/cloud/aws_saml_access_by_provider_user_and_principal.yml +++ b/detections/cloud/aws_saml_access_by_provider_user_and_principal.yml @@ -1,15 +1,19 @@ name: AWS SAML Access by Provider User and Principal id: bbe23980-6019-11eb-ae93-0242ac130002 -version: 1 -date: '2021-01-26' +version: 2 +date: '2024-05-23' author: Rod Soto, Splunk status: production type: Anomaly -description: This search provides specific SAML access from specific Service Provider, - user and targeted principal at AWS. This search provides specific information to - detect abnormal access or potential credential hijack or forgery, specially in federated - environments using SAML protocol inside the perimeter or cloud provider. -data_source: +description: The following analytic identifies specific SAML access events by a service + provider, user, and targeted principal within AWS. It leverages AWS CloudTrail logs + to detect the `AssumeRoleWithSAML` event, analyzing fields such as `principalArn`, + `roleArn`, and `roleSessionName`. This activity is significant as it can indicate + abnormal access patterns or potential credential hijacking, especially in federated + environments using the SAML protocol. If confirmed malicious, this could allow attackers + to assume roles and gain unauthorized access to sensitive AWS resources, leading + to data breaches or further exploitation. +data_source: - AWS CloudTrail AssumeRoleWithSAML search: '`cloudtrail` eventName=Assumerolewithsaml | stats count min(_time) as firstTime max(_time) as lastTime by eventName requestParameters.principalArn requestParameters.roleArn @@ -67,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/assume_role_with_saml/assume_role_with_saml.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/assume_role_with_saml/assume_role_with_saml.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_saml_update_identity_provider.yml b/detections/cloud/aws_saml_update_identity_provider.yml index b4f08fcbd3..d1da02fe30 100644 --- a/detections/cloud/aws_saml_update_identity_provider.yml +++ b/detections/cloud/aws_saml_update_identity_provider.yml @@ -1,15 +1,19 @@ name: AWS SAML Update identity provider id: 2f0604c6-6030-11eb-ae93-0242ac130002 -version: 1 -date: '2021-01-26' +version: 2 +date: '2024-05-19' author: Rod Soto, Splunk status: production type: TTP -description: This search provides detection of updates to SAML provider in AWS. Updates - to SAML provider need to be monitored closely as they may indicate possible perimeter - compromise of federated credentials, or backdoor access from another cloud provider - set by attacker. -data_source: +description: The following analytic detects updates to the SAML provider in AWS. It + leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing + fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. + Monitoring updates to the SAML provider is crucial as it may indicate a perimeter + compromise of federated credentials or unauthorized backdoor access set by an attacker. + If confirmed malicious, this activity could allow attackers to manipulate identity + federation, potentially leading to unauthorized access to cloud resources and sensitive + data. +data_source: - AWS CloudTrail UpdateSAMLProvider search: '`cloudtrail` eventName=UpdateSAMLProvider | stats count min(_time) as firstTime max(_time) as lastTime by eventType eventName requestParameters.sAMLProviderArn @@ -63,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/update_saml_provider/update_saml_provider.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/update_saml_provider/update_saml_provider.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_setdefaultpolicyversion.yml b/detections/cloud/aws_setdefaultpolicyversion.yml index 890ed9b643..fd4ef5cde3 100644 --- a/detections/cloud/aws_setdefaultpolicyversion.yml +++ b/detections/cloud/aws_setdefaultpolicyversion.yml @@ -1,15 +1,18 @@ name: AWS SetDefaultPolicyVersion id: 2a9b80d3-6340-4345-11ad-212bf3d0dac4 -version: 1 -date: '2021-03-02' +version: 2 +date: '2024-05-16' author: Bhavin Patel, Splunk status: production type: TTP -description: This search looks for AWS CloudTrail events where a user has set a default - policy versions. Attackers have been know to use this technique for Privilege Escalation - in case the previous versions of the policy had permissions to access more resources - than the current version of the policy -data_source: +description: The following analytic detects when a user sets a default policy version + in AWS. It leverages AWS CloudTrail logs to identify the `SetDefaultPolicyVersion` + event from the IAM service. This activity is significant because attackers may exploit + this technique for privilege escalation, especially if previous policy versions + grant more extensive permissions than the current one. If confirmed malicious, this + could allow an attacker to gain elevated access to AWS resources, potentially leading + to unauthorized actions and data breaches. +data_source: - AWS CloudTrail SetDefaultPolicyVersion search: '`cloudtrail` eventName=SetDefaultPolicyVersion eventSource = iam.amazonaws.com | stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.policyArn) @@ -31,8 +34,8 @@ tags: asset_type: AWS Account confidence: 60 impact: 50 - message: From IP address $src$, user $user_arn$ has trigged an - event $eventName$ for updating the the default policy version + message: From IP address $src$, user $user_arn$ has trigged an event $eventName$ + for updating the the default policy version mitre_attack_id: - T1078.004 - T1078 @@ -61,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_setdefaultpolicyversion/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_setdefaultpolicyversion/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_successful_console_authentication_from_multiple_ips.yml b/detections/cloud/aws_successful_console_authentication_from_multiple_ips.yml index 8539506325..7e324252e3 100644 --- a/detections/cloud/aws_successful_console_authentication_from_multiple_ips.yml +++ b/detections/cloud/aws_successful_console_authentication_from_multiple_ips.yml @@ -1,21 +1,22 @@ name: AWS Successful Console Authentication From Multiple IPs id: 395e50e1-2b87-4fa3-8632-0dfbdcbcd2cb -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-26' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies an AWS account successfully authenticating - from more than one unique Ip address in the span of 5 minutes. This behavior could - represent an adversary who has stolen credentials via a phishing attack or some - other method and using them to access corporate online resources around the same - time as a legitimate user. As users may behave differently across organizations, - security teams should test and customize this detection to fit their environments. -data_source: +description: The following analytic detects an AWS account successfully authenticating + from multiple unique IP addresses within a 5-minute window. It leverages AWS CloudTrail + logs, specifically monitoring `ConsoleLogin` events and counting distinct source + IPs. This behavior is significant as it may indicate compromised credentials, potentially + from a phishing attack, being used concurrently by an adversary and a legitimate + user. If confirmed malicious, this activity could allow unauthorized access to corporate + resources, leading to data breaches or further exploitation within the AWS environment. +data_source: - AWS CloudTrail ConsoleLogin -search: ' `cloudtrail` eventName = ConsoleLogin | bin span=5m _time | stats values(userAgent) as userAgent - values(eventName) as eventName values(src_ip) as src_ip dc(src_ip) as distinct_ip_count by _time user_arn - | where distinct_ip_count>1 | `aws_successful_console_authentication_from_multiple_ips_filter`' +search: ' `cloudtrail` eventName = ConsoleLogin | bin span=5m _time | stats values(userAgent) + as userAgent values(eventName) as eventName values(src_ip) as src_ip dc(src_ip) + as distinct_ip_count by _time user_arn | where distinct_ip_count>1 | `aws_successful_console_authentication_from_multiple_ips_filter`' how_to_implement: You must install Splunk AWS add on and Splunk App for AWS. This search works when AWS CloudTrail events are normalized use the Authentication datamodel. known_false_positives: A user with successful authentication events from different @@ -59,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/aws_console_login_multiple_ips/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/aws_console_login_multiple_ips/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_successful_single_factor_authentication.yml b/detections/cloud/aws_successful_single_factor_authentication.yml index a9aaf07302..762f71e260 100644 --- a/detections/cloud/aws_successful_single_factor_authentication.yml +++ b/detections/cloud/aws_successful_single_factor_authentication.yml @@ -1,15 +1,18 @@ name: AWS Successful Single-Factor Authentication id: a520b1fe-cc9e-4f56-b762-18354594c52f -version: 1 -date: '2022-10-04' +version: 2 +date: '2024-05-12' author: Bhavin Patel, Splunk status: production type: TTP description: The following analytic identifies a successful Console Login authentication - event against an AWS IAM user for an account without Multi-Factor Authentication - enabled. This could be evidence of a misconfiguration, a policy violation or an - account take over attempt that should be investigated -data_source: + event for an AWS IAM user account without Multi-Factor Authentication (MFA) enabled. + It leverages AWS CloudTrail logs to detect instances where MFA was not used during + login. This activity is significant as it may indicate a misconfiguration, policy + violation, or potential account takeover attempt. If confirmed malicious, an attacker + could gain unauthorized access to the AWS environment, potentially leading to data + exfiltration, resource manipulation, or further privilege escalation. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName= ConsoleLogin errorCode=success "additionalEventData.MFAUsed"=No | stats count min(_time) as firstTime max(_time) as lastTime by src eventName eventSource @@ -67,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/aws_login_sfa/cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/aws_login_sfa/cloudtrail.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_unusual_number_of_failed_authentications_from_ip.yml b/detections/cloud/aws_unusual_number_of_failed_authentications_from_ip.yml index 17b0be2de1..f7fb8db8f0 100644 --- a/detections/cloud/aws_unusual_number_of_failed_authentications_from_ip.yml +++ b/detections/cloud/aws_unusual_number_of_failed_authentications_from_ip.yml @@ -1,28 +1,23 @@ name: AWS Unusual Number of Failed Authentications From Ip id: 0b5c9c2b-e2cb-4831-b4f1-af125ceb1386 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-24' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies one source IP failing to authenticate - into the AWS Console with multiple valid users. This behavior could represent an - adversary performing a Password Spraying attack against an AWS environment to obtain - initial access or elevate privileges. The detection calculates the standard deviation - for source IP and leverages the 3-sigma statistical rule to identify an unusual - number of failed authentication attempts. To customize this analytic, users can - try different combinations of the bucket span time and the calculation of the upperBound - field. This logic can be used for real time security monitoring as well as threat - hunting exercises. While looking for anomalies using statistical methods like the - standard deviation can have benefits, we also recommend using threshold-based detections - to complement coverage. A similar analytic following the threshold model is `AWS - Multiple Users Failing To Authenticate From Ip`. -data_source: +description: The following analytic identifies a single source IP failing to authenticate + into the AWS Console with multiple valid users. It uses CloudTrail logs and calculates + the standard deviation for source IP, leveraging the 3-sigma rule to detect unusual + numbers of failed authentication attempts. This behavior is significant as it may + indicate a Password Spraying attack, where an adversary attempts to gain initial + access or elevate privileges. If confirmed malicious, this activity could lead to + unauthorized access, data breaches, or further exploitation within the AWS environment. +data_source: - AWS CloudTrail ConsoleLogin search: '`cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _time | stats dc(_raw) AS distinct_attempts values(user_name) as tried_accounts by _time, - src_ip | eventstats avg(distinct_attempts) as avg_attempts , stdev(distinct_attempts) as - ip_std by _time | eval upperBound=(avg_attempts+ip_std*3) | eval isOutlier=if(distinct_attempts + src_ip | eventstats avg(distinct_attempts) as avg_attempts , stdev(distinct_attempts) + as ip_std by _time | eval upperBound=(avg_attempts+ip_std*3) | eval isOutlier=if(distinct_attempts > 10 and distinct_attempts >= upperBound, 1, 0) | where isOutlier = 1 |`aws_unusual_number_of_failed_authentications_from_ip_filter`' how_to_implement: You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and @@ -39,7 +34,8 @@ tags: asset_type: AWS Account confidence: 90 impact: 60 - message: 'Unusual number of failed console login attempts (Count: $distinct_attempts$) against users from IP Address - $src_ip$' + message: 'Unusual number of failed console login attempts (Count: $distinct_attempts$) + against users from IP Address - $src_ip$' mitre_attack_id: - T1586 - T1586.003 @@ -70,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/aws_mulitple_failed_console_login/aws_cloudtrail.json source: aws_cloudtrail sourcetype: aws:cloudtrail update_timestamp: true diff --git a/detections/cloud/aws_updateloginprofile.yml b/detections/cloud/aws_updateloginprofile.yml index 40da71dba3..1ff20b3915 100644 --- a/detections/cloud/aws_updateloginprofile.yml +++ b/detections/cloud/aws_updateloginprofile.yml @@ -1,15 +1,19 @@ name: AWS UpdateLoginProfile id: 2a9b80d3-6a40-4115-11ad-212bf3d0d111 -version: 3 -date: '2022-03-03' +version: 4 +date: '2024-05-17' author: Bhavin Patel, Splunk status: production type: TTP -description: This search looks for AWS CloudTrail events where a user A who has already - permission to update login profile, makes an API call to update login profile for - another user B . Attackers have been know to use this technique for Privilege Escalation - in case new victim(user B) has more permissions than old victim(user B) -data_source: +description: The following analytic detects an AWS CloudTrail event where a user with + permissions updates the login profile of another user. It leverages CloudTrail logs + to identify instances where the user making the change is different from the user + whose profile is being updated. This activity is significant because it can indicate + privilege escalation attempts, where an attacker uses a compromised account to gain + higher privileges. If confirmed malicious, this could allow the attacker to escalate + their privileges, potentially leading to unauthorized access and control over sensitive + resources within the AWS environment. +data_source: - AWS CloudTrail UpdateLoginProfile search: ' `cloudtrail` eventName = UpdateLoginProfile userAgent !=console.amazonaws.com errorCode = success | eval match=if(match(userIdentity.userName,requestParameters.userName), @@ -30,9 +34,9 @@ tags: asset_type: AWS Account confidence: 60 impact: 50 - message: From IP address $src$, user agent $userAgent$ has trigged an - event $eventName$ for updating the existing login profile, potentially giving - user $user_arn$ more access privilleges + message: From IP address $src$, user agent $userAgent$ has trigged an event $eventName$ + for updating the existing login profile, potentially giving user $user_arn$ more + access privilleges mitre_attack_id: - T1136.003 - T1136 @@ -60,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_updateloginprofile/aws_cloudtrail_events.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/aws_updateloginprofile/aws_cloudtrail_events.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/azure_active_directory_high_risk_sign_in.yml b/detections/cloud/azure_active_directory_high_risk_sign_in.yml index 1ecb867cf1..7f07462ef4 100644 --- a/detections/cloud/azure_active_directory_high_risk_sign_in.yml +++ b/detections/cloud/azure_active_directory_high_risk_sign_in.yml @@ -1,26 +1,28 @@ name: Azure Active Directory High Risk Sign-in id: 1ecff169-26d7-4161-9a7b-2ac4c8e61bea -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-22' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic triggers on a high risk sign-in against Azure - Active Directory identified by Azure Identity Protection. Identity Protection monitors - sign-in events using heuristics and machine learning to identify potentially malicious - events and categorizes them in three categories high, medium and low. -data_source: -- Azure Active Directory -search: ' `azure_monitor_aad` category=UserRiskEvents properties.riskLevel=high - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, activity, riskLevel, riskEventType, additionalInfo - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_active_directory_high_risk_sign_in_filter`' +description: The following analytic detects high-risk sign-in attempts against Azure + Active Directory, identified by Azure Identity Protection. It leverages the RiskyUsers + and UserRiskEvents log categories from Azure AD events ingested via EventHub. This + activity is significant as it indicates potentially compromised accounts, flagged + by heuristics and machine learning. If confirmed malicious, attackers could gain + unauthorized access to sensitive resources, leading to data breaches or further + exploitation within the environment. +data_source: +- Azure Active Directory +search: ' `azure_monitor_aad` category=UserRiskEvents properties.riskLevel=high | + rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + values(user) as user by src_ip, activity, riskLevel, riskEventType, additionalInfo + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_active_directory_high_risk_sign_in_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category in the azure:monitor:aad sourcetype. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. Specifically, this analytic leverages the RiskyUsers and UserRiskEvents + log category in the azure:monitor:aad sourcetype. known_false_positives: Details for the risk calculation algorithm used by Identity Protection are unknown and may be prone to false positives. references: @@ -67,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azuread_highrisk/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azuread_highrisk/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_admin_consent_bypassed_by_service_principal.yml b/detections/cloud/azure_ad_admin_consent_bypassed_by_service_principal.yml index 46a75df4f1..33c9cab5e2 100644 --- a/detections/cloud/azure_ad_admin_consent_bypassed_by_service_principal.yml +++ b/detections/cloud/azure_ad_admin_consent_bypassed_by_service_principal.yml @@ -1,30 +1,42 @@ name: Azure AD Admin Consent Bypassed by Service Principal id: 9d4fea43-9182-4c5a-ada8-13701fd5615d -version: 1 -date: '2024-02-09' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk -data_source: +data_source: - Azure Active Directory Add app role assignment to service principal type: TTP status: production -description: This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight. -search: >- - `azure_monitor_aad` operationName="Add app role assignment to service principal" src_user_type=servicePrincipal - | rename properties.* as * - | eval roleId = mvindex('targetResources{}.modifiedProperties{}.newValue', 0) +description: The following analytic identifies instances where a service principal + in Azure Active Directory assigns app roles without standard admin consent. It uses + Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app + role assignment to service principal" operation. This detection is significant as + it highlights potential bypasses of critical administrative consent processes, which + could lead to unauthorized privileges being granted. If confirmed malicious, this + activity could allow attackers to exploit automation to assign sensitive permissions + without proper oversight, potentially compromising the security of the Azure AD + environment. +search: >- + `azure_monitor_aad` operationName="Add app role assignment to service principal" + src_user_type=servicePrincipal + | rename properties.* as * | eval roleId = mvindex('targetResources{}.modifiedProperties{}.newValue', + 0) | eval roleValue = mvindex('targetResources{}.modifiedProperties{}.newValue', 1) - | eval roleDescription = mvindex('targetResources{}.modifiedProperties{}.newValue', 2) + | eval roleDescription = mvindex('targetResources{}.modifiedProperties{}.newValue', + 2) | eval dest_user = mvindex('targetResources{}.id', 0) | rename initiatedBy.app.displayName as src_user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by src_user dest_user roleId roleValue roleDescription + | stats count earliest(_time) as firstTime latest(_time) as lastTime by src_user + dest_user roleId roleValue roleDescription | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_admin_consent_bypassed_by_service_principal_filter` + | `security_content_ctime(lastTime)` | `azure_ad_admin_consent_bypassed_by_service_principal_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category -known_false_positives: Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the Auditlog log category +known_false_positives: Service Principals are sometimes configured to legitimately + bypass the consent process for purposes of automation. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ tags: @@ -34,7 +46,8 @@ tags: asset_type: Azure Active Directory confidence: 60 impact: 90 - message: Service principal $src_user$ bypassed the admin consent process and granted permissions to $dest_user$ + message: Service principal $src_user$ bypassed the admin consent process and granted + permissions to $dest_user$ mitre_attack_id: - T1098.003 observable: @@ -56,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_bypass_admin_consent/azure_ad_bypass_admin_consent.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_bypass_admin_consent/azure_ad_bypass_admin_consent.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_application_administrator_role_assigned.yml b/detections/cloud/azure_ad_application_administrator_role_assigned.yml index 53a7344a0b..f527f11123 100644 --- a/detections/cloud/azure_ad_application_administrator_role_assigned.yml +++ b/detections/cloud/azure_ad_application_administrator_role_assigned.yml @@ -1,29 +1,30 @@ name: Azure AD Application Administrator Role Assigned id: eac4de87-7a56-4538-a21b-277897af6d8d -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Add member to role -description: The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all - aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. - Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has - been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while - impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. - Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant. -search: ' `azure_monitor_aad` "operationName"="Add member to role" "properties.targetResources{}.modifiedProperties{}.newValue"="\"Application Administrator\"" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime by user initiatedBy, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the assignment of the Application Administrator + role to an Azure AD user. It leverages Azure Active Directory events, specifically + monitoring the "Add member to role" operation. This activity is significant because + users in this role can manage all aspects of enterprise applications, including + credentials, which can be used to impersonate application identities. If confirmed + malicious, an attacker could escalate privileges, manage application settings, and + potentially access sensitive resources by impersonating application identities, + posing a significant security risk to the Azure AD tenant. +search: ' `azure_monitor_aad` "operationName"="Add member to role" "properties.targetResources{}.modifiedProperties{}.newValue"="\"Application + Administrator\"" | rename properties.* as * | rename initiatedBy.user.userPrincipalName + as initiatedBy | stats count min(_time) as firstTime max(_time) as lastTime by user + initiatedBy, result, operationName | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_application_administrator_role_assigned_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the Auditlog log category known_false_positives: Administrators may legitimately assign the Application Administrator role to a user. Filter as needed. references: @@ -39,8 +40,8 @@ tags: atomic_guid: [] confidence: 50 impact: 70 - message: The privileged Azure AD role Application Administrator was assigned for User $user$ initiated - by $initiatedBy$ + message: The privileged Azure AD role Application Administrator was assigned for + User $user$ initiated by $initiatedBy$ mitre_attack_id: - T1098 - T1098.003 @@ -68,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml b/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml index ebe0877c31..86627df216 100644 --- a/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml +++ b/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml @@ -1,27 +1,28 @@ name: Azure AD Authentication Failed During MFA Challenge id: e62c9c2e-bf51-4719-906c-3074618fcc1c -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-18' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: 'The following analytic identifies an authentication attempt event against - an Azure AD tenant that fails during the Multi Factor Authentication challenge. - Error Code 500121 represents a failed attempt to authenticate using a second factor. - This behavior may represent an adversary trying to authenticate with compromised - credentials for an account that has multi-factor authentication enabled. ' -data_source: +description: 'The following analytic identifies failed authentication attempts against + an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically + flagged by error code 500121. It leverages Azure AD SignInLogs to detect these events. + This activity is significant as it may indicate an adversary attempting to authenticate + using compromised credentials on an account with MFA enabled. If confirmed malicious, + this could suggest an ongoing effort to bypass MFA protections, potentially leading + to unauthorized access and further compromise of the affected account.' +data_source: - Azure Active Directory search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=500121 - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, status.additionalDetails, appDisplayName, user_agent - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_authentication_failed_during_mfa_challenge_filter`' + | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + by user, src_ip, status.additionalDetails, appDisplayName, user_agent | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_authentication_failed_during_mfa_challenge_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. known_false_positives: Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. references: @@ -68,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azuread/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azuread/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml index bb2c8209ba..75171daea3 100644 --- a/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml +++ b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml @@ -1,28 +1,40 @@ name: Azure AD Block User Consent For Risky Apps Disabled id: 875de3d7-09bc-4916-8c0a-0929f4ced3d8 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Update authorization policy -description: This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization +description: The following analytic detects when the risk-based step-up consent security + setting in Azure AD is disabled. It monitors Azure Active Directory logs for the + "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" + setting. This activity is significant because disabling this feature can expose + the organization to OAuth phishing threats by allowing users to grant consent to + potentially malicious applications. If confirmed malicious, attackers could gain + unauthorized access to user data and sensitive information, leading to data breaches + and further compromise within the organization. search: >- - `azure_monitor_aad` operationName="Update authorization policy" - | rename properties.* as * - | eval index_number = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps"), -1) - | search index_number >= 0 - | eval AllowUserConsentForRiskyApps = mvindex('targetResources{}.modifiedProperties{}.newValue',index_number) - | search AllowUserConsentForRiskyApps = "[true]" - | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, operationName, AllowUserConsentForRiskyApps - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_block_user_consent_for_risky_apps_disabled_filter` + `azure_monitor_aad` operationName="Update authorization policy" + | rename properties.* as * | eval index_number = if(mvfind('targetResources{}.modifiedProperties{}.displayName', + "AllowUserConsentForRiskyApps") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', + "AllowUserConsentForRiskyApps"), -1) + | search index_number >= 0 | eval AllowUserConsentForRiskyApps = mvindex('targetResources{}.modifiedProperties{}.newValue',index_number) + | search AllowUserConsentForRiskyApps = "[true]" + | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, operationName, + AllowUserConsentForRiskyApps + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_block_user_consent_for_risky_apps_disabled_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. +known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting + by administrators, perhaps as part of a policy update or security assessment, may + trigger this alert, necessitating verification of the change's intent and authorization references: - https://attack.mitre.org/techniques/T1562/ - https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/ @@ -58,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/azuread_disable_blockconsent_for_riskapps/azuread_disable_blockconsent_for_riskapps.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/azuread_disable_blockconsent_for_riskapps/azuread_disable_blockconsent_for_riskapps.log source: Azure Ad sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_concurrent_sessions_from_different_ips.yml b/detections/cloud/azure_ad_concurrent_sessions_from_different_ips.yml index 399133dfe9..dc0b061ef5 100644 --- a/detections/cloud/azure_ad_concurrent_sessions_from_different_ips.yml +++ b/detections/cloud/azure_ad_concurrent_sessions_from_different_ips.yml @@ -1,30 +1,30 @@ name: Azure AD Concurrent Sessions From Different Ips id: a9126f73-9a9b-493d-96ec-0dd06695490d -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies an Azure AD account with concurrent - sessions coming from more than one unique Ip address within the span of 5 minutes. - This behavior could represent a session hijacking attack whereby an adversary has - extracted cookies from a victims browser and is using them from a different location - to access corporate online resources. As users may behave differently across organizations, - security teams should test and customize this detection to fit their environments. -data_source: +description: The following analytic detects an Azure AD account with concurrent sessions + originating from multiple unique IP addresses within a 5-minute window. It leverages + Azure Active Directory NonInteractiveUserSignInLogs to identify this behavior by + analyzing successful authentication events and counting distinct source IPs per + user. This activity is significant as it may indicate session hijacking, where an + attacker uses stolen session cookies to access corporate resources from a different + location. If confirmed malicious, this could lead to unauthorized access to sensitive + information and potential data breaches. +data_source: - Azure Active Directory search: ' `azure_monitor_aad` properties.authenticationDetails{}.succeeded=true category=NonInteractiveUserSignInLogs - | rename properties.* as * - | bucket span=30m _time - | stats count min(_time) as firstTime max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) as appDisplayName by user - | where unique_ips > 1 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_concurrent_sessions_from_different_ips_filter`' + | rename properties.* as * | bucket span=30m _time | stats count min(_time) as firstTime + max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) + as appDisplayName by user | where unique_ips > 1 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_concurrent_sessions_from_different_ips_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. known_false_positives: A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -39,8 +39,8 @@ tags: asset_type: Azure Tenant confidence: 60 impact: 70 - message: User $user$ has concurrent sessions from more than one unique - IP address in the span of 5 minutes. + message: User $user$ has concurrent sessions from more than one unique IP address + in the span of 5 minutes. mitre_attack_id: - T1185 observable: @@ -68,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/azure_ad_concurrent_sessions_from_different_ips/azuread.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/azure_ad_concurrent_sessions_from_different_ips/azuread.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 1a7f6003a6..9bf37ac615 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -1,31 +1,32 @@ name: Azure AD Device Code Authentication id: d68d8732-6f7e-4ee5-a6eb-737f2b990b91 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-28' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory -description: The following analytic identifies the execution of the Azure Device Code Phishing attack, - which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically - focusing on authentication requests to identify the attack. This technique involves creating malicious - infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). - The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick - the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result - in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). - This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. - It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. -search: '`azure_monitor_aad` category=SignInLogs "properties.authenticationProtocol"=deviceCode - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime by user src_ip, appDisplayName, userAgent - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_device_code_authentication_filter`' +description: The following analytic identifies Azure Device Code Phishing attacks, + which can lead to Azure Account Take-Over (ATO). It leverages Azure AD SignInLogs + to detect suspicious authentication requests using the device code authentication + protocol. This activity is significant as it indicates potential bypassing of Multi-Factor + Authentication (MFA) and Conditional Access Policies (CAPs) through phishing emails. + If confirmed malicious, attackers could gain unauthorized access to Azure AD, Exchange + mailboxes, and Outlook Web Application (OWA), leading to potential data breaches + and unauthorized data access. +search: '`azure_monitor_aad` category=SignInLogs "properties.authenticationProtocol"=deviceCode + | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + by user src_ip, appDisplayName, userAgent | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_device_code_authentication_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. -known_false_positives: In most organizations, device code authentication will be used to access common Microsoft service but it may be legitimate for others. Filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. +known_false_positives: In most organizations, device code authentication will be used + to access common Microsoft service but it may be legitimate for others. Filter as + needed. references: - https://attack.mitre.org/techniques/T1528 - https://github.com/rvrsh3ll/TokenTactics @@ -70,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/device_code_authentication/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/device_code_authentication/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_external_guest_user_invited.yml b/detections/cloud/azure_ad_external_guest_user_invited.yml index a24b98701b..ccd54623f8 100644 --- a/detections/cloud/azure_ad_external_guest_user_invited.yml +++ b/detections/cloud/azure_ad_external_guest_user_invited.yml @@ -1,31 +1,28 @@ name: Azure AD External Guest User Invited id: c1fb4edb-cab1-4359-9b40-925ffd797fb5 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-11' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the invitation of an external guest - user within Azure AD. With Azure AD B2B collaboration, users and administrators - can invite external users to collaborate with internal users. External guest account - invitations should be monitored by security teams as they could potentially lead - to unauthorized access. An example of this attack vector was described at BlackHat - 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking - Azure AD Accounts by Abusing External Identities` -data_source: +description: The following analytic detects the invitation of an external guest user + within Azure AD. It leverages Azure AD AuditLogs to identify events where an external + user is invited, using fields such as operationName and initiatedBy. Monitoring + these invitations is crucial as they can lead to unauthorized access if abused. + If confirmed malicious, this activity could allow attackers to gain access to internal + resources, potentially leading to data breaches or further exploitation of the environment. +data_source: - Azure Active Directory Invite external user -search: '`azure_monitor_aad` operationName="Invite external user" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | rename targetResources{}.type as type - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by type, initiatedBy, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_external_guest_user_invited_filter`' +search: '`azure_monitor_aad` operationName="Invite external user" | rename properties.* as + * | rename initiatedBy.user.userPrincipalName as initiatedBy | rename targetResources{}.type + as type | stats count min(_time) as firstTime max(_time) as lastTime values(user) + as user by type, initiatedBy, result, operationName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_external_guest_user_invited_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLogs log category. known_false_positives: Administrator may legitimately invite external guest users. Filter as needed. references: @@ -66,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_external_guest_user_invited/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_external_guest_user_invited/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_fullaccessasapp_permission_assigned.yml b/detections/cloud/azure_ad_fullaccessasapp_permission_assigned.yml index d12be6c356..74b8cac346 100644 --- a/detections/cloud/azure_ad_fullaccessasapp_permission_assigned.yml +++ b/detections/cloud/azure_ad_fullaccessasapp_permission_assigned.yml @@ -1,28 +1,37 @@ name: Azure AD FullAccessAsApp Permission Assigned id: ae286126-f2ad-421c-b240-4ea83bd1c43a -version: 1 -date: '2024-01-29' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited. -data_source: +description: The following analytic detects the assignment of the 'full_access_as_app' + permission to an application within Office 365 Exchange Online. This is identified + by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. + The detection leverages the azure_monitor_aad data source, focusing on AuditLogs + with the operation name 'Update application'. This activity is significant as it + grants broad control over Office 365 operations, including full access to all mailboxes + and the ability to send emails as any user. If malicious, this could lead to unauthorized + access and data exfiltration. +data_source: - Azure Active Directory Update application search: >- - `azure_monitor_aad` category=AuditLogs operationName="Update application" - | eval newvalue = mvindex('properties.targetResources{}.modifiedProperties{}.newValue',0) - | spath input=newvalue - | search "{}.ResourceAppId"="00000002-0000-0ff1-ce00-000000000000" "{}.RequiredAppPermissions{}.EntitlementId"="dc890d15-9560-4a4c-9b7f-a736ec74ec40" - | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) by user, object, user_agent, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_fullaccessasapp_permission_assigned_filter` + `azure_monitor_aad` category=AuditLogs operationName="Update application" | eval + newvalue = mvindex('properties.targetResources{}.modifiedProperties{}.newValue',0) + | spath input=newvalue | search "{}.ResourceAppId"="00000002-0000-0ff1-ce00-000000000000" "{}.RequiredAppPermissions{}.EntitlementId"="dc890d15-9560-4a4c-9b7f-a736ec74ec40" + | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) + by user, object, user_agent, operationName + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_fullaccessasapp_permission_assigned_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. -known_false_positives: The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. +known_false_positives: The full_access_as_app API permission may be assigned to legitimate + applications. Filter as needed. references: - https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -34,7 +43,8 @@ tags: asset_type: Azure Active Directory confidence: 60 impact: 80 - message: User $user$ assigned the full_access_as_app permission to the app registration $object$ + message: User $user$ assigned the full_access_as_app permission to the app registration + $object$ mitre_attack_id: - T1098.002 - T1098.003 @@ -54,8 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/full_access_as_app_permission_assigned/full_access_as_app_permission_assigned.log - source: Azure AD - sourcetype: azure:monitor:aad + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/full_access_as_app_permission_assigned/full_access_as_app_permission_assigned.log source: Azure AD + sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_global_administrator_role_assigned.yml b/detections/cloud/azure_ad_global_administrator_role_assigned.yml index 82d0f500bb..b4acf713d2 100644 --- a/detections/cloud/azure_ad_global_administrator_role_assigned.yml +++ b/detections/cloud/azure_ad_global_administrator_role_assigned.yml @@ -1,31 +1,30 @@ name: Azure AD Global Administrator Role Assigned id: 825fed20-309d-4fd1-8aaf-cd49c1bb093c -version: 4 -date: '2023-12-20' +version: 5 +date: '2024-05-29' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the assignment of the Azure AD Global - Administrator role to an Azure AD user. The Global Administrator role is the most - powerful administrator role in Azure AD and provides almost unlimited access to - data, resources and settings. It is equivalent to the Domain Administrator group - in an Active Directory environment. While Azure AD roles do not grant access to - Azure services and resources, it is possible for a Global Administrator account - to gain control of Azure resources. Adversaries and red teams alike may assign this - role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment. -data_source: +description: The following analytic detects the assignment of the Azure AD Global + Administrator role to a user. It leverages Azure Active Directory AuditLogs to identify + when the "Add member to role" operation includes the "Global Administrator" role. + This activity is significant because the Global Administrator role grants extensive + access to data, resources, and settings, similar to a Domain Administrator in traditional + AD environments. If confirmed malicious, this could allow an attacker to establish + persistence, escalate privileges, and potentially gain control over Azure resources, + posing a severe security risk. +data_source: - Azure Active Directory Add member to role -search: '`azure_monitor_aad` operationName="Add member to role" properties.targetResources{}.modifiedProperties{}.newValue="\"Global Administrator\"" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by initiatedBy, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_global_administrator_role_assigned_filter`' +search: '`azure_monitor_aad` operationName="Add member to role" properties.targetResources{}.modifiedProperties{}.newValue="\"Global + Administrator\"" | rename properties.* as * | rename initiatedBy.user.userPrincipalName + as initiatedBy | stats count min(_time) as firstTime max(_time) as lastTime values(user) + as user by initiatedBy, result, operationName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_global_administrator_role_assigned_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. known_false_positives: Administrators may legitimately assign the Global Administrator role to a user. Filter as needed. references: @@ -42,8 +41,7 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 80 - message: Global Administrator Role assigned for User $user$ initiated - by $initiatedBy$ + message: Global Administrator Role assigned for User $user$ initiated by $initiatedBy$ mitre_attack_id: - T1098.003 observable: @@ -70,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_global_administrator/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_global_administrator/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_high_number_of_failed_authentications_for_user.yml b/detections/cloud/azure_ad_high_number_of_failed_authentications_for_user.yml index 90a48c271f..98b05d1f52 100644 --- a/detections/cloud/azure_ad_high_number_of_failed_authentications_for_user.yml +++ b/detections/cloud/azure_ad_high_number_of_failed_authentications_for_user.yml @@ -1,28 +1,30 @@ name: Azure AD High Number Of Failed Authentications For User id: 630b1694-210a-48ee-a450-6f79e7679f2c -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies an Azure AD account with more than - 20 failed authentication events in the span of 10 minutes. This behavior could represent - a brute force attack against the account. As environments differ across organizations, - security teams should customize the threshold of this detection. -data_source: +description: The following analytic identifies an Azure AD account experiencing more + than 20 failed authentication attempts within a 10-minute window. This detection + leverages Azure SignInLogs data, specifically monitoring for error code 50126 and + unsuccessful authentication attempts. This behavior is significant as it may indicate + a brute force attack targeting the account. If confirmed malicious, an attacker + could potentially gain unauthorized access, leading to data breaches or further + exploitation within the environment. Security teams should adjust the threshold + based on their specific environment to reduce false positives. +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false - | rename properties.* as * - | bucket span=10m _time - | stats count min(_time) as firstTime max(_time) as lastTime values(src_ip) as src_ip by user - | where count > 20 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_high_number_of_failed_authentications_for_user_filter`' +search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 + properties.authenticationDetails{}.succeeded=false | rename properties.* as * | + bucket span=10m _time | stats count min(_time) as firstTime max(_time) as lastTime + values(src_ip) as src_ip by user | where count > 20 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_high_number_of_failed_authentications_for_user_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. known_false_positives: A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. references: @@ -35,8 +37,8 @@ tags: asset_type: Azure Tenant confidence: 70 impact: 50 - message: User $user$ failed to authenticate more than 20 times in the - span of 5 minutes. + message: User $user$ failed to authenticate more than 20 times in the span of 5 + minutes. mitre_attack_id: - T1110 - T1110.001 @@ -61,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_high_number_of_failed_authentications_from_ip.yml b/detections/cloud/azure_ad_high_number_of_failed_authentications_from_ip.yml index beb9947699..3e5a6654a5 100644 --- a/detections/cloud/azure_ad_high_number_of_failed_authentications_from_ip.yml +++ b/detections/cloud/azure_ad_high_number_of_failed_authentications_from_ip.yml @@ -1,29 +1,29 @@ name: Azure AD High Number Of Failed Authentications From Ip id: e5ab41bf-745d-4f72-a393-2611151afd8e -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies an Ip address failing to authenticate - 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could - represent a brute force attack againstan Azure AD to obtain initial access or elevate - privileges. As environments differ across organizations, security teams should customize - the threshold of this detection. -data_source: +description: The following analytic detects an IP address with 20 or more failed authentication + attempts to an Azure AD tenant within 10 minutes. It leverages Azure AD SignInLogs + to identify repeated failed logins from the same IP. This behavior is significant + as it may indicate a brute force attack aimed at gaining unauthorized access or + escalating privileges. If confirmed malicious, the attacker could potentially compromise + user accounts, leading to unauthorized access to sensitive information and resources + within the Azure environment. +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false - | rename properties.* as * - | bucket span=10m _time - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip - | where count > 20 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_high_number_of_failed_authentications_from_ip_filter`' +search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 + properties.authenticationDetails{}.succeeded=false | rename properties.* as * | + bucket span=10m _time | stats count min(_time) as firstTime max(_time) as lastTime + values(user) as user by src_ip | where count > 20 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_high_number_of_failed_authentications_from_ip_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. known_false_positives: An Ip address with more than 20 failed authentication attempts in the span of 10 minutes may also be triggered by a broken application. references: @@ -69,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_multi_factor_authentication_disabled.yml b/detections/cloud/azure_ad_multi_factor_authentication_disabled.yml index 2622799870..d02e86cbd9 100644 --- a/detections/cloud/azure_ad_multi_factor_authentication_disabled.yml +++ b/detections/cloud/azure_ad_multi_factor_authentication_disabled.yml @@ -1,29 +1,29 @@ name: Azure AD Multi-Factor Authentication Disabled id: 482dd42a-acfa-486b-a0bb-d6fcda27318e -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies an attempt to disable multi-factor - authentication for an Azure AD user. An adversary who has obtained access to an - Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor - and maintain persistence using a valid account. This way the attackers can keep - persistance in the environment without adding new users. -data_source: +description: The following analytic detects attempts to disable multi-factor authentication + (MFA) for an Azure AD user. It leverages Azure Active Directory AuditLogs to identify + the "Disable Strong Authentication" operation. This activity is significant because + disabling MFA can allow adversaries to maintain persistence using compromised accounts + without raising suspicion. If confirmed malicious, this action could enable attackers + to bypass an essential security control, potentially leading to unauthorized access + and prolonged undetected presence in the environment. +data_source: - Azure Active Directory Disable Strong Authentication search: '`azure_monitor_aad` category=AuditLogs operationName="Disable Strong Authentication" - | rename properties.* as * - | rename targetResources{}.type as type - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime by user, type, operationName, initiatedBy, result - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multi_factor_authentication_disabled_filter`' + | rename properties.* as * | rename targetResources{}.type as type | rename initiatedBy.user.userPrincipalName + as initiatedBy | stats count min(_time) as firstTime max(_time) as lastTime by user, + type, operationName, initiatedBy, result | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `azure_ad_multi_factor_authentication_disabled_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. known_false_positives: Legitimate use case may require for users to disable MFA. Filter as needed. references: @@ -67,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/azuread/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/azuread/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml index 5572bfa4d1..e96759611d 100644 --- a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml +++ b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml @@ -1,27 +1,46 @@ name: Azure AD Multi-Source Failed Authentications Spike id: 116e11a9-63ea-41eb-a66a-6a13bdc7d2c7 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: Hunting -data_source: +data_source: - Azure Active Directory -description: This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure. -search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false - | rename properties.* as * - | bucket span=5m _time - | eval uniqueIPUserCombo = src_ip . "-" . user - | stats count min(_time) as firstTime max(_time) as lastTime dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(user_agent) as uniqueUserAgents, dc(location.countryOrRegion) as uniqueCountries values(user) as user, values(src_ip) as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries - | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20 AND uniqueUserAgents = 1 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multi_source_failed_authentications_spike_filter`' +description: The following analytic detects potential distributed password spraying + attacks in an Azure AD environment. It identifies a spike in failed authentication + attempts across various user-and-IP combinations from multiple source IPs and countries, + using different user agents. This detection leverages Azure AD SignInLogs, focusing + on error code 50126 for failed authentications. This activity is significant as + it indicates an adversary's attempt to bypass security controls by distributing + login attempts. If confirmed malicious, this could lead to unauthorized access, + data breaches, privilege escalation, and lateral movement within the organization's + infrastructure. +search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 + properties.authenticationDetails{}.succeeded=false | rename properties.* as * | + bucket span=5m _time | eval uniqueIPUserCombo = src_ip . "-" . user | stats count + min(_time) as firstTime max(_time) as lastTime dc(uniqueIPUserCombo) as uniqueIpUserCombinations, + dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(user_agent) as uniqueUserAgents, + dc(location.countryOrRegion) as uniqueCountries values(user) as user, values(src_ip) + as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries + | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20 AND + uniqueUserAgents = 1 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `azure_ad_multi_source_failed_authentications_spike_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. - The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. -known_false_positives: This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. The thresholds set within the + analytic (such as unique IPs, unique users, etc.) are initial guidelines and should + be customized based on the organization's user behavior and risk profile. Security + teams are encouraged to adjust these thresholds to optimize the balance between + detecting genuine threats and minimizing false positives, ensuring the detection + is tailored to their specific environment. +known_false_positives: This detection may yield false positives in scenarios where + legitimate bulk sign-in activities occur, such as during company-wide system updates + or when users are accessing resources from varying locations in a short time frame, + such as in the case of VPNs or cloud services that rotate IP addresses. Filter as + needed. references: - https://attack.mitre.org/techniques/T1110/003/ - https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray @@ -64,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azure_ad_distributed_spray/azure_ad_distributed_spray.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azure_ad_distributed_spray/azure_ad_distributed_spray.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml index 246f61382e..4c973afffd 100644 --- a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml +++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml @@ -1,25 +1,37 @@ name: Azure AD Multiple AppIDs and UserAgents Authentication Spike id: 5d8bb1f0-f65a-4b4e-af2e-fcdb88276314 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: Anomaly -data_source: +data_source: - Azure Active Directory Sign-in activity -description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. -search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) - | bucket span=5m _time - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) values(deviceDetail.operatingSystem) by user, src_ip - | where count > 5 and unique_app_ids > 2 and unique_user_agents > 5 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multiple_appids_and_useragents_authentication_spike_filter`' +description: The following analytic detects unusual authentication activity in Azure + AD, specifically when a single user account has over 8 authentication attempts using + 3+ unique application IDs and 5+ unique user agents within a short period. It leverages + Azure AD audit logs, focusing on authentication events and using statistical thresholds. + This behavior is significant as it may indicate an adversary probing for MFA requirements. + If confirmed malicious, it suggests a compromised account, potentially leading to + further exploitation, lateral movement, and data exfiltration. Early detection is + crucial to prevent substantial harm. +search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" + (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA + required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication + AND "properties.authenticationDetails{}.succeeded"=true) | bucket span=5m _time + | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) + values(deviceDetail.operatingSystem) by user, src_ip | where count > 5 and unique_app_ids + > 2 and unique_user_agents > 5 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `azure_ad_multiple_appids_and_useragents_authentication_spike_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. -known_false_positives: Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. +known_false_positives: Rapid authentication from the same user using more than 5 different + user agents and 3 application IDs is highly unlikely under normal circumstances. + However, there are potential scenarios that could lead to false positives. references: - https://attack.mitre.org/techniques/T1078/ - https://www.blackhillsinfosec.com/exploiting-mfa-inconsistencies-on-microsoft-services/ @@ -31,7 +43,8 @@ tags: asset_type: Azure Tenant confidence: 80 impact: 60 - message: $user$ authenticated in a short periof of time with more than 5 different user agents across 3 or more unique application ids. + message: $user$ authenticated in a short periof of time with more than 5 different + user agents across 3 or more unique application ids. mitre_attack_id: - T1078 observable: @@ -59,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/azure_ad_multiple_appids_and_useragents_auth/azure_ad_multiple_appids_and_useragents_auth.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/azure_ad_multiple_appids_and_useragents_auth/azure_ad_multiple_appids_and_useragents_auth.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml index b96f198f6b..6889ecefd9 100644 --- a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml @@ -1,26 +1,33 @@ name: Azure AD Multiple Denied MFA Requests For User id: d0895c20-de71-4fd2-b56c-3fcdb888eba1 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-18' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Sign-in activity -description: This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +description: The following analytic detects an unusually high number of denied Multi-Factor + Authentication (MFA) requests for a single user within a 10-minute window, specifically + when more than nine MFA prompts are declined. It leverages Azure Active Directory + (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 + and additional details indicating "MFA denied; user declined the authentication." + This behavior is significant as it may indicate a targeted attack or account compromise + attempt, with the user actively declining unauthorized access. If confirmed malicious, + it could lead to data exfiltration, lateral movement, or further malicious activities. search: '`azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" - | rename properties.* as * - | search status.errorCode=500121 status.additionalDetails="MFA denied; user declined the authentication" - | bucket span=10m _time - | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent - | where count > 9 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multiple_denied_mfa_requests_for_user_filter`' + | rename properties.* as * | search status.errorCode=500121 status.additionalDetails="MFA + denied; user declined the authentication" | bucket span=10m _time | stats count + min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, + appDisplayName, user_agent | where count > 9 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_multiple_denied_mfa_requests_for_user_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. -known_false_positives: Multiple denifed MFA requests in a short period of span may also be a sign of authentication errors. Investigate and filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. +known_false_positives: Multiple denifed MFA requests in a short period of span may + also be a sign of authentication errors. Investigate and filter as needed. references: - https://www.mandiant.com/resources/blog/russian-targeting-gov-business - https://arstechnica.com/information-technology/2022/03/lapsus-and-solar-winds-hackers-both-use-the-same-old-trick-to-bypass-mfa/ @@ -60,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azure_ad_multiple_denied_mfa_requests/azure_ad_multiple_denied_mfa_requests.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azure_ad_multiple_denied_mfa_requests/azure_ad_multiple_denied_mfa_requests.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml index 9261b1bf88..e56b196c40 100644 --- a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml @@ -1,36 +1,31 @@ name: Azure AD Multiple Failed MFA Requests For User id: 264ea131-ab1f-41b8-90e0-33ad1a1888ea -version: 3 -date: '2023-12-20' +version: 4 +date: '2024-05-20' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP description: The following analytic identifies multiple failed multi-factor authentication - requests for a single user within an Azure AD tenant. Error Code 500121 represents - a failed attempt to authenticate using a second factor. Specifically, the analytic - triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, - like the user not responding in time or receiving multiple duplicate MFA requests. - Azure AD tenants can be very different depending on the organization, Security teams should test - this detection and customize these arbitrary thresholds. The detected behavior may - represent an adversary who has obtained legitimate credentials for a user and continuously - repeats login attempts in order to bombard users with MFA push notifications, SMS - messages, and phone calls potentially resulting in the user finally accepting the - authentication request. Threat actors like the Lapsus team and APT29 have leveraged - this technique to bypass multi-factor authentication controls as reported by Mandiant - and others. -data_source: + (MFA) requests for a single user within an Azure AD tenant. It leverages Azure AD + Sign-in Logs, specifically error code 500121, to detect more than 10 failed MFA + attempts within 10 minutes. This behavior is significant as it may indicate an adversary + attempting to bypass MFA by bombarding the user with repeated authentication prompts. + If confirmed malicious, this activity could lead to unauthorized access, allowing + attackers to compromise user accounts and potentially escalate their privileges + within the environment. +data_source: - Azure Active Directory Sign-in activity -search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication" - | rename properties.* as * - | bucket span=10m _time - | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent - | where count > 9 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multiple_failed_mfa_requests_for_user_filter`' +search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" + properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; + user declined the authentication" | rename properties.* as * | bucket span=10m _time + | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, + appDisplayName, user_agent | where count > 10 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_multiple_failed_mfa_requests_for_user_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. references: @@ -46,7 +41,8 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 60 - message: User $user$ failed to complete MFA authentication more than 9 times in a timespan of 10 minutes. + message: User $user$ failed to complete MFA authentication more than 9 times in + a timespan of 10 minutes. mitre_attack_id: - T1586 - T1586.003 @@ -75,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/multiple_failed_mfa_requests/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/multiple_failed_mfa_requests/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_multiple_service_principals_created_by_sp.yml b/detections/cloud/azure_ad_multiple_service_principals_created_by_sp.yml index cdf3d76e41..407709ae8c 100644 --- a/detections/cloud/azure_ad_multiple_service_principals_created_by_sp.yml +++ b/detections/cloud/azure_ad_multiple_service_principals_created_by_sp.yml @@ -1,29 +1,33 @@ name: Azure AD Multiple Service Principals Created by SP id: 66cb378f-234d-4fe1-bb4c-e7878ff6b017 -version: 1 -date: '2024-02-07' +version: 2 +date: '2024-05-13' author: Mauricio Velazco, Splunk -data_source: +data_source: - Azure Active Directory Add service principal type: Anomaly status: production -description: This detection identifies when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span, potentially signaling malicious activity. It monitors the 'Add service principal' operation, focusing on the activity of service principals rather than individual users. By aggregating the creation events over a 10-minute period, the analytic tracks how many distinct OAuth applications are created by each service principal. This is key for SOC teams to pinpoint potential attack staging, where an attacker might use a compromised or malicious service principal to rapidly establish multiple service principals, facilitating network infiltration or expansion. While the default threshold is set to trigger on more than three applications, security teams should adjust this to fit their specific environment's norm +description: The following analytic detects when a single service principal in Azure + AD creates more than three unique OAuth applications within a 10-minute span. It + leverages Azure AD audit logs, specifically monitoring the 'Add service principal' + operation initiated by service principals. This behavior is significant as it may + indicate an attacker using a compromised or malicious service principal to rapidly + establish multiple service principals, potentially staging an attack. If confirmed + malicious, this activity could facilitate network infiltration or expansion, allowing + the attacker to gain unauthorized access and persist within the environment. search: ' `azure_monitor_aad` operationName="Add service principal" properties.initiatedBy.app.appId=* - | rename properties.* as * - | bucket span=10m _time - | rename targetResources{}.displayName as displayName - | rename targetResources{}.type as type - | rename initiatedBy.app.displayName as src_user - | stats min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName dc(displayName) as unique_apps by src_user - | where unique_apps > 3 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multiple_service_principals_created_by_sp_filter`' + | rename properties.* as * | bucket span=10m _time | rename targetResources{}.displayName + as displayName | rename targetResources{}.type as type | rename initiatedBy.app.displayName + as src_user | stats min(_time) as firstTime max(_time) as lastTime values(displayName) + as displayName dc(displayName) as unique_apps by src_user | where unique_apps > + 3 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_multiple_service_principals_created_by_sp_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. -known_false_positives: Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. +known_false_positives: Certain users or applications may create multiple service principals + in a short period of time for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1136/003/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -34,7 +38,8 @@ tags: asset_type: Azure Active Directory confidence: 60 impact: 70 - message: Multiple OAuth applications were created by $src_user$ in a short period of time + message: Multiple OAuth applications were created by $src_user$ in a short period + of time mitre_attack_id: - T1136.003 observable: @@ -53,7 +58,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_multiple_service_principals_created/azure_ad_multiple_service_principals_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_multiple_service_principals_created/azure_ad_multiple_service_principals_created.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_multiple_service_principals_created_by_user.yml b/detections/cloud/azure_ad_multiple_service_principals_created_by_user.yml index 9e942685cf..bb71615da5 100644 --- a/detections/cloud/azure_ad_multiple_service_principals_created_by_user.yml +++ b/detections/cloud/azure_ad_multiple_service_principals_created_by_user.yml @@ -1,27 +1,32 @@ name: Azure AD Multiple Service Principals Created by User id: 32880707-f512-414e-bd7f-204c0c85b758 -version: 1 -date: '2024-02-07' +version: 2 +date: '2024-05-13' author: Mauricio Velazco, Splunk -data_source: +data_source: - Azure Active Directory Add service principal type: Anomaly status: production -description: This detection focuses on identifying instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD, a potential indicator of malicious activity. By monitoring the 'Add service principal' operation and aggregating the data with a 10-minute bucket span, it tracks the number of distinct OAuth applications created by each user. This analytic is crucial for SOC teams to detect possible staging of attacks, where an adversary might rapidly create multiple service principals as part of their infiltration or expansion strategy within the network. The threshold of three applications is set to flag unusual behavior, but security teams are advised to adjust this value to suit the normal operational patterns of their environment +description: The following analytic identifies instances where a single user creates + more than three unique OAuth applications within a 10-minute timeframe in Azure + AD. It detects this activity by monitoring the 'Add service principal' operation + and aggregating data in 10-minute intervals. This behavior is significant as it + may indicate an adversary rapidly creating multiple service principals to stage + an attack or expand their foothold within the network. If confirmed malicious, this + activity could allow attackers to establish persistence, escalate privileges, or + access sensitive information within the Azure environment. search: ' `azure_monitor_aad` operationName="Add service principal" properties.initiatedBy.user.id=* - | rename properties.* as * - | bucket span=10m _time - | rename targetResources{}.displayName as displayName - | stats min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName dc(displayName) as unique_apps by src_user - | where unique_apps > 3 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_multiple_service_principals_created_by_user_filter`' + | rename properties.* as * | bucket span=10m _time | rename targetResources{}.displayName + as displayName | stats min(_time) as firstTime max(_time) as lastTime values(displayName) + as displayName dc(displayName) as unique_apps by src_user | where unique_apps > + 3 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_multiple_service_principals_created_by_user_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. -known_false_positives: Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. +known_false_positives: Certain users or applications may create multiple service principals + in a short period of time for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1136/003/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -32,7 +37,8 @@ tags: asset_type: Azure Active Directory confidence: 60 impact: 70 - message: Multiple OAuth applications were created by $src_user$ in a short period of time + message: Multiple OAuth applications were created by $src_user$ in a short period + of time mitre_attack_id: - T1136.003 observable: @@ -55,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_multiple_service_principals_created/azure_ad_multiple_service_principals_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_multiple_service_principals_created/azure_ad_multiple_service_principals_created.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_multiple_users_failing_to_authenticate_from_ip.yml b/detections/cloud/azure_ad_multiple_users_failing_to_authenticate_from_ip.yml index 73fa6e51e5..3b4582fc2e 100644 --- a/detections/cloud/azure_ad_multiple_users_failing_to_authenticate_from_ip.yml +++ b/detections/cloud/azure_ad_multiple_users_failing_to_authenticate_from_ip.yml @@ -1,33 +1,30 @@ name: Azure AD Multiple Users Failing To Authenticate From Ip id: 94481a6a-8f59-4c86-957f-55a71e3612a6 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-13' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: 'The following analytic identifies one source Ip failing to authenticate - with 30 unique valid users within 5 minutes. This behavior could represent an adversary - performing a Password Spraying attack against an Azure Active Directory tenant to - obtain initial access or elevate privileges. Error Code 50126 represents an invalid - password. This logic can be used for real time security monitoring as well as threat - hunting exercises. - - Azure AD tenants can be very different depending on the organization. Users should - test this detection and customize the arbitrary threshold if needed.' -data_source: +description: 'The following analytic detects a single source IP failing to authenticate + with 30 unique valid users within 5 minutes in Azure Active Directory. It leverages + Azure AD SignInLogs with error code 50126, indicating invalid passwords. This behavior + is significant as it may indicate a Password Spraying attack, where an adversary + attempts to gain initial access or elevate privileges by trying common passwords + across many accounts. If confirmed malicious, this activity could lead to unauthorized + access, data breaches, or privilege escalation within the Azure AD environment.' +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false - | rename properties.* as * - | bucket span=5m _time - | stats count min(_time) as firstTime max(_time) as lastTime dc(user) AS unique_accounts values(user) as user by src_ip - | where unique_accounts > 30 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 + properties.authenticationDetails{}.succeeded=false | rename properties.* as * | + bucket span=5m _time | stats count min(_time) as firstTime max(_time) as lastTime + dc(user) AS unique_accounts values(user) as user by src_ip | where unique_accounts + > 30 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_multiple_users_failing_to_authenticate_from_ip_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. references: @@ -41,8 +38,7 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 70 - message: Source Ip $src_ip$ failed to authenticate with 30 users - within 5 minutes. + message: Source Ip $src_ip$ failed to authenticate with 30 users within 5 minutes. mitre_attack_id: - T1586 - T1586.003 @@ -74,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_new_custom_domain_added.yml b/detections/cloud/azure_ad_new_custom_domain_added.yml index 6469ec3e21..9699b2bed5 100644 --- a/detections/cloud/azure_ad_new_custom_domain_added.yml +++ b/detections/cloud/azure_ad_new_custom_domain_added.yml @@ -1,36 +1,30 @@ name: Azure AD New Custom Domain Added id: 30c47f45-dd6a-4720-9963-0bca6c8686ef -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies the addition of a new custom domain - within an Azure Active Directory tenant. Adding a custom domain is a step required - to set up the Azure Active Directory identity federation backdoor technique discovered - by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses - the concept of domains to manage directories of identities. A new Azure AD tenant - will initially contain a single domain that is commonly called the `cloud-only` - onmicrosoft.com domain. Organizations can also add their registered custom domains - to Azure AD for email addresses to match the organizations domain name. If the organization - intends to use a third-party identity provider such as ADFS for authentication, - the added custom domains can be configured as federated. An adversary who has obtained - privileged access to an Azure AD tenant may leverage this technique to establish - persistence and be able to authenticate to Azure AD impersonating any user and bypassing - the requirement to have a valid password and/or perform MFA. -data_source: +description: The following analytic detects the addition of a new custom domain within + an Azure Active Directory (AD) tenant. It leverages Azure AD AuditLogs to identify + successful "Add unverified domain" operations. This activity is significant as it + may indicate an adversary attempting to establish persistence by setting up identity + federation backdoors, allowing them to impersonate users and bypass authentication + mechanisms. If confirmed malicious, this could enable attackers to gain unauthorized + access, escalate privileges, and maintain long-term access to the Azure AD environment, + posing a severe security risk. +data_source: - Azure Active Directory Add unverified domain search: ' `azure_monitor_aad` operationName="Add unverified domain" properties.result=success - | rename properties.* as * - | rename targetResources{}.displayName as domain - | stats count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, src_ip - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | rename properties.* as * | rename targetResources{}.displayName as domain | stats + count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, + src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_new_custom_domain_added_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLogs log category. known_false_positives: In most organizations, new customm domains will be updated infrequently. Filter as needed. references: @@ -71,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_new_federated_domain_added.yml b/detections/cloud/azure_ad_new_federated_domain_added.yml index 7251122626..a0b3cad525 100644 --- a/detections/cloud/azure_ad_new_federated_domain_added.yml +++ b/detections/cloud/azure_ad_new_federated_domain_added.yml @@ -1,36 +1,29 @@ name: Azure AD New Federated Domain Added id: a87cd633-076d-4ab2-9047-977751a3c1a0 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-28' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies the addition of a new federated domain - within an Azure Active Directory tenant. This event could represent the execution - of the Azure Active Directory identity federation backdoor technique discovered - by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses - the concept of domains to manage directories of identities. A new Azure AD tenant - will initially contain a single domain that is commonly called the `cloud-only` - onmicrosoft.com domain. Organizations can also add their registered custom domains - to Azure AD for email addresses to match the organizations domain name. If the organization - intends to use a third-party identity provider such as ADFS for authentication, - the added custom domains can be configured as federated. An adversary who has obtained - privileged access to an Azure AD tenant may leverage this technique to establish - persistence and be able to authenticate to Azure AD impersonating any user and bypassing - the requirement to have a valid password and/or perform MFA. -data_source: +description: The following analytic detects the addition of a new federated domain + within an Azure Active Directory tenant. It leverages Azure AD AuditLogs to identify + successful "Set domain authentication" operations. This activity is significant + as it may indicate the use of the Azure AD identity federation backdoor technique, + allowing an adversary to establish persistence. If confirmed malicious, the attacker + could impersonate any user, bypassing password and MFA requirements, potentially + leading to unauthorized access and control over the Azure AD environment. +data_source: - Azure Active Directory Set domain authentication search: ' `azure_monitor_aad` operationName="Set domain authentication" "properties.result"=success - | rename properties.* as * - | rename targetResources{}.displayName as domain - | stats count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, src_ip - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | rename properties.* as * | rename targetResources{}.displayName as domain | stats + count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, + src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_new_federated_domain_added_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLogs log category. known_false_positives: In most organizations, domain federation settings will be updated infrequently. Filter as needed. references: @@ -70,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_new_mfa_method_registered.yml b/detections/cloud/azure_ad_new_mfa_method_registered.yml index bce3a74fdf..601fed445a 100644 --- a/detections/cloud/azure_ad_new_mfa_method_registered.yml +++ b/detections/cloud/azure_ad_new_mfa_method_registered.yml @@ -1,32 +1,43 @@ name: Azure AD New MFA Method Registered id: 0488e814-eb81-42c3-9f1f-b2244973e3a3 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-16' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Update user -description: This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +description: The following analytic detects the registration of a new Multi-Factor + Authentication (MFA) method for a user account in Azure Active Directory. It leverages + Azure AD audit logs to identify changes in MFA configurations. This activity is + significant because adding a new MFA method can indicate an attacker's attempt to + maintain persistence on a compromised account. If confirmed malicious, the attacker + could bypass existing security measures, solidify their access, and potentially + escalate privileges, access sensitive data, or make unauthorized changes. Immediate + verification and remediation are required to secure the affected account. search: >- - `azure_monitor_aad` operationName="Update user" - | rename properties.* as * - | eval propertyName = mvindex('targetResources{}.modifiedProperties{}.displayName', 0) - | search propertyName = StrongAuthenticationMethod - | eval oldvalue = mvindex('targetResources{}.modifiedProperties{}.oldValue',0) - | eval newvalue = mvindex('targetResources{}.modifiedProperties{}.newValue',0) - | rex field=newvalue max_match=0 "(?i)(?\"MethodType\")" - | rex field=oldvalue max_match=0 "(?i)(?\"MethodType\")" - | eval count_new_method_type = coalesce(mvcount(new_method_type), 0) - | eval count_old_method_type = coalesce(mvcount(old_method_type), 0) - | stats earliest(_time) as firstTime latest(_time) as lastTime values(propertyName) by user newvalue oldvalue - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_new_mfa_method_registered_filter` + `azure_monitor_aad` operationName="Update user" + | rename properties.* as * | eval propertyName = mvindex('targetResources{}.modifiedProperties{}.displayName', + 0) + | search propertyName = StrongAuthenticationMethod + | eval oldvalue = mvindex('targetResources{}.modifiedProperties{}.oldValue',0) + | eval newvalue = mvindex('targetResources{}.modifiedProperties{}.newValue',0) + | rex field=newvalue max_match=0 "(?i)(?\"MethodType\")" + | rex field=oldvalue max_match=0 "(?i)(?\"MethodType\")" + | eval count_new_method_type = coalesce(mvcount(new_method_type), 0) + | eval count_old_method_type = coalesce(mvcount(old_method_type), 0) + | stats earliest(_time) as firstTime latest(_time) as lastTime values(propertyName) + by user newvalue oldvalue + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_new_mfa_method_registered_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: Users may register MFA methods legitimally, investigate and filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. +known_false_positives: Users may register MFA methods legitimally, investigate and + filter as needed. references: - https://attack.mitre.org/techniques/T1098/005/ - https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/ @@ -62,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/azure_ad_register_new_mfa_method/azure_ad_register_new_mfa_method.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/azure_ad_register_new_mfa_method/azure_ad_register_new_mfa_method.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_new_mfa_method_registered_for_user.yml b/detections/cloud/azure_ad_new_mfa_method_registered_for_user.yml index de7c9384d6..e0e0bd3bc5 100644 --- a/detections/cloud/azure_ad_new_mfa_method_registered_for_user.yml +++ b/detections/cloud/azure_ad_new_mfa_method_registered_for_user.yml @@ -1,26 +1,29 @@ name: Azure AD New MFA Method Registered For User id: 2628b087-4189-403f-9044-87403f777a1b -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the registration of a new Multi Factor - authentication method for an Azure AD account. Adversaries who have obtained unauthorized - access to an Azure AD account may register a new MFA method to maintain persistence. -data_source: +description: The following analytic detects the registration of a new Multi-Factor + Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs + to identify when a user registers new security information. This activity is significant + because adversaries who gain unauthorized access to an account may add their own + MFA method to maintain persistence. If confirmed malicious, this could allow attackers + to bypass existing security controls, maintain long-term access, and potentially + escalate their privileges within the environment. +data_source: - Azure Active Directory User registered security info -search: ' `azure_monitor_aad` category=AuditLogs operationName="User registered security info" properties.operationType=Add - | rename properties.* as * - | rename targetResources{}.* as * - | stats count min(_time) as firstTime max(_time) as lastTime by user, resultDescription, result, src_ip - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: ' `azure_monitor_aad` category=AuditLogs operationName="User registered security + info" properties.operationType=Add | rename properties.* as * | rename targetResources{}.* + as * | stats count min(_time) as firstTime max(_time) as lastTime by user, resultDescription, + result, src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_new_mfa_method_registered_for_user_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLogs log category. known_false_positives: Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. references: @@ -66,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/azure_ad_new_mfa_method_registered_for_user/azuread.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/azure_ad_new_mfa_method_registered_for_user/azuread.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml index 410e8c8825..3e4b3baed2 100644 --- a/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml +++ b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml @@ -1,27 +1,41 @@ name: Azure AD OAuth Application Consent Granted By User id: 10ec9031-015b-4617-b453-c0c1ab729007 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Consent to application -description: This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. +description: The following analytic detects when a user in an Azure AD environment + grants consent to an OAuth application. It leverages Azure AD audit logs to identify + events where users approve application consents. This activity is significant as + it can expose organizational data to third-party applications, a common tactic used + by malicious actors to gain unauthorized access. If confirmed malicious, this could + lead to unauthorized access to sensitive information and resources. Immediate investigation + is required to validate the application's legitimacy, review permissions, and mitigate + potential risks. search: >- `azure_monitor_aad` operationName="Consent to application" properties.result=success - | rename properties.* as * - | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions"), -1) + | rename properties.* as * | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Permissions"), -1) | eval permissions = mvindex('targetResources{}.modifiedProperties{}.newValue',permissions_index) | rex field=permissions "Scope: (?[^,]+)" - | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, Scope + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, + Scope | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_oauth_application_consent_granted_by_user_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: False positives may occur if users are granting consents as part of legitimate application integrations or setups. It is crucial to review the application and the permissions it requests to ensure they align with organizational policies and security best practices. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. +known_false_positives: False positives may occur if users are granting consents as + part of legitimate application integrations or setups. It is crucial to review the + application and the permissions it requests to ensure they align with organizational + policies and security best practices. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -58,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_granted/azure_ad_user_consent_granted.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_granted/azure_ad_user_consent_granted.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_pim_role_assigned.yml b/detections/cloud/azure_ad_pim_role_assigned.yml index 69c8c94e84..6d4ea20cdb 100644 --- a/detections/cloud/azure_ad_pim_role_assigned.yml +++ b/detections/cloud/azure_ad_pim_role_assigned.yml @@ -1,29 +1,31 @@ name: Azure AD PIM Role Assigned id: fcd6dfeb-191c-46a0-a29c-c306382145ab -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory -description: The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD - that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the - risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role - assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful - security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their - legitimacy. +description: The following analytic detects the assignment of an Azure AD Privileged + Identity Management (PIM) role. It leverages Azure Active Directory events to identify + when a user is added as an eligible member to a PIM role. This activity is significant + because PIM roles grant elevated privileges, and their assignment should be closely + monitored to prevent unauthorized access. If confirmed malicious, an attacker could + exploit this to gain privileged access, potentially leading to unauthorized actions, + data breaches, or further compromise of the environment. search: ' `azure_monitor_aad` operationName="Add eligible member to role in PIM completed*" - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(targetResources{}.displayName) as displayName by result, operationName, initiatedBy.user.displayName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_pim_role_assigned_filter`' + | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + values(user) as user values(targetResources{}.displayName) as displayName by result, + operationName, initiatedBy.user.displayName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_pim_role_assigned_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: As part of legitimate administrative behavior, users may be assigned PIM roles. Filter as needed + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. +known_false_positives: As part of legitimate administrative behavior, users may be + assigned PIM roles. Filter as needed references: - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-activate-role @@ -54,12 +56,13 @@ tags: - properties - operationName - user - - initiatedBy.user.userPrincipalName + - initiatedBy.user.userPrincipalName - result security_domain: identity tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log source: Azure AD - sourcetype: azure:monitor:aad \ No newline at end of file + sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_pim_role_assignment_activated.yml b/detections/cloud/azure_ad_pim_role_assignment_activated.yml index 19c5909a23..e87d24a8b2 100644 --- a/detections/cloud/azure_ad_pim_role_assignment_activated.yml +++ b/detections/cloud/azure_ad_pim_role_assignment_activated.yml @@ -1,30 +1,32 @@ name: Azure AD PIM Role Assignment Activated id: 952e80d0-e343-439b-83f4-808c3e6fbf2e -version: 3 -date: '2023-12-20' +version: 4 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory -description: The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD - that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the - risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role - assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful - security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their - legitimacy. +description: The following analytic detects the activation of an Azure AD Privileged + Identity Management (PIM) role. It leverages Azure Active Directory events to identify + when a user activates a PIM role assignment, indicated by the "Add member to role + completed (PIM activation)" operation. Monitoring this activity is crucial as PIM + roles grant elevated privileges, and unauthorized activation could indicate an adversary + attempting to gain privileged access. If confirmed malicious, this could lead to + unauthorized administrative actions, data breaches, or further compromise of the + Azure environment. search: ' `azure_monitor_aad` operationName="Add member to role completed (PIM activation)" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(targetResources{}.displayName) as displayName by initiatedBy, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_pim_role_assignment_activated_filter`' + | rename properties.* as * | rename initiatedBy.user.userPrincipalName as initiatedBy + | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user + values(targetResources{}.displayName) as displayName by initiatedBy, result, operationName + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_pim_role_assignment_activated_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. +known_false_positives: As part of legitimate administrative behavior, users may activate + PIM roles. Filter as needed references: - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-activate-role @@ -54,13 +56,14 @@ tags: - properties - operationName - user - - initiatedBy.user.userPrincipalName + - initiatedBy.user.userPrincipalName - result risk_score: 35 security_domain: identity tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log source: eventhub://researchhub1.servicebus.windows.net/azureadhub; sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_privileged_authentication_administrator_role_assigned.yml b/detections/cloud/azure_ad_privileged_authentication_administrator_role_assigned.yml index 909458ef70..f0c6deb71a 100644 --- a/detections/cloud/azure_ad_privileged_authentication_administrator_role_assigned.yml +++ b/detections/cloud/azure_ad_privileged_authentication_administrator_role_assigned.yml @@ -1,29 +1,32 @@ name: Azure AD Privileged Authentication Administrator Role Assigned id: a7da845d-6fae-41cf-b823-6c0b8c55814a -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-20' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Add member to role -description: The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication - methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive - or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. - Red teams and adversaries alike may abuse this role to escalate their privileges. -search: ' `azure_monitor_aad` "operationName"="Add member to role" "properties.targetResources{}.modifiedProperties{}.newValue"="\"Privileged Authentication Administrator\"" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by initiatedBy, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_privileged_authentication_administrator_role_assigned_filter`' +description: The following analytic detects the assignment of the Privileged Authentication + Administrator role to an Azure AD user. It leverages Azure Active Directory audit + logs to identify when this specific role is assigned. This activity is significant + because users in this role can set or reset authentication methods for any user, + including those in privileged roles like Global Administrators. If confirmed malicious, + an attacker could change credentials and assume the identity and permissions of + high-privilege users, potentially leading to unauthorized access to sensitive information + and critical configurations. +search: ' `azure_monitor_aad` "operationName"="Add member to role" "properties.targetResources{}.modifiedProperties{}.newValue"="\"Privileged + Authentication Administrator\"" | rename properties.* as * | rename initiatedBy.user.userPrincipalName + as initiatedBy | stats count min(_time) as firstTime max(_time) as lastTime values(user) + as user by initiatedBy, result, operationName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_privileged_authentication_administrator_role_assigned_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: Administrators may legitimately assign the Privileged Authentication Administrator role - as part of administrative tasks. Filter as needed. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. +known_false_positives: Administrators may legitimately assign the Privileged Authentication + Administrator role as part of administrative tasks. Filter as needed. references: - https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#privileged-authentication-administrator - https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48 @@ -34,8 +37,8 @@ tags: asset_type: Azure Active Directory confidence: 50 impact: 100 - message: The privileged Azure AD role Privileged Authentication Administrator was assigned for User $user$ initiated - by $initiatedBy$ + message: The privileged Azure AD role Privileged Authentication Administrator was + assigned for User $user$ initiated by $initiatedBy$ mitre_attack_id: - T1003.002 observable: @@ -62,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/azure_ad_privileged_graph_api_permission_assigned.yml b/detections/cloud/azure_ad_privileged_graph_api_permission_assigned.yml index 0e5a21d608..36832caf61 100644 --- a/detections/cloud/azure_ad_privileged_graph_api_permission_assigned.yml +++ b/detections/cloud/azure_ad_privileged_graph_api_permission_assigned.yml @@ -1,28 +1,38 @@ name: Azure AD Privileged Graph API Permission Assigned id: 5521f8c5-1aa3-473c-9eb7-853701924a06 -version: 1 -date: '2024-01-30' +version: 2 +date: '2024-05-11' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Update application -description: This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches. +description: The following analytic detects the assignment of high-risk Graph API + permissions in Azure AD, specifically Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, + and RoleManagement.ReadWrite.Directory. It uses azure_monitor_aad data to scan AuditLogs + for 'Update application' operations, identifying when these permissions are assigned. + This activity is significant as it grants broad control over Azure AD, including + application and directory settings. If confirmed malicious, it could lead to unauthorized + modifications and potential security breaches, compromising the integrity and security + of the Azure AD environment. Immediate investigation is required. search: >- - `azure_monitor_aad` category=AuditLogs operationName="Update application" - | eval newvalue = mvindex('properties.targetResources{}.modifiedProperties{}.newValue',0) - | spath input=newvalue - | search "{}.RequiredAppPermissions{}.EntitlementId"="1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9" OR "{}.RequiredAppPermissions{}.EntitlementId"="06b708a9-e830-4db3-a914-8e69da51d44f" OR "{}.RequiredAppPermissions{}.EntitlementId"="9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" - | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) by user, object, user_agent, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_privileged_graph_api_permission_assigned_filter` + `azure_monitor_aad` category=AuditLogs operationName="Update application" | eval + newvalue = mvindex('properties.targetResources{}.modifiedProperties{}.newValue',0) + | spath input=newvalue | search "{}.RequiredAppPermissions{}.EntitlementId"="1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9" + OR "{}.RequiredAppPermissions{}.EntitlementId"="06b708a9-e830-4db3-a914-8e69da51d44f" + OR "{}.RequiredAppPermissions{}.EntitlementId"="9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" | + eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) + by user, object, user_agent, operationName + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_privileged_graph_api_permission_assigned_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. +known_false_positives: Privileged Graph API permissions may be assigned for legitimate + purposes. Filter as needed. references: - https://cloudbrothers.info/en/azure-attack-paths/ - https://github.com/mandiant/Mandiant-Azure-AD-Investigator/blob/master/MandiantAzureADInvestigator.json @@ -61,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_privileged_graph_perm_assigned/azure_ad_privileged_graph_perm_assigned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_privileged_graph_perm_assigned/azure_ad_privileged_graph_perm_assigned.log source: Azure AD sourcetype: azure:monitor:aad - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/cloud/azure_ad_privileged_role_assigned.yml b/detections/cloud/azure_ad_privileged_role_assigned.yml index 4547aa93a9..841b4c60f5 100644 --- a/detections/cloud/azure_ad_privileged_role_assigned.yml +++ b/detections/cloud/azure_ad_privileged_role_assigned.yml @@ -1,15 +1,18 @@ name: Azure AD Privileged Role Assigned id: a28f0bc3-3400-4a6e-a2da-89b9e95f0d2a version: 3 -date: '2023-12-20' +date: '2024-05-29' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies the assignment of sensitive and privileged - Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike - may assign these roles to a compromised account to establish Persistence in an Azure - AD environment. -data_source: +description: The following analytic detects the assignment of privileged Azure Active + Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring + the "Add member to role" operation. This activity is significant as adversaries + may assign privileged roles to compromised accounts to maintain persistence within + the Azure AD environment. If confirmed malicious, this could allow attackers to + escalate privileges, access sensitive information, and maintain long-term control + over the Azure AD infrastructure. +data_source: - Azure Active Directory Add member to role search: ' `azure_monitor_aad` "operationName"="Add member to role" | rename properties.* as * | rename initiatedBy.user.userPrincipalName as initiatedBy @@ -24,7 +27,8 @@ search: ' `azure_monitor_aad` "operationName"="Add member to role" | rename pro how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. known_false_positives: Administrators will legitimately assign the privileged roles users as part of administrative tasks. Filter as needed. references: @@ -41,8 +45,7 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 70 - message: A privileged Azure AD role was assigned for User $user$ initiated - by $initiatedBy$ + message: A privileged Azure AD role was assigned for User $user$ initiated by $initiatedBy$ mitre_attack_id: - T1098 - T1098.003 @@ -70,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml b/detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml index 7cc67019f4..3022a4b9fd 100644 --- a/detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml +++ b/detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml @@ -1,12 +1,19 @@ name: Azure AD Privileged Role Assigned to Service Principal id: 5dfaa3d3-e2e4-4053-8252-16d9ee528c41 version: 3 -date: '2023-12-20' +date: '2024-05-31' author: Mauricio Velazco, Splunk status: production type: TTP -description: "The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals." -data_source: +description: "The following analytic detects the assignment of privileged roles to + service principals in Azure Active Directory (AD). It leverages the AuditLogs log + category from ingested Azure AD events. This activity is significant because assigning + elevated permissions to non-human entities can lead to unauthorized access or malicious + activities. If confirmed malicious, attackers could exploit these service principals + to gain elevated access to Azure resources, potentially compromising sensitive data + and critical infrastructure. Monitoring this behavior helps prevent privilege escalation + and ensures the security of Azure environments." +data_source: - Azure Active Directory Add member to role search: ' `azure_monitor_aad` operationName="Add member to role" | rename properties.* as * @@ -25,7 +32,8 @@ search: ' `azure_monitor_aad` operationName="Add member to role" how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. known_false_positives: Administrators may legitimately assign the privileged roles to Service Principals as part of administrative tasks. Filter as needed. references: @@ -61,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_privileged_role_serviceprincipal/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_privileged_role_serviceprincipal/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_service_principal_authentication.yml b/detections/cloud/azure_ad_service_principal_authentication.yml index e1e85883de..e357d5d3cb 100644 --- a/detections/cloud/azure_ad_service_principal_authentication.yml +++ b/detections/cloud/azure_ad_service_principal_authentication.yml @@ -1,23 +1,34 @@ name: Azure AD Service Principal Authentication id: 5a2ec401-60bb-474e-b936-1e66e7aa4060 -version: 1 -date: '2024-02-12' +version: 2 +date: '2024-05-21' author: Mauricio Velazco, Splunk -data_source: +data_source: - Azure Active Directory Sign-in activity type: TTP status: production -description: Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities. +description: The following analytic identifies authentication events of service principals + in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically + targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers + details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring + these events is significant for SOC teams to distinguish between normal application + authentication and potential anomalies, which could indicate compromised credentials + or malicious activities. If confirmed malicious, attackers could gain unauthorized + access to resources, leading to data breaches or further exploitation within the + environment. search: ' `azure_monitor_aad` operationName="Sign-in activity" category=ServicePrincipalSignInLogs - | rename properties.* as * - | stats count earliest(_time) as firstTime latest(_time) as lastTime by user, user_id, src_ip, resourceDisplayName, resourceId - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_service_principal_authentication_filter`' -how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. -known_false_positives: Service Principals will legitimally authenticate remotely to your tenant. Implementing this detection after establishing a baseline enables a more accurate identification of security threats, ensuring proactive and informed responses to safeguard the Azure AD environment. - source ips. + | rename properties.* as * | stats count earliest(_time) as firstTime latest(_time) + as lastTime by user, user_id, src_ip, resourceDisplayName, resourceId | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_service_principal_authentication_filter`' +how_to_implement: You must install the latest version of Splunk Add-on for Microsoft + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. +known_false_positives: Service Principals will legitimally authenticate remotely to + your tenant. Implementing this detection after establishing a baseline enables a + more accurate identification of security threats, ensuring proactive and informed + responses to safeguard the Azure AD environment. source ips. references: - https://attack.mitre.org/techniques/T1078/004/ - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins#service-principal-sign-ins @@ -25,7 +36,7 @@ tags: analytic_story: - Azure Active Directory Account Takeover - NOBELIUM Group - asset_type: Azure Active Directory + asset_type: Azure Active Directory confidence: 50 impact: 50 message: Service Principal $user$ authenticated from $src_ip$ @@ -58,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_ad_service_principal_authentication/azure_ad_service_principal_authentication.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_ad_service_principal_authentication/azure_ad_service_principal_authentication.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_service_principal_created.yml b/detections/cloud/azure_ad_service_principal_created.yml index 890da5086a..174a84df04 100644 --- a/detections/cloud/azure_ad_service_principal_created.yml +++ b/detections/cloud/azure_ad_service_principal_created.yml @@ -1,32 +1,30 @@ name: Azure AD Service Principal Created id: f8ba49e7-ffd3-4b53-8f61-e73974583c5d -version: 1 -date: '2022-08-17' +version: 2 +date: '2024-05-30' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the creation of a Service Principal - in an Azure AD environment. An Azure Service Principal is an identity designed to - be used with applications, services, and automated tools to access resources. It - is similar to a service account within an Active Directory environment. Service - Principal authentication does not support multi-factor authentication nor conditional - access policies. Adversaries and red teams alike who have obtained administrative - access may create a Service Principal to establish Persistence and obtain single-factor - access to an Azure AD environment. -data_source: +description: The following analytic detects the creation of a Service Principal in + an Azure AD environment. It leverages Azure Active Directory events ingested through + EventHub, specifically monitoring the "Add service principal" operation. This activity + is significant because Service Principals can be used by adversaries to establish + persistence and bypass multi-factor authentication and conditional access policies. + If confirmed malicious, this could allow attackers to maintain single-factor access + to the Azure AD environment, potentially leading to unauthorized access to resources + and prolonged undetected activity. +data_source: - Azure Active Directory Add service principal search: '`azure_monitor_aad` operationName="Add service principal" properties.initiatedBy.user.id=* - | rename properties.* as * - | rename targetResources{}.displayName as displayName - | rename targetResources{}.type as type - | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by type, user, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_service_principal_created_filter`' + | rename properties.* as * | rename targetResources{}.displayName as displayName + | rename targetResources{}.type as type | stats count min(_time) as firstTime max(_time) + as lastTime values(displayName) as displayName by type, user, result, operationName + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_service_principal_created_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment thorough an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + You must be ingesting Azure Active Directory events into your Splunk environment + thorough an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. known_false_positives: Administrator may legitimately create Service Principal. Filter as needed. references: @@ -65,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_add_service_principal/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_add_service_principal/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_service_principal_new_client_credentials.yml b/detections/cloud/azure_ad_service_principal_new_client_credentials.yml index a95272ce69..99e48bd36c 100644 --- a/detections/cloud/azure_ad_service_principal_new_client_credentials.yml +++ b/detections/cloud/azure_ad_service_principal_new_client_credentials.yml @@ -1,33 +1,30 @@ name: Azure AD Service Principal New Client Credentials id: e3adc0d3-9e4b-4b5d-b662-12cec1adff2a -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-11' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies the addition of new credentials for Service - Principals and Applications in addition to existing legitimate credentials in Azure - AD. These credentials include both x509 certificates and passwords. With sufficient - permissions, there are a variety of ways to add credentials including the Azure - Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries - and red teams alike who have obtained privileged access to Azure AD may add credentials - to Service Principals to maintain persistent access to victim accounts and other - instances within the Azure environment. By compromising an account who is an Owner of an application - with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and - logging in as the service principal. -data_source: +description: The following analytic detects the addition of new credentials to Service + Principals and Applications in Azure AD. It leverages Azure AD AuditLogs, specifically + monitoring the "Update application*Certificates and secrets management" operation. + This activity is significant as it may indicate an adversary attempting to maintain + persistent access or escalate privileges within the Azure environment. If confirmed + malicious, attackers could use these new credentials to log in as the service principal, + potentially compromising sensitive accounts and resources, leading to unauthorized + access and control over the Azure environment. +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category=AuditLogs operationName="Update application*Certificates and secrets management " - | rename properties.* as * - | rename targetResources{}.* as * - | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by user, modifiedProperties{}.newValue, src_ip - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_service_principal_new_client_credentials_filter`' +search: ' `azure_monitor_aad` category=AuditLogs operationName="Update application*Certificates + and secrets management " | rename properties.* as * | rename targetResources{}.* + as * | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) + as displayName by user, modifiedProperties{}.newValue, src_ip | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_service_principal_new_client_credentials_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the Signin log category. known_false_positives: Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. references: @@ -71,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/azure_ad_service_principal_credentials/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/azure_ad_service_principal_credentials/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_service_principal_owner_added.yml b/detections/cloud/azure_ad_service_principal_owner_added.yml index 53612a16f5..104b919d26 100644 --- a/detections/cloud/azure_ad_service_principal_owner_added.yml +++ b/detections/cloud/azure_ad_service_principal_owner_added.yml @@ -1,36 +1,32 @@ name: Azure AD Service Principal Owner Added id: 7ddf2084-6cf3-4a44-be83-474f7b73c701 -version: 3 -date: '2023-12-20' +version: 4 +date: '2024-05-28' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies the addition of a new owner for a Service - Principal within an Azure AD tenant. An Azure Service Principal is an identity designed - to be used with applications, services, and automated tools to access resources. - It is similar to a service account within an Active Directory environment. Service - Principal authentication does not support multi-factor authentication nor conditional - access policies. Adversaries and red teams alike who have obtained administrative - access may add a new owner for an existing Service Principal to establish Persistence - and obtain single-factor access to an Azure AD environment. Attackers who are looking to - escalate their privileges by leveraging a Service Principals permissions may also add a new owner. -data_source: +description: The following analytic detects the addition of a new owner to a Service + Principal within an Azure AD tenant. It leverages Azure Active Directory events + from the AuditLog log category to identify this activity. This behavior is significant + because Service Principals do not support multi-factor authentication or conditional + access policies, making them a target for adversaries seeking persistence or privilege + escalation. If confirmed malicious, this activity could allow attackers to maintain + access to the Azure AD environment with single-factor authentication, potentially + leading to unauthorized access and control over critical resources. +data_source: - Azure Active Directory Add owner to application -search: ' `azure_monitor_aad` operationName="Add owner to application" - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | rename targetResources{}.userPrincipalName as newOwner - | rename targetResources{}.modifiedProperties{}.newValue as displayName - | eval displayName = mvindex(displayName,1) - | where initiatedBy!=newOwner - | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by initiatedBy, result, operationName, newOwner - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_service_principal_owner_added_filter`' +search: ' `azure_monitor_aad` operationName="Add owner to application" | rename properties.* + as * | rename initiatedBy.user.userPrincipalName as initiatedBy | rename targetResources{}.userPrincipalName + as newOwner | rename targetResources{}.modifiedProperties{}.newValue as displayName + | eval displayName = mvindex(displayName,1) | where initiatedBy!=newOwner | stats + count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName + by initiatedBy, result, operationName, newOwner | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_service_principal_owner_added_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. known_false_positives: Administrator may legitimately add new owners for Service Principals. Filter as needed. references: @@ -71,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_add_serviceprincipal_owner/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_add_serviceprincipal_owner/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_successful_authentication_from_different_ips.yml b/detections/cloud/azure_ad_successful_authentication_from_different_ips.yml index fcf2ec56c7..01ce2310b9 100644 --- a/detections/cloud/azure_ad_successful_authentication_from_different_ips.yml +++ b/detections/cloud/azure_ad_successful_authentication_from_different_ips.yml @@ -1,30 +1,29 @@ name: Azure AD Successful Authentication From Different Ips id: be6d868d-33b6-4aaa-912e-724fb555b11a -version: 3 -date: '2023-12-20' +version: 4 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies an Azure AD account successfully authenticating - from more than one unique Ip address in the span of 30 minutes. This behavior could - represent an adversary who has stolen credentials via a phishing attack or some - other method and using them to access corporate online resources around the same - time as a legitimate user. As users may behave differently across organizations, - security teams should test and customize this detection to fit their environments. -data_source: +description: The following analytic detects an Azure AD account successfully authenticating + from multiple unique IP addresses within a 30-minute window. It leverages Azure + AD SignInLogs to identify instances where the same user logs in from different IPs + in a short time frame. This behavior is significant as it may indicate compromised + credentials being used by an adversary, potentially following a phishing attack. + If confirmed malicious, this activity could allow unauthorized access to corporate + resources, leading to data breaches or further exploitation within the network. +data_source: - Azure Active Directory search: ' `azure_monitor_aad` properties.authenticationDetails{}.succeeded=true category=SignInLogs - | rename properties.* as * - | bucket span=30m _time - | stats count min(_time) as firstTime max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) as appDisplayName by user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where unique_ips > 1 - | `azure_ad_successful_authentication_from_different_ips_filter`' + | rename properties.* as * | bucket span=30m _time | stats count min(_time) as firstTime + max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) + as appDisplayName by user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | where unique_ips > 1 | `azure_ad_successful_authentication_from_different_ips_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -39,8 +38,8 @@ tags: asset_type: Azure Tenant confidence: 80 impact: 70 - message: User $user$ has had successful authentication events from - more than one unique IP address in the span of 30 minutes. + message: User $user$ has had successful authentication events from more than one + unique IP address in the span of 30 minutes. mitre_attack_id: - T1110 - T1110.001 @@ -71,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_successful_authentication_from_different_ips/azuread.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_successful_authentication_from_different_ips/azuread.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_successful_powershell_authentication.yml b/detections/cloud/azure_ad_successful_powershell_authentication.yml index a75a4a2547..eeb37fcfc7 100644 --- a/detections/cloud/azure_ad_successful_powershell_authentication.yml +++ b/detections/cloud/azure_ad_successful_powershell_authentication.yml @@ -1,27 +1,30 @@ name: Azure AD Successful PowerShell Authentication id: 62f10052-d7b3-4e48-b57b-56f8e3ac7ceb -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-24' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP description: The following analytic identifies a successful authentication event against - an Azure AD tenant using PowerShell commandlets. This behavior is not common for - regular, non administrative users. After compromising an account in Azure AD, attackers - and red teams alike will perform enumeration and discovery techniques. One method - of executing these techniques is leveraging the native PowerShell modules. -data_source: + an Azure AD tenant using PowerShell cmdlets. This detection leverages Azure AD SignInLogs + to identify successful logins where the appDisplayName is "Microsoft Azure PowerShell." + This activity is significant because it is uncommon for regular, non-administrative + users to authenticate using PowerShell, and it may indicate enumeration and discovery + techniques by an attacker. If confirmed malicious, this activity could allow attackers + to perform extensive reconnaissance, potentially leading to privilege escalation + or further exploitation within the Azure environment. +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category=SignInLogs properties.authenticationDetails{}.succeeded=true properties.appDisplayName="Microsoft Azure PowerShell" - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, appDisplayName, user_agent - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_successful_powershell_authentication_filter`' +search: ' `azure_monitor_aad` category=SignInLogs properties.authenticationDetails{}.succeeded=true + properties.appDisplayName="Microsoft Azure PowerShell" | rename properties.* as + * | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user + by src_ip, appDisplayName, user_agent | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `azure_ad_successful_powershell_authentication_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: Administrative users will likely use PowerShell commandlets to troubleshoot and maintain the environment. Filter as needed. references: @@ -35,8 +38,7 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 60 - message: Successful authentication for user $user$ - using PowerShell. + message: Successful authentication for user $user$ using PowerShell. mitre_attack_id: - T1586 - T1586.003 @@ -68,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread_pws/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread_pws/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_successful_single_factor_authentication.yml b/detections/cloud/azure_ad_successful_single_factor_authentication.yml index 6d1503c136..dd84988f4c 100644 --- a/detections/cloud/azure_ad_successful_single_factor_authentication.yml +++ b/detections/cloud/azure_ad_successful_single_factor_authentication.yml @@ -1,24 +1,28 @@ name: Azure AD Successful Single-Factor Authentication id: a560e7f6-1711-4353-885b-40be53101fcd -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies a successful authentication event against - Azure Active Directory for an account without Multi-Factor Authentication enabled. - This could be evidence of a missconfiguration, a policy violation or an account - take over attempt that should be investigated -data_source: +description: The following analytic identifies a successful single-factor authentication + event against Azure Active Directory. It leverages Azure SignInLogs data, specifically + focusing on events where single-factor authentication succeeded. This activity is + significant as it may indicate a misconfiguration, policy violation, or potential + account takeover attempt. If confirmed malicious, an attacker could gain unauthorized + access to the account, potentially leading to data breaches, privilege escalation, + or further exploitation within the environment. +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category=SignInLogs properties.authenticationRequirement=singleFactorAuthentication properties.authenticationDetails{}.succeeded=true - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, appDisplayName, authenticationRequirement - | `azure_ad_successful_single_factor_authentication_filter`' +search: ' `azure_monitor_aad` category=SignInLogs properties.authenticationRequirement=singleFactorAuthentication + properties.authenticationDetails{}.succeeded=true | rename properties.* as * | stats + count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, + appDisplayName, authenticationRequirement | `azure_ad_successful_single_factor_authentication_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: Although not recommended, certain users may be required without multi-factor authentication. Filter as needed references: @@ -31,8 +35,7 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 50 - message: Successful authentication for user $user$ - without MFA + message: Successful authentication for user $user$ without MFA mitre_attack_id: - T1586 - T1586.003 @@ -64,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml index 6d6cf40cf0..e84950d54b 100644 --- a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml +++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml @@ -1,34 +1,43 @@ name: Azure AD Tenant Wide Admin Consent Granted id: dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418 -version: 2 -date: '2023-09-14' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Consent to application -description: The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations -search: >- - `azure_monitor_aad` operationName="Consent to application" - | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4) - | rename properties.* as * - | rex field=new_field "ConsentType: (?[^\,]+)" - | rex field=new_field "Scope: (?[^\,]+)" - | search ConsentType = "AllPrincipals" - | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, targetResources{}.displayName, targetResources{}.id, ConsentType, Scope - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_tenant_wide_admin_consent_granted_filter` +description: The following analytic identifies instances where admin consent is granted + to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically + events related to the admin consent action within the ApplicationManagement category. + This activity is significant because admin consent allows applications to access + data across the entire tenant, potentially exposing vast amounts of organizational + data. If confirmed malicious, an attacker could gain extensive and persistent access + to sensitive data, leading to data exfiltration, espionage, further malicious activities, + and potential compliance violations. +search: >- + `azure_monitor_aad` operationName="Consent to application" + | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', + 4) + | rename properties.* as * | rex field=new_field "ConsentType: (?[^\,]+)" + | rex field=new_field "Scope: (?[^\,]+)" | search ConsentType = "AllPrincipals" | + stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, + targetResources{}.displayName, targetResources{}.id, ConsentType, Scope + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `azure_ad_tenant_wide_admin_consent_granted_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlogs log category. -known_false_positives: Legitimate applications may be granted tenant wide consent, filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Auditlogs log category. +known_false_positives: Legitimate applications may be granted tenant wide consent, + filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ - https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 - https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent - https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal -- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ +- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ tags: analytic_story: - Azure Active Directory Persistence @@ -61,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_admin_consent/azure_ad_admin_consent.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_admin_consent/azure_ad_admin_consent.log source: Azure AD - sourcetype: azure:monitor:aad \ No newline at end of file + sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_unusual_number_of_failed_authentications_from_ip.yml b/detections/cloud/azure_ad_unusual_number_of_failed_authentications_from_ip.yml index a77d3c7e5d..c6061000f6 100644 --- a/detections/cloud/azure_ad_unusual_number_of_failed_authentications_from_ip.yml +++ b/detections/cloud/azure_ad_unusual_number_of_failed_authentications_from_ip.yml @@ -1,40 +1,32 @@ name: Azure AD Unusual Number of Failed Authentications From Ip id: 3d8d3a36-93b8-42d7-8d91-c5f24cec223d -version: 2 -date: '2022-07-11' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: 'The following analytic identifies one source Ip failing to authenticate - with multiple valid users. This behavior could represent an adversary performing - a Password Spraying attack against an Azure Active Directory tenant to obtain initial - access or elevate privileges. Error Code 50126 represents an invalid password. - - The detection calculates the standard deviation for source Ip and leverages the - 3-sigma statistical rule to identify an unusual number of failed authentication - attempts. To customize this analytic, users can try different combinations of the - `bucket` span time and the calculation of the `upperBound` field. This logic can - be used for real time security monitoring as well as threat hunting exercises. - - While looking for anomalies using statistical methods like the standard deviation - can have benefits, we also recommend using threshold-based detections to complement - coverage. A similar analytic following the threshold model is `Azure AD Multiple - Users Failing To Authenticate From Ip`.' -data_source: +description: 'The following analytic identifies a single source IP failing to authenticate + with multiple valid users, potentially indicating a Password Spraying attack against + an Azure Active Directory tenant. It uses Azure SignInLogs data and calculates the + standard deviation for source IPs, applying the 3-sigma rule to detect unusual numbers + of failed authentication attempts. This activity is significant as it may signal + an adversary attempting to gain initial access or elevate privileges. If confirmed + malicious, this could lead to unauthorized access, privilege escalation, and potential + compromise of sensitive information.' +data_source: - Azure Active Directory -search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false - | rename properties.* as * - | bucket span=5m _time - | stats dc(userPrincipalName) AS unique_accounts values(userPrincipalName) as userPrincipalName by _time, ipAddress - | eventstats avg(unique_accounts) as ip_avg, stdev(unique_accounts) as ip_std by ipAddress - | eval upperBound=(ip_avg+ip_std*3) +search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 + properties.authenticationDetails{}.succeeded=false | rename properties.* as * | + bucket span=5m _time | stats dc(userPrincipalName) AS unique_accounts values(userPrincipalName) + as userPrincipalName by _time, ipAddress | eventstats avg(unique_accounts) as ip_avg, + stdev(unique_accounts) as ip_std by ipAddress | eval upperBound=(ip_avg+ip_std*3) | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1,0) - | where isOutlier = 1 - | `azure_ad_unusual_number_of_failed_authentications_from_ip_filter`' + | where isOutlier = 1 | `azure_ad_unusual_number_of_failed_authentications_from_ip_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). - You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the Signin log category. known_false_positives: A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. references: @@ -80,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml index f46f25c060..188c0831f2 100644 --- a/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml +++ b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml @@ -1,30 +1,43 @@ name: Azure AD User Consent Blocked for Risky Application id: 06b8ec9a-d3b5-4882-8f16-04b4d10f5eab -version: 1 -date: '2023-10-27' +version: 2 +date: '2024-05-30' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Consent to application -description: The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +description: The following analytic detects instances where Azure AD has blocked a + user's attempt to grant consent to a risky or potentially malicious application. + This detection leverages Azure AD audit logs, focusing on user consent actions and + system-driven blocks. Monitoring these blocked consent attempts is crucial as it + highlights potential threats early on, indicating that a user might be targeted + or that malicious applications are attempting to infiltrate the organization. If + confirmed malicious, this activity suggests that Azure's security measures successfully + prevented a harmful application from accessing organizational data, warranting immediate + investigation to understand the context and take preventive measures. search: >- `azure_monitor_aad` operationName="Consent to application" properties.result=failure - | rename properties.* as * - | eval reason_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Reason") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Reason"), -1) - | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions"), -1) - | search reason_index >= 0 - | eval reason = mvindex('targetResources{}.modifiedProperties{}.newValue',reason_index) + | rename properties.* as * | eval reason_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Reason") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Reason"), -1) + | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', + "ConsentAction.Permissions"), -1) + | search reason_index >= 0 | eval reason = mvindex('targetResources{}.modifiedProperties{}.newValue',reason_index) | eval permissions = mvindex('targetResources{}.modifiedProperties{}.newValue',permissions_index) | search reason = "\"Risky application detected\"" | rex field=permissions "Scope: (?[^,]+)" - | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, reason, Scope + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, + reason, Scope | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_user_consent_blocked_for_risky_application_filter` how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the AuditLog log category. known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES references: - https://attack.mitre.org/techniques/T1528/ @@ -39,7 +52,8 @@ tags: asset_type: Azure Tenant confidence: 100 impact: 30 - message: Azure AD has blocked $user$ attempt to grant to consent to an application deemed risky. + message: Azure AD has blocked $user$ attempt to grant to consent to an application + deemed risky. mitre_attack_id: - T1528 observable: @@ -62,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_blocked/azure_ad_user_consent_blocked.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_blocked/azure_ad_user_consent_blocked.log source: Azure AD - sourcetype: azure:monitor:aad \ No newline at end of file + sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml index b44f1eabcd..3d0fd1b1a6 100644 --- a/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml +++ b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml @@ -1,23 +1,32 @@ name: Azure AD User Consent Denied for OAuth Application id: bb093c30-d860-4858-a56e-cd0895d5b49c -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-18' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - Azure Active Directory Sign-in activity -description: The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +description: The following analytic identifies instances where a user has denied consent + to an OAuth application seeking permissions within the Azure AD environment. This + detection leverages Azure AD's audit logs, specifically focusing on user consent + actions with error code 65004. Monitoring denied consent actions is significant + as it can indicate users recognizing potentially suspicious or untrusted applications. + If confirmed malicious, this activity could suggest attempts by unauthorized applications + to gain access, potentially leading to data breaches or unauthorized actions within + the environment. Understanding these denials helps refine security policies and + enhance user awareness. search: ' `azure_monitor_aad` operationName="Sign-in activity" properties.status.errorCode=65004 - | rename properties.* as * - | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, appDisplayName, status.failureReason - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_user_consent_denied_for_oauth_application_filter`' + | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime + by operationName, user, appDisplayName, status.failureReason | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_user_consent_denied_for_oauth_application_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft - Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. -known_false_positives: Users may deny consent for legitimate applications by mistake, filter as needed. + Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). + You must be ingesting Azure Active Directory events into your Splunk environment + through an EventHub. This analytic was written to be used with the azure:monitor:aad + sourcetype leveraging the SignInLogs log category. +known_false_positives: Users may deny consent for legitimate applications by mistake, + filter as needed. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -55,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_declined/azure_ad_user_consent_declined.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_declined/azure_ad_user_consent_declined.log source: Azure AD sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_user_enabled_and_password_reset.yml b/detections/cloud/azure_ad_user_enabled_and_password_reset.yml index f65d4d1ba1..d5914a8161 100644 --- a/detections/cloud/azure_ad_user_enabled_and_password_reset.yml +++ b/detections/cloud/azure_ad_user_enabled_and_password_reset.yml @@ -1,30 +1,33 @@ name: Azure AD User Enabled And Password Reset id: 1347b9e8-2daa-4a6f-be73-b421d3d9e268 -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-26' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic identifies an Azure AD user enabling a previously - disabled account and resetting its password within 2 minutes. This behavior could - represent an adversary who has obtained administrative access and is trying to establish - a backdoor identity within an Azure AD tenant. -data_source: +description: The following analytic detects an Azure AD user enabling a previously + disabled account and resetting its password within 2 minutes. It uses Azure Active + Directory events to identify this sequence of actions. This activity is significant + because it may indicate an adversary with administrative access attempting to establish + a backdoor identity within the Azure AD tenant. If confirmed malicious, this could + allow the attacker to maintain persistent access, escalate privileges, and potentially + exfiltrate sensitive information from the environment. +data_source: - Azure Active Directory Enable account - Azure Active Directory Reset password (by admin) - Azure Active Directory Update user -search: ' `azure_monitor_aad` (operationName="Enable account" OR operationName="Reset password (by admin)" OR operationName="Update user") - | transaction user startsWith=(operationName="Enable account") endsWith=(operationName="Reset password (by admin)") maxspan=2m - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | stats count min(_time) as firstTime max(_time) as lastTime values(operationName) as operationName values(initiatedBy) as initiatedBy by user, result - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_ad_user_enabled_and_password_reset_filter`' +search: ' `azure_monitor_aad` (operationName="Enable account" OR operationName="Reset + password (by admin)" OR operationName="Update user") | transaction user startsWith=(operationName="Enable + account") endsWith=(operationName="Reset password (by admin)") maxspan=2m | rename + properties.* as * | rename initiatedBy.user.userPrincipalName as initiatedBy | stats + count min(_time) as firstTime max(_time) as lastTime values(operationName) as operationName + values(initiatedBy) as initiatedBy by user, result | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_user_enabled_and_password_reset_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. known_false_positives: While not common, Administrators may enable accounts and reset their passwords for legitimate reasons. Filter as needed. references: @@ -35,8 +38,8 @@ tags: asset_type: Azure Active Directory confidence: 90 impact: 50 - message: A user account, $user$, was enabled and its password reset within - 2 minutes by $initiatedBy$ + message: A user account, $user$, was enabled and its password reset within 2 minutes + by $initiatedBy$ mitre_attack_id: - T1098 observable: @@ -63,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_enable_and_reset/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_enable_and_reset/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_ad_user_immutableid_attribute_updated.yml b/detections/cloud/azure_ad_user_immutableid_attribute_updated.yml index 8360d6ebf9..4d389d1b08 100644 --- a/detections/cloud/azure_ad_user_immutableid_attribute_updated.yml +++ b/detections/cloud/azure_ad_user_immutableid_attribute_updated.yml @@ -1,38 +1,32 @@ name: Azure AD User ImmutableId Attribute Updated id: 0c0badad-4536-4a84-a561-5ff760f3c00e -version: 1 -date: '2022-09-02' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP description: The following analytic identifies the modification of the SourceAnchor - (also called ImmutableId) attribute for an Azure Active Directory user. Updating - this attribute is a step required to set up the Azure Active Directory identity - federation backdoor technique discovered by security researcher Nestori Syynimaa. - Similar to Active Directory, Azure AD uses the concept of domains to manage directories - of identities. A new Azure AD tenant will initially contain a single domain that - is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also - add their registered custom domains to Azure AD for email addresses to match the - organizations domain name. If the organization intends to use a third-party identity - provider such as ADFS for authentication, the added custom domains can be configured - as federated. An adversary who has obtained privileged access to an Azure AD tenant - may leverage this technique to establish persistence and be able to authenticate - to Azure AD impersonating any user and bypassing the requirement to have a valid - password and/or perform MFA. -data_source: + (ImmutableId) attribute for an Azure Active Directory user. This detection leverages + Azure AD audit logs, specifically monitoring the "Update user" operation and changes + to the SourceAnchor attribute. This activity is significant as it is a step in setting + up an Azure AD identity federation backdoor, allowing an adversary to establish + persistence. If confirmed malicious, the attacker could impersonate any user, bypassing + password and MFA requirements, leading to unauthorized access and potential data + breaches. +data_source: - Azure Active Directory Update user search: ' `azure_monitor_aad` operationName="Update user" properties.targetResources{}.modifiedProperties{}.displayName=SourceAnchor - | rename properties.* as * - | rename initiatedBy.user.userPrincipalName as initiatedBy - | rename targetResources{}.modifiedProperties{}.newValue as modifiedProperties - | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(modifiedProperties) as modifiedProperties by initiatedBy, src_ip, result, operationName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | rename properties.* as * | rename initiatedBy.user.userPrincipalName as initiatedBy + | rename targetResources{}.modifiedProperties{}.newValue as modifiedProperties | + stats count min(_time) as firstTime max(_time) as lastTime values(user) as user + values(modifiedProperties) as modifiedProperties by initiatedBy, src_ip, result, + operationName | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_user_immutableid_attribute_updated_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. - This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. + This analytic was written to be used with the azure:monitor:aad sourcetype leveraging + the AuditLog log category. known_false_positives: The SourceAnchor (also called ImmutableId) Azure AD attribute has legitimate uses for directory synchronization. Investigate and filter as needed. references: @@ -72,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_set_immutableid/azure-audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_set_immutableid/azure-audit.log source: Azure AD sourcetype: azure:monitor:aad update_timestamp: true diff --git a/detections/cloud/azure_automation_account_created.yml b/detections/cloud/azure_automation_account_created.yml index 432c15f41c..af5fb1430f 100644 --- a/detections/cloud/azure_automation_account_created.yml +++ b/detections/cloud/azure_automation_account_created.yml @@ -1,32 +1,25 @@ name: Azure Automation Account Created id: 860902fd-2e76-46b3-b050-ba548dab576c -version: 2 -date: '2023-12-20' +version: 3 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the creation of a new Azure Automation - account within an Azure tenant. Azure Automation is a cloud-based automation platform - that allows administrators to automate Azure management tasks and orchestrate actions - across external systems within Azure using PowerShell and Python. Azure Automation - can also be configured to automate tasks on on premise infrastructure using a component - called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate - Automation resources, runbooks, assets, and configurations from the resources of - other accounts. They allow administrators to separate resources into logical environments - or delegated responsibilities. Adversaries or red teams who have obtained privileged - access to an Azure tenant may create an Azure Automation account with elevated privileges - to maintain persistence in the Azure tenant. A malicious Automation Runbook can - be created to create Global Administrators in Azure AD, execute code on VMs, etc. -data_source: +description: The following analytic detects the creation of a new Azure Automation + account within an Azure tenant. It leverages Azure Audit events, specifically the + Azure Activity log category, to identify when an account is created or updated. + This activity is significant because Azure Automation accounts can be used to automate + tasks and orchestrate actions across Azure and on-premise environments. If an attacker + creates an Automation account with elevated privileges, they could maintain persistence, + execute malicious runbooks, and potentially escalate privileges or execute code + on virtual machines, posing a significant security risk. +data_source: - Azure Audit Create or Update an Azure Automation account -search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation account" status.value=Succeeded - | dedup object - | rename claims.ipaddr as src_ip - | rename caller as user - | stats count min(_time) as firstTime max(_time) as lastTime values(object) as object by user, src_ip, resourceGroupName, object_path - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_automation_account_created_filter`' +search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation + account" status.value=Succeeded | dedup object | rename claims.ipaddr as src_ip + | rename caller as user | stats count min(_time) as firstTime max(_time) as lastTime + values(object) as object by user, src_ip, resourceGroupName, object_path | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_automation_account_created_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, @@ -74,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_automation_account/azure-activity.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_automation_account/azure-activity.log source: mscs:azure:audit sourcetype: mscs:azure:audit update_timestamp: true diff --git a/detections/cloud/azure_automation_runbook_created.yml b/detections/cloud/azure_automation_runbook_created.yml index 6a6c3e6666..3c1cfeb265 100644 --- a/detections/cloud/azure_automation_runbook_created.yml +++ b/detections/cloud/azure_automation_runbook_created.yml @@ -1,29 +1,25 @@ name: Azure Automation Runbook Created id: 178d696d-6dc6-4ee8-9d25-93fee34eaf5b -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-11' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the creation of a new Azure Automation - Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform - that allows administrators to automate Azure management tasks and orchestrate actions - across external systems within Azure. Azure Automation script files called Runbooks - that can be written in PowerShell or Python. Adversaries or red teams who have obtained - privileged access to an Azure tenant may create an Azure Automation Runbook that - runs with elevated privileges to maintain persistence in the Azure tenant. A malicious - Automation Runbook can be created to create Global Administrators in Azure AD, execute - code on VMs, etc. -data_source: +description: The following analytic detects the creation of a new Azure Automation + Runbook within an Azure tenant. It leverages Azure Audit events, specifically the + Azure Activity log category, to identify when a new Runbook is created or updated. + This activity is significant because adversaries with privileged access can use + Runbooks to maintain persistence, escalate privileges, or execute malicious code. + If confirmed malicious, this could lead to unauthorized actions such as creating + Global Administrators, executing code on VMs, and compromising the entire Azure + environment. +data_source: - Azure Audit Create or Update an Azure Automation Runbook -search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation Runbook" object!=AzureAutomationTutorial* status.value=Succeeded - | dedup object - | rename claims.ipaddr as src_ip - | rename caller as user - | stats count min(_time) as firstTime max(_time) as lastTime by object user, src_ip, resourceGroupName, object_path - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_automation_runbook_created_filter`' +search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation + Runbook" object!=AzureAutomationTutorial* status.value=Succeeded | dedup object + | rename claims.ipaddr as src_ip | rename caller as user | stats count min(_time) + as firstTime max(_time) as lastTime by object user, src_ip, resourceGroupName, object_path + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_automation_runbook_created_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, @@ -71,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_automation_runbook/azure-activity.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_automation_runbook/azure-activity.log source: mscs:azure:audit sourcetype: mscs:azure:audit update_timestamp: true diff --git a/detections/cloud/azure_runbook_webhook_created.yml b/detections/cloud/azure_runbook_webhook_created.yml index 20a73cbeae..28fc9c5694 100644 --- a/detections/cloud/azure_runbook_webhook_created.yml +++ b/detections/cloud/azure_runbook_webhook_created.yml @@ -1,30 +1,25 @@ name: Azure Runbook Webhook Created id: e98944a9-92e4-443c-81b8-a322e33ce75a -version: 3 -date: '2023-12-20' +version: 4 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the creation of a new Automation Runbook - Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform - that allows administrators to automate Azure management tasks and orchestrate actions - across external systems within Azure. Azure Automation script files called Runbooks - that can be written in PowerShell or Python. One of the ways administrators can - configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom - unauthenticated URLs that are exposed to the Internet. An adversary who has obtained - privileged access to an Azure tenant may create a Webhook to trigger the execution - of an Automation Runbook with malicious code that can create users or execute code - on a VM. This provides a persistent foothold on the environment. -data_source: +description: The following analytic detects the creation of a new Automation Runbook + Webhook within an Azure tenant. It leverages Azure Audit events, specifically the + "Create or Update an Azure Automation webhook" operation, to identify this activity. + This behavior is significant because Webhooks can trigger Automation Runbooks via + unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed + malicious, an attacker could use this to execute code, create users, or maintain + persistence within the environment, potentially leading to unauthorized access and + control over Azure resources. +data_source: - Azure Audit Create or Update an Azure Automation webhook -search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation webhook" status.value=Succeeded - | dedup object - | rename claims.ipaddr as src_ip - | rename caller as user - | stats count min(_time) as firstTime max(_time) as lastTime by object user, src_ip, resourceGroupName, object_path - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `azure_runbook_webhook_created_filter`' +search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation + webhook" status.value=Succeeded | dedup object | rename claims.ipaddr as src_ip + | rename caller as user | stats count min(_time) as firstTime max(_time) as lastTime + by object user, src_ip, resourceGroupName, object_path | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_runbook_webhook_created_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, @@ -72,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_runbook_webhook/azure-activity.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azure_runbook_webhook/azure-activity.log source: mscs:azure:audit sourcetype: mscs:azure:audit update_timestamp: true diff --git a/detections/cloud/circle_ci_disable_security_job.yml b/detections/cloud/circle_ci_disable_security_job.yml index 9b36b3f296..455ff6f326 100644 --- a/detections/cloud/circle_ci_disable_security_job.yml +++ b/detections/cloud/circle_ci_disable_security_job.yml @@ -1,13 +1,13 @@ name: Circle CI Disable Security Job id: 4a2fdd41-c578-4cd4-9ef7-980e352517f2 -version: 1 -date: '2021-09-02' +version: 2 +date: '2024-05-20' author: Patrick Bareiss, Splunk status: production type: Anomaly description: |- - This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage. False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection. -data_source: + The following analytic detects the disabling of security jobs in CircleCI pipelines. It leverages CircleCI log data, renaming and extracting fields such as job names, workflow IDs, user information, commit messages, URLs, and branches. The detection identifies mandatory jobs for each workflow and checks if they were executed. This activity is significant because disabling security jobs can allow malicious code to bypass security checks, leading to potential data breaches, system downtime, and reputational damage. If confirmed malicious, this could result in unauthorized code execution and compromised pipeline integrity. +data_source: - CircleCI search: '`circleci` | rename vcs.committer_name as user vcs.subject as commit_message vcs.url as url workflows.* as * | stats values(job_name) as job_names by workflow_id @@ -25,7 +25,8 @@ tags: asset_type: CircleCI confidence: 90 impact: 80 - message: Disable security job $mandatory_job$ in workflow $workflow_name$ from user $user$ + message: Disable security job $mandatory_job$ in workflow $workflow_name$ from user + $user$ mitre_attack_id: - T1554 observable: @@ -44,6 +45,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1554/circle_ci_disable_security_job/circle_ci_disable_security_job.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1554/circle_ci_disable_security_job/circle_ci_disable_security_job.json sourcetype: circleci source: circleci diff --git a/detections/cloud/circle_ci_disable_security_step.yml b/detections/cloud/circle_ci_disable_security_step.yml index 672ab05dac..4c7c333edd 100644 --- a/detections/cloud/circle_ci_disable_security_step.yml +++ b/detections/cloud/circle_ci_disable_security_step.yml @@ -1,13 +1,13 @@ name: Circle CI Disable Security Step id: 72cb9de9-e98b-4ac9-80b2-5331bba6ea97 -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: experimental type: Anomaly description: |- - The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs. The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change. -data_source: + The following analytic detects the disablement of security steps in a CircleCI pipeline. It leverages CircleCI logs, using field renaming, joining, and statistical analysis to identify instances where mandatory security steps are not executed. This activity is significant because disabling security steps can introduce vulnerabilities, unauthorized changes, or malicious code into the pipeline. If confirmed malicious, this could lead to potential attacks, data breaches, or compromised infrastructure. Investigate by reviewing job names, commit details, and user information associated with the disablement, and examine any relevant artifacts and concurrent processes. +data_source: - CircleCI search: '`circleci` | rename workflows.job_id AS job_id | join job_id [ | search `circleci` | stats values(name) as step_names count by job_id job_name ] | stats count by step_names @@ -45,6 +45,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1554/circle_ci_disable_security_step/circle_ci_disable_security_step.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1554/circle_ci_disable_security_step/circle_ci_disable_security_step.json sourcetype: circleci source: circleci diff --git a/detections/cloud/cloud_api_calls_from_previously_unseen_user_roles.yml b/detections/cloud/cloud_api_calls_from_previously_unseen_user_roles.yml index 00f674b7f7..ca2e5983db 100644 --- a/detections/cloud/cloud_api_calls_from_previously_unseen_user_roles.yml +++ b/detections/cloud/cloud_api_calls_from_previously_unseen_user_roles.yml @@ -1,12 +1,12 @@ name: Cloud API Calls From Previously Unseen User Roles id: 2181ad1f-1e73-4d0c-9780-e8880482a08f -version: 1 -date: '2020-09-04' +version: 2 +date: '2024-05-15' author: David Dorsey, Splunk status: experimental type: Anomaly description: |- - The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes. + The following analytic detects cloud API calls executed by user roles that have not previously run these commands. It leverages the Change data model in Splunk to identify commands executed by users with the user_type of AssumedRole and a status of success. This activity is significant because new commands from different user roles can indicate potential malicious activity or unauthorized actions. If confirmed malicious, this behavior could lead to unauthorized access, data breaches, or other damaging outcomes by exploiting new or unmonitored commands within the cloud environment. data_source: [] search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where All_Changes.user_type=AssumedRole AND All_Changes.status=success by All_Changes.user, @@ -58,7 +58,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/cloud_compute_instance_created_with_previously_unseen_image.yml b/detections/cloud/cloud_compute_instance_created_with_previously_unseen_image.yml index a3fdda8ed8..7114193294 100644 --- a/detections/cloud/cloud_compute_instance_created_with_previously_unseen_image.yml +++ b/detections/cloud/cloud_compute_instance_created_with_previously_unseen_image.yml @@ -1,12 +1,12 @@ name: Cloud Compute Instance Created With Previously Unseen Image id: bc24922d-987c-4645-b288-f8c73ec194c4 -version: 1 -date: '2018-10-12' +version: 2 +date: '2024-05-30' author: David Dorsey, Splunk status: experimental type: Anomaly description: |- - The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack. + The following analytic detects the creation of cloud compute instances using previously unseen image IDs. It leverages cloud infrastructure logs to identify new image IDs that have not been observed before. This activity is significant because it may indicate unauthorized or suspicious activity, such as the deployment of malicious payloads or unauthorized access to sensitive information. If confirmed malicious, this could lead to data breaches, unauthorized access, or further compromise of the cloud environment. Immediate investigation is required to determine the legitimacy of the instance creation and to mitigate potential threats. data_source: [] search: '| tstats count earliest(_time) as firstTime, latest(_time) as lastTime values(All_Changes.object_id) as dest from datamodel=Change where All_Changes.action=created by All_Changes.Instance_Changes.image_id, @@ -59,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/cloud_compute_instance_created_with_previously_unseen_instance_type.yml b/detections/cloud/cloud_compute_instance_created_with_previously_unseen_instance_type.yml index a5c9bd52f7..51ba95c9c5 100644 --- a/detections/cloud/cloud_compute_instance_created_with_previously_unseen_instance_type.yml +++ b/detections/cloud/cloud_compute_instance_created_with_previously_unseen_instance_type.yml @@ -1,11 +1,18 @@ name: Cloud Compute Instance Created With Previously Unseen Instance Type id: c6ddbf53-9715-49f3-bb4c-fb2e8a309cda -version: 1 -date: '2020-09-12' +version: 2 +date: '2024-05-14' author: David Dorsey, Splunk status: experimental type: Anomaly -description: The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts. +description: The following analytic detects the creation of EC2 instances with previously + unseen instance types. It leverages Splunk's tstats command to analyze data from + the Change data model, identifying instance types that have not been previously + recorded. This activity is significant for a SOC because it may indicate unauthorized + or suspicious activity, such as an attacker attempting to create instances for malicious + purposes. If confirmed malicious, this could lead to unauthorized access, data exfiltration, + system compromise, or service disruption. Immediate investigation is required to + determine the legitimacy of the instance creation. data_source: [] search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime values(All_Changes.object_id) as dest, count from datamodel=Change where All_Changes.action=created by All_Changes.Instance_Changes.instance_type, @@ -59,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_city.yml b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_city.yml index d993474fef..b9d62ef08b 100644 --- a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_city.yml +++ b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_city.yml @@ -21,9 +21,10 @@ search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime from d lookup previously_seen_cloud_provisioning_activity_sources City as City OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCity=min(firstTimeSeen) | where isnull(firstTimeSeenCity) OR firstTimeSeenCity - > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | - table firstTime, src, City, user, object, command | `cloud_provisioning_activity_from_previously_unseen_city_filter` - | `security_content_ctime(firstTime)`' + > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) + | `security_content_ctime(firstTime)` + | table firstTime, src, City, user, object, command + | `cloud_provisioning_activity_from_previously_unseen_city_filter`' how_to_implement: You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic diff --git a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_country.yml b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_country.yml index 9fc5036c7f..15ebf020a3 100644 --- a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_country.yml +++ b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_country.yml @@ -21,9 +21,10 @@ search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime from d | lookup previously_seen_cloud_provisioning_activity_sources Country as Country OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCountry=min(firstTimeSeen) | where isnull(firstTimeSeenCountry) - OR firstTimeSeenCountry > relative_time(now(), "-24h@h") | table firstTime, src, - Country, user, object, command | `cloud_provisioning_activity_from_previously_unseen_country_filter` - | `security_content_ctime(firstTime)`' + OR firstTimeSeenCountry > relative_time(now(), "-24h@h") + | `security_content_ctime(firstTime)` + | table firstTime, src, Country, user, object, command + | `cloud_provisioning_activity_from_previously_unseen_country_filter`' how_to_implement: You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic diff --git a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_ip_address.yml b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_ip_address.yml index 8cca4a3983..7698432f62 100644 --- a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_ip_address.yml +++ b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_ip_address.yml @@ -21,8 +21,9 @@ search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime, value src as src OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenSrc=min(firstTimeSeen) | where isnull(firstTimeSeenSrc) OR firstTimeSeenSrc > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) - | table firstTime, src, user, object_id, command | `cloud_provisioning_activity_from_previously_unseen_ip_address_filter` - | `security_content_ctime(firstTime)`' + | `security_content_ctime(firstTime)` + | table firstTime, src, user, object_id, command + | `cloud_provisioning_activity_from_previously_unseen_ip_address_filter`' how_to_implement: You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic diff --git a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_region.yml b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_region.yml index 4f9f552f0e..779605e1eb 100644 --- a/detections/cloud/cloud_provisioning_activity_from_previously_unseen_region.yml +++ b/detections/cloud/cloud_provisioning_activity_from_previously_unseen_region.yml @@ -22,8 +22,9 @@ search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime from d firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenRegion=min(firstTimeSeen) | where isnull(firstTimeSeenRegion) OR firstTimeSeenRegion > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) - | table firstTime, src, Region, user, object, command | `cloud_provisioning_activity_from_previously_unseen_region_filter` - | `security_content_ctime(firstTime)`' + | `security_content_ctime(firstTime)` + | table firstTime, src, Region, user, object, command + | `cloud_provisioning_activity_from_previously_unseen_region_filter`' how_to_implement: You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic diff --git a/detections/cloud/cloud_security_groups_modifications_by_user.yml b/detections/cloud/cloud_security_groups_modifications_by_user.yml index c2e5fd3a65..1ce26bf6ec 100644 --- a/detections/cloud/cloud_security_groups_modifications_by_user.yml +++ b/detections/cloud/cloud_security_groups_modifications_by_user.yml @@ -1,34 +1,35 @@ name: Cloud Security Groups Modifications by User id: cfe7cca7-2746-4bdf-b712-b01ed819b9de -version: 1 -date: '2024-02-21' -author: Bhavin Patel, Splunk -data_source: +version: 2 +date: '2024-05-18' +author: Bhavin Patel, Splunk +data_source: - AWS CloudTrail type: Anomaly status: production -description: The following analytic identifies users who are unsually modifying security group in your cloud enriovnment,focusing on actions such as modifications, deletions, or creations performed by users over 30-minute intervals. Analyzing patterns of modifications to security groups can help in identifying anomalous behavior that may indicate a compromised account or an insider threat. - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on all user and service accounts that have created/modified/deleted a security group . - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and values of the security objects affected. -search: '| tstats dc(All_Changes.object) as unique_security_groups values(All_Changes.src) as src values(All_Changes.user_type) as user_type values(All_Changes.object_category) as object_category values(All_Changes.object) as objects - values(All_Changes.action) as action values(All_Changes.user_agent) as user_agent values(All_Changes.command) as command from datamodel=Change WHERE All_Changes.object_category = "security_group" (All_Changes.action = modified OR All_Changes.action = deleted OR All_Changes.action = created) by All_Changes.user _time span=30m - | `drop_dm_object_name("All_Changes")` - | eventstats avg(unique_security_groups) as avg_changes - , stdev(unique_security_groups) as std_changes by user - | eval upperBound=(avg_changes+std_changes*3) - | eval isOutlier=if(unique_security_groups > 2 and unique_security_groups >= upperBound, 1, 0) - | where isOutlier=1| `cloud_security_groups_modifications_by_user_filter`' -how_to_implement: This search requries the Cloud infrastructure logs such as AWS Cloudtrail, GCP Pubsub Message logs, Azure Audit logs to be ingested into an accelerated Change datamodel. It is also recommended that users can try different combinations of the `bucket` span time and outlier conditions to better suit with their environment. -known_false_positives: It is possible that legitimate user/admin may modify a number of security groups +description: The following analytic identifies unusual modifications to security groups + in your cloud environment by users, focusing on actions such as modifications, deletions, + or creations over 30-minute intervals. It leverages cloud infrastructure logs and + calculates the standard deviation for each user, using the 3-sigma rule to detect + anomalies. This activity is significant as it may indicate a compromised account + or insider threat. If confirmed malicious, attackers could alter security group + configurations, potentially exposing sensitive resources or disrupting services. +search: '| tstats dc(All_Changes.object) as unique_security_groups values(All_Changes.src) + as src values(All_Changes.user_type) as user_type values(All_Changes.object_category) + as object_category values(All_Changes.object) as objects values(All_Changes.action) + as action values(All_Changes.user_agent) as user_agent values(All_Changes.command) + as command from datamodel=Change WHERE All_Changes.object_category = "security_group" + (All_Changes.action = modified OR All_Changes.action = deleted OR All_Changes.action + = created) by All_Changes.user _time span=30m | `drop_dm_object_name("All_Changes")` + | eventstats avg(unique_security_groups) as avg_changes , stdev(unique_security_groups) + as std_changes by user | eval upperBound=(avg_changes+std_changes*3) | eval isOutlier=if(unique_security_groups + > 2 and unique_security_groups >= upperBound, 1, 0) | where isOutlier=1| `cloud_security_groups_modifications_by_user_filter`' +how_to_implement: This search requries the Cloud infrastructure logs such as AWS Cloudtrail, + GCP Pubsub Message logs, Azure Audit logs to be ingested into an accelerated Change + datamodel. It is also recommended that users can try different combinations of the + `bucket` span time and outlier conditions to better suit with their environment. +known_false_positives: It is possible that legitimate user/admin may modify a number + of security groups references: - https://attack.mitre.org/techniques/T1578/005/ tags: @@ -37,7 +38,7 @@ tags: asset_type: Cloud Instance confidence: 50 impact: 70 - message: Unsual number cloud security group modifications detected by user - $user$ + message: Unsual number cloud security group modifications detected by user - $user$ mitre_attack_id: - T1578.005 observable: @@ -61,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1578.005/aws_authorize_security_group/aws_authorize_security_group.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1578.005/aws_authorize_security_group/aws_authorize_security_group.json sourcetype: aws:cloudtrail source: aws_cloudtrail diff --git a/detections/cloud/detect_aws_console_login_by_new_user.yml b/detections/cloud/detect_aws_console_login_by_new_user.yml index 2541da0e47..a5f08b2e0c 100644 --- a/detections/cloud/detect_aws_console_login_by_new_user.yml +++ b/detections/cloud/detect_aws_console_login_by_new_user.yml @@ -1,15 +1,17 @@ name: Detect AWS Console Login by New User id: bc91a8cd-35e7-4bb2-6140-e756cc46fd71 -version: 3 -date: '2022-05-10' +version: 4 +date: '2024-05-28' author: Rico Valdez, Splunk status: experimental type: Hunting -description: This search looks for AWS CloudTrail events wherein a console login event - by a user was recorded within the last hour, then compares the event to a lookup - file of previously seen users (by ARN values) who have logged into the console. - The alert is fired if the user has logged into the console for the first time within - the last hour +description: The following analytic detects AWS console login events by new users. + It leverages AWS CloudTrail events and compares them against a lookup file of previously + seen users based on ARN values. This detection is significant because a new user + logging into the AWS console could indicate the creation of new accounts or potential + unauthorized access. If confirmed malicious, this activity could lead to unauthorized + access to AWS resources, data exfiltration, or further exploitation within the cloud + environment. data_source: [] search: '| tstats earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Authentication where Authentication.signature=ConsoleLogin by Authentication.user | `drop_dm_object_name(Authentication)` @@ -59,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/detect_aws_console_login_by_user_from_new_city.yml b/detections/cloud/detect_aws_console_login_by_user_from_new_city.yml index 2428ed1042..9488c17d39 100644 --- a/detections/cloud/detect_aws_console_login_by_user_from_new_city.yml +++ b/detections/cloud/detect_aws_console_login_by_user_from_new_city.yml @@ -1,16 +1,18 @@ name: Detect AWS Console Login by User from New City id: 121b0b11-f8ac-4ed6-a132-3800ca4fc07a -version: 2 -date: '2022-08-25' +version: 3 +date: '2024-05-25' author: Bhavin Patel, Eric McGinnis Splunk status: production type: Hunting -description: This search looks for AWS CloudTrail events wherein a console login event - by a user was recorded within the last hour, then compares the event to a lookup - file of previously seen users (by ARN values) who have logged into the console. - The alert is fired if the user has logged into the console for the first time within - the last hour -data_source: +description: The following analytic identifies AWS console login events by users from + a new city within the last hour. It leverages AWS CloudTrail events and compares + them against a lookup file of previously seen user locations. This activity is significant + for a SOC as it may indicate unauthorized access or credential compromise, especially + if the login originates from an unusual location. If confirmed malicious, this could + lead to unauthorized access to AWS resources, data exfiltration, or further exploitation + within the cloud environment. +data_source: - AWS CloudTrail search: '| tstats earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Authentication where Authentication.signature=ConsoleLogin by Authentication.user Authentication.src @@ -66,12 +68,13 @@ tags: - Authentication.src risk_score: 18 security_domain: threat - manual_test: This search needs the baseline to be run first to create a lookup. + manual_test: This search needs the baseline to be run first to create a lookup. It also requires that the timestamps in the dataset be updated. tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/detect_aws_console_login_by_user_from_new_country.yml b/detections/cloud/detect_aws_console_login_by_user_from_new_country.yml index 49f63ccf37..7cd18c04e7 100644 --- a/detections/cloud/detect_aws_console_login_by_user_from_new_country.yml +++ b/detections/cloud/detect_aws_console_login_by_user_from_new_country.yml @@ -1,16 +1,17 @@ name: Detect AWS Console Login by User from New Country id: 67bd3def-c41c-4bf6-837b-ae196b4257c6 -version: 2 -date: '2022-08-25' +version: 3 +date: '2024-05-16' author: Bhavin Patel, Eric McGinnis Splunk status: production type: Hunting -description: This search looks for AWS CloudTrail events wherein a console login event - by a user was recorded within the last hour, then compares the event to a lookup - file of previously seen users (by ARN values) who have logged into the console. - The alert is fired if the user has logged into the console for the first time within - the last hour -data_source: +description: The following analytic identifies AWS console login events by users from + a new country. It leverages AWS CloudTrail events and compares them against a lookup + file of previously seen users and their login locations. This activity is significant + because logins from new countries can indicate potential unauthorized access or + compromised accounts. If confirmed malicious, this could lead to unauthorized access + to AWS resources, data exfiltration, or further exploitation within the AWS environment. +data_source: - AWS CloudTrail search: '| tstats earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Authentication where Authentication.signature=ConsoleLogin by Authentication.user Authentication.src @@ -67,12 +68,13 @@ tags: - Authentication.src risk_score: 42 security_domain: threat - manual_test: This search needs the baseline to be run first to create a lookup. + manual_test: This search needs the baseline to be run first to create a lookup. It also requires that the timestamps in the dataset be updated. tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/detect_aws_console_login_by_user_from_new_region.yml b/detections/cloud/detect_aws_console_login_by_user_from_new_region.yml index 471db53e87..69cda1c583 100644 --- a/detections/cloud/detect_aws_console_login_by_user_from_new_region.yml +++ b/detections/cloud/detect_aws_console_login_by_user_from_new_region.yml @@ -1,16 +1,18 @@ name: Detect AWS Console Login by User from New Region id: 9f31aa8e-e37c-46bc-bce1-8b3be646d026 -version: 2 -date: '2022-08-25' +version: 3 +date: '2024-05-18' author: Bhavin Patel, Eric McGinnis Splunk status: production type: Hunting -description: This search looks for AWS CloudTrail events wherein a console login event - by a user was recorded within the last hour, then compares the event to a lookup - file of previously seen users (by ARN values) who have logged into the console. - The alert is fired if the user has logged into the console for the first time within - the last hour -data_source: +description: The following analytic identifies AWS console login attempts by users + from a new region. It leverages AWS CloudTrail events and compares current login + regions against a baseline of previously seen regions for each user. This activity + is significant as it may indicate unauthorized access attempts or compromised credentials. + If confirmed malicious, an attacker could gain unauthorized access to AWS resources, + potentially leading to data breaches, resource manipulation, or further lateral + movement within the cloud environment. +data_source: - AWS CloudTrail search: '| tstats earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Authentication where Authentication.signature=ConsoleLogin by Authentication.user Authentication.src @@ -67,12 +69,13 @@ tags: - Authentication.src risk_score: 36 security_domain: threat - manual_test: This search needs the baseline to be run first to create a lookup. + manual_test: This search needs the baseline to be run first to create a lookup. It also requires that the timestamps in the dataset be updated. tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/abnormally_high_cloud_instances_launched/cloudtrail_behavioural_detections.json sourcetype: aws:cloudtrail source: aws_cloudtrail update_timestamp: true diff --git a/detections/cloud/detect_new_open_s3_buckets.yml b/detections/cloud/detect_new_open_s3_buckets.yml index d6d8f01373..64a68a65f9 100644 --- a/detections/cloud/detect_new_open_s3_buckets.yml +++ b/detections/cloud/detect_new_open_s3_buckets.yml @@ -21,7 +21,7 @@ search: '`cloudtrail` eventSource=s3.amazonaws.com eventName=PutBucketAcl | rex rename requestParameters.bucketName AS bucketName | stats count min(_time) as firstTime max(_time) as lastTime by user_arn userIdentity.principalId userAgent uri permission bucketName | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `detect_new_open_s3_buckets_filter` ' + | `detect_new_open_s3_buckets_filter`' how_to_implement: You must install the AWS App for Splunk. known_false_positives: While this search has no known false positives, it is possible that an AWS admin has legitimately created a public bucket for a specific purpose. diff --git a/detections/cloud/detect_new_open_s3_buckets_over_aws_cli.yml b/detections/cloud/detect_new_open_s3_buckets_over_aws_cli.yml index 4cfc41d780..c81623d904 100644 --- a/detections/cloud/detect_new_open_s3_buckets_over_aws_cli.yml +++ b/detections/cloud/detect_new_open_s3_buckets_over_aws_cli.yml @@ -23,7 +23,7 @@ search: '`cloudtrail` eventSource="s3.amazonaws.com" (userAgent="[aws-cli*" OR u by userIdentity.userName userIdentity.principalId userAgent bucketName requestParameters.accessControlList.x-amz-grant-read requestParameters.accessControlList.x-amz-grant-read-acp requestParameters.accessControlList.x-amz-grant-write requestParameters.accessControlList.x-amz-grant-write-acp requestParameters.accessControlList.x-amz-grant-full-control - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_over_aws_cli_filter` ' + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_over_aws_cli_filter`' how_to_implement: The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs. known_false_positives: While this search has no known false positives, it is possible diff --git a/detections/cloud/gcp_authentication_failed_during_mfa_challenge.yml b/detections/cloud/gcp_authentication_failed_during_mfa_challenge.yml index 71890a9d28..2b04cfc1b8 100644 --- a/detections/cloud/gcp_authentication_failed_during_mfa_challenge.yml +++ b/detections/cloud/gcp_authentication_failed_during_mfa_challenge.yml @@ -1,18 +1,23 @@ name: GCP Authentication Failed During MFA Challenge id: 345f7e1d-a3fe-4158-abd8-e630f9878323 -version: 2 -date: '2024-01-04' +version: 3 +date: '2024-05-11' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: TTP -description: 'The following analytic identifies an authentication attempt event against - a Google Cloud Platform tenant that fails during the Multi Factor Authentication - challenge. This behavior may represent an adversary trying to authenticate with - compromised credentials for an account that has multi-factor authentication enabled. ' -data_source: +description: 'The following analytic detects failed authentication attempts during + the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) + tenant. It uses Google Workspace login failure events to identify instances where + MFA methods were challenged but not successfully completed. This activity is significant + as it may indicate an adversary attempting to access an account with compromised + credentials despite MFA protection. If confirmed malicious, this could lead to unauthorized + access attempts, potentially compromising sensitive data and resources within the + GCP environment.' +data_source: - Google Workspace login_failure search: ' `gws_reports_login` event.name=login_failure `gws_login_mfa_methods` | stats - count min(_time) as firstTime max(_time) as lastTime by user, src_ip, login_challenge_method | `gcp_authentication_failed_during_mfa_challenge_filter`' + count min(_time) as firstTime max(_time) as lastTime by user, src_ip, login_challenge_method + | `gcp_authentication_failed_during_mfa_challenge_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google @@ -59,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/gcp_failed_mfa/gws_login.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/gcp_failed_mfa/gws_login.log source: gws:reports:login sourcetype: gws:reports:login update_timestamp: true diff --git a/detections/cloud/gcp_multi_factor_authentication_disabled.yml b/detections/cloud/gcp_multi_factor_authentication_disabled.yml index 69f6cc1bcb..8acdae5d35 100644 --- a/detections/cloud/gcp_multi_factor_authentication_disabled.yml +++ b/detections/cloud/gcp_multi_factor_authentication_disabled.yml @@ -1,18 +1,24 @@ name: GCP Multi-Factor Authentication Disabled id: b9bc5513-6fc1-4821-85a3-e1d81e451c83 -version: 2 -date: '2024-01-04' +version: 3 +date: '2024-05-25' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies an attempt to disable multi-factor - authentication for a GCP user. An adversary who has obtained access to an GCP tenant - may disable multi-factor authentication as a way to plant a backdoor and maintain - persistence using a valid account. This way the attackers can keep persistance in - the environment without adding new users. -data_source: +description: The following analytic detects an attempt to disable multi-factor authentication + (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin + log events, specifically the `UNENROLL_USER_FROM_STRONG_AUTH` command. This activity + is significant because disabling MFA can allow an adversary to maintain persistence + within the environment using a compromised account without raising suspicion. If + confirmed malicious, this action could enable attackers to bypass additional security + layers, potentially leading to unauthorized access, data exfiltration, or further + exploitation of the compromised account. +data_source: - Google Workspace -search: '`gws_reports_admin` command=UNENROLL_USER_FROM_STRONG_AUTH | stats count min(_time) as firstTime max(_time) as lastTime by user, command, actor.email, status, id.applicationName, event.name, vendor_account, action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `gcp_multi_factor_authentication_disabled_filter`' +search: '`gws_reports_admin` command=UNENROLL_USER_FROM_STRONG_AUTH | stats count + min(_time) as firstTime max(_time) as lastTime by user, command, actor.email, status, + id.applicationName, event.name, vendor_account, action | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)`| `gcp_multi_factor_authentication_disabled_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google @@ -59,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/gcp_disable_mfa/gws_admin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/gcp_disable_mfa/gws_admin.log source: gws:reports:admin sourcetype: gws:reports:admin update_timestamp: true diff --git a/detections/cloud/gcp_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/gcp_multiple_failed_mfa_requests_for_user.yml index b12e297409..501ca6414b 100644 --- a/detections/cloud/gcp_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/gcp_multiple_failed_mfa_requests_for_user.yml @@ -1,24 +1,23 @@ name: GCP Multiple Failed MFA Requests For User id: cbb3cb84-c06f-4393-adcc-5cb6195621f1 -version: 1 -date: '2022-10-14' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies multiple failed multi-factor authentication - requests for a single user within a Google Cloud Platform tenant. Specifically, - the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google - CLoud tenants can be very different depending on the organization, Security teams - should test this detection and customize these arbitrary thresholds. The detected - behavior may represent an adversary who has obtained legitimate credentials for - a user and continuously repeats login attempts in order to bombard users with MFA - push notifications, SMS messages, and phone calls potentially resulting in the user - finally accepting the authentication request. Threat actors like the Lapsus team - and APT29 have leveraged this technique to bypass multi-factor authentication controls - as reported by Mandiant and others. -data_source: +description: The following analytic detects multiple failed multi-factor authentication + (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. It + triggers when 10 or more MFA prompts fail within a 5-minute window, using Google + Workspace login failure events. This behavior is significant as it may indicate + an adversary attempting to bypass MFA by bombarding the user with repeated authentication + requests. If confirmed malicious, this activity could lead to unauthorized access, + allowing attackers to compromise accounts and potentially escalate privileges within + the GCP environment. +data_source: - Google Workspace login_failure -search: "`gws_reports_login` event.name=login_failure `gws_login_mfa_methods` | bucket span=5m _time | stats dc(_raw) AS mfa_prompts values(user) AS user by src_ip, login_challenge_method, _time | where mfa_prompts >= 10 | `gcp_multiple_failed_mfa_requests_for_user_filter`" +search: "`gws_reports_login` event.name=login_failure `gws_login_mfa_methods` | bucket + span=5m _time | stats dc(_raw) AS mfa_prompts values(user) AS user by src_ip, login_challenge_method,\ + \ _time | where mfa_prompts >= 10 | `gcp_multiple_failed_mfa_requests_for_user_filter`" how_to_implement: You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google @@ -66,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/multiple_failed_mfa_gws/gws_login.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/multiple_failed_mfa_gws/gws_login.log source: gws:reports:login sourcetype: gws:reports:login update_timestamp: true diff --git a/detections/cloud/gcp_multiple_users_failing_to_authenticate_from_ip.yml b/detections/cloud/gcp_multiple_users_failing_to_authenticate_from_ip.yml index f1a9dd7197..f4f9aceee7 100644 --- a/detections/cloud/gcp_multiple_users_failing_to_authenticate_from_ip.yml +++ b/detections/cloud/gcp_multiple_users_failing_to_authenticate_from_ip.yml @@ -1,17 +1,18 @@ name: GCP Multiple Users Failing To Authenticate From Ip id: da20828e-d6fb-4ee5-afb7-d0ac200923d5 -version: 1 -date: '2022-10-12' +version: 2 +date: '2024-05-22' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies one source Ip failing to authenticate - into the Google Workspace user accounts with more than 20 unique valid users within - 5 minutes. These user accounts may have other privileges with respect to access - to other sensitive resources in the Google Cloud Platform. This behavior could represent - an adversary performing a Password Spraying attack against an Google Workspace environment - to obtain initial access or elevate privileges. -data_source: +description: The following analytic detects a single source IP address failing to + authenticate into more than 20 unique Google Workspace user accounts within a 5-minute + window. It leverages Google Workspace login failure events to identify potential + password spraying attacks. This activity is significant as it may indicate an adversary + attempting to gain unauthorized access or elevate privileges within the Google Cloud + Platform. If confirmed malicious, this behavior could lead to unauthorized access + to sensitive resources, data breaches, or further exploitation within the environment. +data_source: - Google Workspace login_failure search: '`gws_reports_login` event.type = login event.name = login_failure | bucket span=5m _time | stats count dc(user) AS unique_accounts values(user) as tried_accounts @@ -37,7 +38,8 @@ tags: asset_type: Google Cloud Platform tenant confidence: 90 impact: 60 - message: 'Multiple failed login attempts (Count: $unique_accounts$) against users seen from $src$' + message: 'Multiple failed login attempts (Count: $unique_accounts$) against users + seen from $src$' mitre_attack_id: - T1586 - T1586.003 @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/gcp_gws_multiple_login_failure/gws_login.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/gcp_gws_multiple_login_failure/gws_login.json source: gws_login sourcetype: gws:reports:login update_timestamp: true diff --git a/detections/cloud/gcp_successful_single_factor_authentication.yml b/detections/cloud/gcp_successful_single_factor_authentication.yml index 5ee9e0bccf..7edda663ec 100644 --- a/detections/cloud/gcp_successful_single_factor_authentication.yml +++ b/detections/cloud/gcp_successful_single_factor_authentication.yml @@ -1,19 +1,24 @@ name: GCP Successful Single-Factor Authentication id: 40e17d88-87da-414e-b253-8dc1e4f9555b -version: 2 -date: '2024-01-04' +version: 3 +date: '2024-05-25' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies a successful authentication event against - Google Cloud Platform for an account without Multi-Factor Authentication enabled. - This could be evidence of a missconfiguration, a policy violation or an account - take over attempt that should be investigated -data_source: +description: The following analytic identifies a successful single-factor authentication + event against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication + (MFA) enabled. It uses Google Workspace login event data to detect instances where + MFA is not utilized. This activity is significant as it may indicate a misconfiguration, + policy violation, or potential account takeover attempt. If confirmed malicious, + an attacker could gain unauthorized access to GCP resources, potentially leading + to data breaches, service disruptions, or further exploitation within the cloud + environment. +data_source: - Google Workspace login_success search: '`gws_reports_login` event.name=login_success NOT `gws_login_mfa_methods` - | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, login_challenge_method, app, event.name, vendor_account, action - |`security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `gcp_successful_single_factor_authentication_filter`' + | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, login_challenge_method, + app, event.name, vendor_account, action |`security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `gcp_successful_single_factor_authentication_filter`' how_to_implement: You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google @@ -61,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/gcp_single_factor_auth/gws_login.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/gcp_single_factor_auth/gws_login.log source: gws:reports:login sourcetype: gws:reports:login update_timestamp: true diff --git a/detections/cloud/gcp_unusual_number_of_failed_authentications_from_ip.yml b/detections/cloud/gcp_unusual_number_of_failed_authentications_from_ip.yml index 962884c414..007e7b649a 100644 --- a/detections/cloud/gcp_unusual_number_of_failed_authentications_from_ip.yml +++ b/detections/cloud/gcp_unusual_number_of_failed_authentications_from_ip.yml @@ -1,23 +1,19 @@ name: GCP Unusual Number of Failed Authentications From Ip id: bd8097ed-958a-4873-87d9-44f2b4d85705 -version: 1 -date: '2022-10-13' +version: 2 +date: '2024-05-24' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies one source IP failing to authenticate - into the Google Workspace with multiple valid users. This behavior could represent - an adversary performing a Password Spraying attack against a Google Workspace enviroment - to obtain initial access or elevate privileges. The detection calculates the standard - deviation for source IP and leverages the 3-sigma statistical rule to identify an - unusual number of failed authentication attempts. To customize this analytic, users - can try different combinations of the bucket span time and the calculation of the - upperBound field. This logic can be used for real time security monitoring as well - as threat hunting exercises. While looking for anomalies using statistical methods - like the standard deviation can have benefits, we also recommend using threshold-based - detections to complement coverage. A similar analytic following the threshold model - is `GCP Multiple Users Failing To Authenticate From Ip` -data_source: +description: The following analytic identifies a single source IP failing to authenticate + into Google Workspace with multiple valid users, potentially indicating a Password + Spraying attack. It uses Google Workspace login failure events and calculates the + standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed + authentication attempts. This activity is significant as it may signal an adversary + attempting to gain initial access or elevate privileges. If confirmed malicious, + this could lead to unauthorized access, data breaches, or further exploitation within + the environment. +data_source: - Google Workspace login_failure search: '`gws_reports_login` event.type = login event.name = login_failure| bucket span=5m _time | stats dc(user_name) AS unique_accounts values(user_name) as tried_accounts @@ -44,7 +40,8 @@ tags: asset_type: Google Cloud Platform tenant confidence: 90 impact: 60 - message: 'Unusual number of failed console login attempts (Count: $unique_accounts$) against users from IP Address - $src$' + message: 'Unusual number of failed console login attempts (Count: $unique_accounts$) + against users from IP Address - $src$' mitre_attack_id: - T1586 - T1586.003 @@ -75,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/gcp_gws_multiple_login_failure/gws_login.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/gcp_gws_multiple_login_failure/gws_login.json source: gws_login sourcetype: gws:reports:login update_timestamp: true diff --git a/detections/cloud/github_commit_changes_in_master.yml b/detections/cloud/github_commit_changes_in_master.yml index e4bdf94cc8..0a4052114b 100644 --- a/detections/cloud/github_commit_changes_in_master.yml +++ b/detections/cloud/github_commit_changes_in_master.yml @@ -1,16 +1,18 @@ name: Github Commit Changes In Master id: c9d2bfe2-019f-11ec-a8eb-acde48001122 -version: 1 -date: '2021-08-20' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a pushed or commit to master or main branch. - This is to avoid unwanted modification to master without a review to the changes. - Ideally in terms of devsecops the changes made in a branch and do a PR for review. - of course in some cases admin of the project may did a changes directly to master - branch -data_source: +description: The following analytic detects direct commits or pushes to the master + or main branch in a GitHub repository. It leverages GitHub logs to identify events + where changes are made directly to these critical branches. This activity is significant + because direct modifications to the master or main branch bypass the standard review + process, potentially introducing unreviewed and harmful changes. If confirmed malicious, + this could lead to unauthorized code execution, security vulnerabilities, or compromised + project integrity. +data_source: - GitHub search: '`github` branches{}.name = main OR branches{}.name = master | stats count min(_time) as firstTime max(_time) as lastTime by commit.commit.author.email commit.author.login @@ -48,6 +50,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1199/github_push_master/github_push_master.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1199/github_push_master/github_push_master.log source: github sourcetype: aws:firehose:json diff --git a/detections/cloud/github_commit_in_develop.yml b/detections/cloud/github_commit_in_develop.yml index 93dd9436e6..1346e0f952 100644 --- a/detections/cloud/github_commit_in_develop.yml +++ b/detections/cloud/github_commit_in_develop.yml @@ -1,15 +1,18 @@ name: Github Commit In Develop id: f3030cb6-0b02-11ec-8f22-acde48001122 -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a pushed or commit to develop branch. This is - to avoid unwanted modification to develop without a review to the changes. Ideally - in terms of devsecops the changes made in a branch and do a PR for review. of course - in some cases admin of the project may did a changes directly to master branch -data_source: +description: The following analytic detects commits pushed directly to the 'develop' + or 'main' branches in a GitHub repository. It leverages GitHub logs, focusing on + commit metadata such as author details, commit messages, and timestamps. This activity + is significant as direct commits to these branches can bypass the review process, + potentially introducing unvetted changes. If confirmed malicious, this could lead + to unauthorized code modifications, introducing vulnerabilities or backdoors into + the codebase, and compromising the integrity of the development lifecycle. +data_source: - GitHub search: '`github` branches{}.name = main OR branches{}.name = develop | stats count min(_time) as firstTime max(_time) as lastTime by commit.author.html_url commit.commit.author.email @@ -47,6 +50,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1199/github_push_master/github_push_develop.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1199/github_push_master/github_push_develop.json source: github sourcetype: aws:firehose:json diff --git a/detections/cloud/github_dependabot_alert.yml b/detections/cloud/github_dependabot_alert.yml index bb3b9bdcc8..da4f09cdc9 100644 --- a/detections/cloud/github_dependabot_alert.yml +++ b/detections/cloud/github_dependabot_alert.yml @@ -1,12 +1,19 @@ name: GitHub Dependabot Alert id: 05032b04-4469-4034-9df7-05f607d75cba -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-27' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: "The following analytic is made by first searching for logs that contain the action \"create\" and renames certain fields for easier analysis. Then, this analytic uses the \"stats\" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The \"phase\" field is set to \"code\" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the \"create\" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps." -data_source: +description: "The following analytic identifies the creation of GitHub Dependabot + alerts, which indicate potential vulnerabilities in the codebase. It detects this + activity by searching for logs with the \"create\" action and analyzing fields such + as affected package, severity, and fixed version. This detection is significant + for a SOC because it helps identify and address security risks in the codebase proactively. + If confirmed malicious, these vulnerabilities could be exploited by attackers to + gain unauthorized access or cause breaches, leading to potential data loss or system + compromise." +data_source: - GitHub search: '`github` alert.id=* action=create | rename repository.full_name as repository, repository.html_url as repository_url sender.login as user | stats min(_time) as @@ -56,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/github_security_advisor_alert/github_security_advisor_alert.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/github_security_advisor_alert/github_security_advisor_alert.json sourcetype: aws:firehose:json source: github diff --git a/detections/cloud/github_pull_request_from_unknown_user.yml b/detections/cloud/github_pull_request_from_unknown_user.yml index b54e3440cf..7ab0f9565a 100644 --- a/detections/cloud/github_pull_request_from_unknown_user.yml +++ b/detections/cloud/github_pull_request_from_unknown_user.yml @@ -1,12 +1,19 @@ name: GitHub Pull Request from Unknown User id: 9d7b9100-8878-4404-914e-ca5e551a641e -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-13' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request." -data_source: +description: The following analytic detects pull requests from unknown users on GitHub. + It uses a Splunk query to identify pull requests where the user ID is not specified + and cross-references these with a known users lookup table. This activity is significant + because pull requests from unknown users can introduce malicious code or unauthorized + changes to repositories. If confirmed malicious, this could lead to unauthorized + code changes, data breaches, or other security incidents. Immediate steps include + reviewing the author's name, repository, head reference, and commit message, and + investigating any related artifacts and processes. +data_source: - GitHub search: '`github` check_suite.pull_requests{}.id=* | stats count by check_suite.head_commit.author.name repository.full_name check_suite.pull_requests{}.head.ref check_suite.head_commit.message @@ -56,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/github_pull_request/github_pull_request.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/github_pull_request/github_pull_request.json sourcetype: aws:firehose:json source: github diff --git a/detections/cloud/gsuite_drive_share_in_external_email.yml b/detections/cloud/gsuite_drive_share_in_external_email.yml index 61816b1325..1415347b8c 100644 --- a/detections/cloud/gsuite_drive_share_in_external_email.yml +++ b/detections/cloud/gsuite_drive_share_in_external_email.yml @@ -1,13 +1,17 @@ name: Gsuite Drive Share In External Email id: f6ee02d6-fea0-11eb-b2c2-acde48001122 -version: 1 -date: '2021-08-16' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: experimental type: Anomaly -description: This search is to detect suspicious google drive or google docs files - shared outside or externally. This behavior might be a good hunting query to monitor - exfitration of data made by an attacker or insider to a targetted machine. +description: The following analytic detects Google Drive or Google Docs files shared + externally from an internal domain. It leverages GSuite Drive logs, extracting and + comparing the source and destination email domains to identify external sharing. + This activity is significant as it may indicate potential data exfiltration by an + attacker or insider. If confirmed malicious, this could lead to unauthorized access + to sensitive information, data leakage, and potential compliance violations. Monitoring + this behavior helps in early detection and mitigation of data breaches. data_source: [] search: '`gsuite_drive` NOT (email IN("", "null")) | rex field=parameters.owner "[^@]+@(?[^@]+)" | rex field=email "[^@]+@(?[^@]+)" | where src_domain = "internal_test_email.com" @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1567.002/gsuite_share_drive/gdrive_share_external.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1567.002/gsuite_share_drive/gdrive_share_external.log source: http:gsuite sourcetype: gsuite:drive:json diff --git a/detections/cloud/gsuite_email_suspicious_attachment.yml b/detections/cloud/gsuite_email_suspicious_attachment.yml index d78ce9524a..5c9abfa33c 100644 --- a/detections/cloud/gsuite_email_suspicious_attachment.yml +++ b/detections/cloud/gsuite_email_suspicious_attachment.yml @@ -1,16 +1,18 @@ name: GSuite Email Suspicious Attachment id: 6d663014-fe92-11eb-ab07-acde48001122 -version: 1 -date: '2021-08-16' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a suspicious attachment file extension in Gsuite - email that may related to spear phishing attack. This file type is commonly used - by malware to lure user to click on it to execute malicious code to compromised - targetted machine. But this search can also catch some normal files related to this - file type that maybe send by employee or network admin. -data_source: +description: The following analytic detects suspicious attachment file extensions + in GSuite emails, potentially indicating a spear-phishing attack. It leverages GSuite + Gmail logs to identify emails with attachments having file extensions commonly associated + with malware, such as .exe, .bat, and .js. This activity is significant as these + file types are often used to deliver malicious payloads, posing a risk of compromising + targeted machines. If confirmed malicious, this could lead to unauthorized code + execution, data breaches, or further network infiltration. +data_source: - G Suite Gmail search: '`gsuite_gmail` "attachment{}.file_extension_type" IN ("pl", "py", "rb", "sh", "bat", "exe", "dll", "cpl", "com", "js", "vbs", "ps1", "reg","swf", "cmd", "go") @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_attachment_ext/gsuite_gmail_file_ext.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_attachment_ext/gsuite_gmail_file_ext.log source: http:gsuite sourcetype: gsuite:gmail:bigquery diff --git a/detections/cloud/gsuite_email_suspicious_subject_with_attachment.yml b/detections/cloud/gsuite_email_suspicious_subject_with_attachment.yml index ed60a9f68f..ff370ee6bb 100644 --- a/detections/cloud/gsuite_email_suspicious_subject_with_attachment.yml +++ b/detections/cloud/gsuite_email_suspicious_subject_with_attachment.yml @@ -1,19 +1,19 @@ name: Gsuite Email Suspicious Subject With Attachment id: 8ef3971e-00f2-11ec-b54f-acde48001122 -version: 1 -date: '2021-08-19' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a gsuite email contains suspicious subject having - known file type used in spear phishing. This technique is a common and effective - entry vector of attacker to compromise a network by luring the user to click or - execute the suspicious attachment send from external email account because of the - effective social engineering of subject related to delivery, bank and so on. On - the other hand this detection may catch a normal email traffic related to legitimate - transaction so better to check the email sender, spelling and etc. avoid click link - or opening the attachment if you are not expecting this type of e-mail. -data_source: +description: The following analytic identifies Gsuite emails with suspicious subjects + and attachments commonly used in spear phishing attacks. It leverages Gsuite email + logs, focusing on specific keywords in the subject line and known malicious file + types in attachments. This activity is significant for a SOC as spear phishing is + a prevalent method for initial compromise, often leading to further malicious actions. + If confirmed malicious, this activity could result in unauthorized access, data + exfiltration, or further malware deployment, posing a significant risk to the organization's + security. +data_source: - G Suite Gmail search: '`gsuite_gmail` num_message_attachments > 0 subject IN ("*dhl*", "* ups *", "*delivery*", "*parcel*", "*label*", "*invoice*", "*postal*", "* fedex *", "* usps @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_subj/gsuite_susp_subj_attach.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_subj/gsuite_susp_subj_attach.log source: http:gsuite sourcetype: gsuite:gmail:bigquery diff --git a/detections/cloud/gsuite_email_with_known_abuse_web_service_link.yml b/detections/cloud/gsuite_email_with_known_abuse_web_service_link.yml index e8b8f07159..f3b12b02de 100644 --- a/detections/cloud/gsuite_email_with_known_abuse_web_service_link.yml +++ b/detections/cloud/gsuite_email_with_known_abuse_web_service_link.yml @@ -1,15 +1,18 @@ name: Gsuite Email With Known Abuse Web Service Link id: 8630aa22-042b-11ec-af39-acde48001122 -version: 1 -date: '2021-08-23' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytics is to detect a gmail containing a link that are known - to be abused by malware or attacker like pastebin, telegram and discord to deliver - malicious payload. This event can encounter some normal email traffic within organization - and external email that normally using this application and services. -data_source: +description: The following analytic detects emails in Gsuite containing links to known + abuse web services such as Pastebin, Telegram, and Discord. It leverages Gsuite + Gmail logs to identify emails with these specific domains in their links. This activity + is significant because these services are commonly used by attackers to deliver + malicious payloads. If confirmed malicious, this could lead to the delivery of malware, + phishing attacks, or other harmful activities, potentially compromising sensitive + information or systems within the organization. +data_source: - G Suite Gmail search: '`gsuite_gmail` "link_domain{}" IN ("*pastebin.com*", "*discord*", "*telegram*","t.me") | rex field=source.from_header_address "[^@]+@(?[^@]+)" | rex field=destination{}.address @@ -56,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_url/gsuite_susp_url.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_susp_url/gsuite_susp_url.log source: http:gsuite sourcetype: gsuite:gmail:bigquery diff --git a/detections/cloud/gsuite_outbound_email_with_attachment_to_external_domain.yml b/detections/cloud/gsuite_outbound_email_with_attachment_to_external_domain.yml index 9cc122c01e..8a4a5f238e 100644 --- a/detections/cloud/gsuite_outbound_email_with_attachment_to_external_domain.yml +++ b/detections/cloud/gsuite_outbound_email_with_attachment_to_external_domain.yml @@ -1,15 +1,18 @@ name: Gsuite Outbound Email With Attachment To External Domain id: dc4dc3a8-ff54-11eb-8bf7-acde48001122 -version: 2 -date: '2024-03-25' +version: 3 +date: '2024-05-10' author: Teoderick Contreras, Stanislav Miskovic, Splunk status: production type: Hunting -description: This search is to detect a suspicious outbound e-mail from internal email - to external email domain. This can be a good hunting query to monitor insider or - outbound email traffic for not common domain e-mail. The idea is to parse the domain - of destination email check if there is a minimum outbound traffic < 20 with attachment. -data_source: +description: The following analytic detects outbound emails with attachments sent + from an internal email domain to an external domain. It leverages Gsuite Gmail logs, + parsing the source and destination email domains, and flags emails with fewer than + 20 outbound instances. This activity is significant as it may indicate potential + data exfiltration or insider threats. If confirmed malicious, an attacker could + use this method to exfiltrate sensitive information, leading to data breaches and + compliance violations. +data_source: - G Suite Gmail search: '`gsuite_gmail` num_message_attachments > 0 | rex field=source.from_header_address "[^@]+@(?[^@]+)" | rex field=destination{}.address "[^@]+@(?[^@]+)" @@ -56,14 +59,15 @@ tags: - source.from_header_address - destination.address - num_message_attachments - - dest_domain - - phase + - dest_domain + - phase - severity risk_score: 9 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_outbound_email_to_external/gsuite_external_domain.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gsuite_outbound_email_to_external/gsuite_external_domain.log source: http:gsuite sourcetype: gsuite:gmail:bigquery diff --git a/detections/cloud/gsuite_suspicious_shared_file_name.yml b/detections/cloud/gsuite_suspicious_shared_file_name.yml index abf04000d8..00d9aecf1a 100644 --- a/detections/cloud/gsuite_suspicious_shared_file_name.yml +++ b/detections/cloud/gsuite_suspicious_shared_file_name.yml @@ -1,17 +1,18 @@ name: Gsuite Suspicious Shared File Name id: 07eed200-03f5-11ec-98fb-acde48001122 -version: 1 -date: '2021-08-23' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a shared file in google drive with suspicious - file name that are commonly used by spear phishing campaign. This technique is very - popular to lure the user by running a malicious document or click a malicious link - within the shared file that will redirected to malicious website. This detection - can also catch some normal email communication between organization and its external - customer. -data_source: +description: The following analytic detects shared files in Google Drive with suspicious + filenames commonly used in spear phishing campaigns. It leverages GSuite Drive logs + to identify documents with titles that include keywords like "dhl," "ups," "invoice," + and "shipment." This activity is significant because such filenames are often used + to lure users into opening malicious documents or clicking harmful links. If confirmed + malicious, this activity could lead to unauthorized access, data theft, or further + compromise of the user's system. +data_source: - G Suite Drive search: '`gsuite_drive` parameters.owner_is_team_drive=false "parameters.doc_title" IN ("*dhl*", "* ups *", "*delivery*", "*parcel*", "*label*", "*invoice*", "*postal*", @@ -71,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gdrive_susp_file_share/gdrive_susp_attach.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/gdrive_susp_file_share/gdrive_susp_attach.log source: http:gsuite sourcetype: gsuite:drive:json diff --git a/detections/cloud/high_number_of_login_failures_from_a_single_source.yml b/detections/cloud/high_number_of_login_failures_from_a_single_source.yml index deb1ad386c..ed4ccbb777 100644 --- a/detections/cloud/high_number_of_login_failures_from_a_single_source.yml +++ b/detections/cloud/high_number_of_login_failures_from_a_single_source.yml @@ -1,20 +1,31 @@ name: High Number of Login Failures from a single source id: 7f398cfb-918d-41f4-8db8-2e2474e02222 -version: 2 -date: '2020-12-16' +version: 3 +date: '2024-05-25' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: Anomaly -description: This analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. Specifically, it identifies scenarios where there are more than 10 unsuccessful login attempts within a short time frame. The detection leverages Office365 management activity logs, specifically the AzureActiveDirectoryStsLogon records from the AzureActiveDirectory workload. It aggregates these logs in 5-minute intervals to count the number of failed login attempts and associates them with the originating source IP address. Multiple failed login attempts from a single source can be indicative of brute-force attacks, password spraying, or other malicious authentication attempts. Identifying and responding to these patterns promptly can prevent unauthorized access and potential breaches. If this detection represents a true positive, an attacker might be attempting to gain unauthorized access to an Office365 account. Successful compromise could lead to unauthorized access to sensitive data, potential lateral movement within the organization, or further malicious activities using the compromised account. -data_source: +description: The following analytic detects multiple failed login attempts in Office365 + Azure Active Directory from a single source IP address. It leverages Office365 management + activity logs, specifically AzureActiveDirectoryStsLogon records, aggregating these + logs in 5-minute intervals to count failed login attempts. This activity is significant + as it may indicate brute-force attacks or password spraying, which are critical + to monitor. If confirmed malicious, an attacker could gain unauthorized access to + Office365 accounts, leading to potential data breaches, lateral movement within + the organization, or further malicious activities using the compromised account. +data_source: - O365 UserLoginFailed -search: '`o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed record_type=AzureActiveDirectoryStsLogon - | bucket span=5m _time - | stats dc(_raw) AS failed_attempts values(user) as user values(LogonError) as LogonError values(signature) as signature values(UserAgent) as UserAgent by _time, src_ip - | where failed_attempts > 10 - | `high_number_of_login_failures_from_a_single_source_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. Adjust the threshold value to suit the specific environment, as environments with naturally higher login failures might generate false positives at a lower threshold. -known_false_positives: An Ip address with more than 10 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. +search: '`o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed + record_type=AzureActiveDirectoryStsLogon | bucket span=5m _time | stats dc(_raw) + AS failed_attempts values(user) as user values(LogonError) as LogonError values(signature) + as signature values(UserAgent) as UserAgent by _time, src_ip | where failed_attempts + > 10 | `high_number_of_login_failures_from_a_single_source_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. Adjust the threshold value to suit the specific + environment, as environments with naturally higher login failures might generate + false positives at a lower threshold. +known_false_positives: An Ip address with more than 10 failed authentication attempts + in the span of 5 minutes may also be triggered by a broken application. references: - https://attack.mitre.org/techniques/T1110/001/ - https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray @@ -60,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/o365_high_number_authentications_for_user/o365_high_number_authentications_for_user.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/o365_high_number_authentications_for_user/o365_high_number_authentications_for_user.log source: o365 - sourcetype: o365:management:activity \ No newline at end of file + sourcetype: o365:management:activity diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml index 0a0747decb..d012c1e6ef 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml +++ b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml @@ -1,17 +1,19 @@ name: Kubernetes Abuse of Secret by Unusual Location id: 40a064c1-4ec1-4381-9e35-61192ba8ef82 -version: 1 -date: '2023-12-06' +version: 2 +date: '2024-05-11' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. - It identifies anomalies in access patterns by segmenting and analyzing the source of requests by country. - Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, - and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate - an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, - potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects unauthorized access or misuse of Kubernetes + Secrets from unusual locations. It leverages Kubernetes Audit logs to identify anomalies + in access patterns by analyzing the source of requests by country. This activity + is significant for a SOC as Kubernetes Secrets store sensitive information like + passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed + malicious, this behavior could indicate an attacker attempting to exfiltrate or + misuse these secrets, potentially leading to unauthorized access to sensitive systems + or data.' +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=secrets verb=get | iplocation sourceIPs{} @@ -19,7 +21,7 @@ search: '`kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_locations` | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb City Country | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_abuse_of_secret_by_unusual_location_filter` ' + | `kubernetes_abuse_of_secret_by_unusual_location_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -33,7 +35,8 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Access of Kubernetes secret $objectRef.name$ from unusual location $Country$ by $user$ + message: Access of Kubernetes secret $objectRef.name$ from unusual location $Country$ + by $user$ mitre_attack_id: - T1552.007 observable: @@ -69,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml index ba5bee52b3..e26121f0c5 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml +++ b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml @@ -1,24 +1,26 @@ name: Kubernetes Abuse of Secret by Unusual User Agent id: 096ab390-05ca-462c-884e-343acd5b9240 -version: 1 -date: '2023-12-06' +version: 2 +date: '2024-05-22' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. - It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user agent. - Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, - and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate - an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, - potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects unauthorized access or misuse of Kubernetes + Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies + in access patterns by analyzing the source of requests based on user agents. This + activity is significant for a SOC because Kubernetes Secrets store sensitive information + like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed + malicious, this activity could lead to unauthorized access to sensitive systems + or data, potentially resulting in significant security breaches and exfiltration + of critical information.' +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_agents` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_abuse_of_secret_by_unusual_user_agent_filter` ' + | `kubernetes_abuse_of_secret_by_unusual_user_agent_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -32,7 +34,8 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Access of Kubernetes secret $objectRef.name$ from unusual user agent $userAgent$ by $user$ + message: Access of Kubernetes secret $objectRef.name$ from unusual user agent $userAgent$ + by $user$ mitre_attack_id: - T1552.007 observable: @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml index b4626fffee..6d81b53ba3 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml +++ b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml @@ -1,24 +1,25 @@ name: Kubernetes Abuse of Secret by Unusual User Group id: b6f45bbc-4ea9-4068-b3bc-0477f6997ae2 -version: 1 -date: '2023-12-06' +version: 2 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. - It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user group. - Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, - and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate - an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, - potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects unauthorized access or misuse of Kubernetes + Secrets by unusual user groups. It leverages Kubernetes Audit logs to identify anomalies + in access patterns by analyzing the source of requests and user groups. This activity + is significant for a SOC as Kubernetes Secrets store sensitive information like + passwords, OAuth tokens, and SSH keys. If confirmed malicious, this behavior could + indicate an attacker attempting to exfiltrate or misuse these secrets, potentially + leading to unauthorized access to sensitive systems or data.' +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_groups` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_abuse_of_secret_by_unusual_user_group_filter` ' + | `kubernetes_abuse_of_secret_by_unusual_user_group_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -32,7 +33,8 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Access of Kubernetes secret $objectRef.name$ from unusual user group $user.groups{}$ by user name $user$ + message: Access of Kubernetes secret $objectRef.name$ from unusual user group $user.groups{}$ + by user name $user$ mitre_attack_id: - T1552.007 observable: @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml index 393dc802d0..5b44d1e7f8 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml +++ b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml @@ -1,24 +1,26 @@ name: Kubernetes Abuse of Secret by Unusual User Name id: df6e9cae-5257-4a34-8f3a-df49fa0f5c46 -version: 1 -date: '2023-12-06' +version: 2 +date: '2024-05-27' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. - It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user name. - Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, - and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate - an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, - potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects unauthorized access or misuse of Kubernetes + Secrets by unusual user names. It leverages Kubernetes Audit logs to identify anomalies + in access patterns by analyzing the source of requests based on user names. This + activity is significant for a SOC as Kubernetes Secrets store sensitive information + like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed + malicious, this activity could lead to unauthorized access to sensitive systems + or data, potentially resulting in significant security breaches and exfiltration + of sensitive information.' +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_names` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_abuse_of_secret_by_unusual_user_name_filter` ' + | `kubernetes_abuse_of_secret_by_unusual_user_name_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -32,7 +34,7 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Access of Kubernetes secret $objectRef.name$ from unusual user name $user$ + message: Access of Kubernetes secret $objectRef.name$ from unusual user name $user$ mitre_attack_id: - T1552.007 observable: @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.007/kube_audit_get_secret/kube_audit_get_secret.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_access_scanning.yml b/detections/cloud/kubernetes_access_scanning.yml index 8cdcc54d8b..55e2362f32 100644 --- a/detections/cloud/kubernetes_access_scanning.yml +++ b/detections/cloud/kubernetes_access_scanning.yml @@ -1,16 +1,19 @@ name: Kubernetes Access Scanning id: 2f4abe6d-5991-464d-8216-f90f42999764 -version: 1 -date: '2023-12-07' +version: 2 +date: '2024-05-12' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects potential scanning activities within a Kubernetes environment. - It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities. - The analytic detects this behavior by monitoring Kubernetes audit logs for patterns indicative of scanning, such as repeated failed access attempts or unusual API requests. - This behavior is worth identifying for a SOC as it could indicate an attackers preliminary step in an attack, aiming to gather information about the system to find potential vulnerabilities. - The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects potential scanning activities within + a Kubernetes environment. It identifies unauthorized access attempts, probing of + public APIs, or attempts to exploit known vulnerabilities by monitoring Kubernetes + audit logs for repeated failed access attempts or unusual API requests. This activity + is significant for a SOC as it may indicate an attacker''s preliminary reconnaissance + to gather information about the system. If confirmed malicious, this activity could + lead to unauthorized access to sensitive systems or data, posing a severe security + risk.' +data_source: - Kubernetes Audit search: '`kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} @@ -18,7 +21,7 @@ search: '`kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.c by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_access_scanning_filter` ' + | `kubernetes_access_scanning_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -32,7 +35,7 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Kubernetes scanning from ip $src_ip$ + message: Kubernetes scanning from ip $src_ip$ mitre_attack_id: - T1046 observable: @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1046/kubernetes_scanning/kubernetes_scanning.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1046/kubernetes_scanning/kubernetes_scanning.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_anomalous_inbound_network_activity_from_process.yml b/detections/cloud/kubernetes_anomalous_inbound_network_activity_from_process.yml index 700b3cbecd..678f392e81 100644 --- a/detections/cloud/kubernetes_anomalous_inbound_network_activity_from_process.yml +++ b/detections/cloud/kubernetes_anomalous_inbound_network_activity_from_process.yml @@ -1,21 +1,19 @@ name: Kubernetes Anomalous Inbound Network Activity from Process id: 10442d8b-0701-4c25-911d-d67b906e713c -version: 1 -date: '2024-01-10' +version: 2 +date: '2024-05-17' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: 'This detection detects inbound network traffic volume anomalies from processes running within containerised workloads. - Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly.This detection - leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud - using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, - tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for destination (receiving) workload process pairs over the last 1 hour, - with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high inbound network activity. - Anomalies in inbound network traffic may suggest that the container is receiving unexpected or unauthorized data, potentially indicative of a breach, - a vulnerability exploitation attempt, an attempt to overload the service, or propagation of malware. Successful compromise of a containerised - application resulting in the ability to upload data, can result in installation of command and control software or other malware, - data integrity damage, container escape, and further compromise of the environment. Additionally this kind of activity may result in - resource contention, performance degradation and disruption to the normal operation of the environment.' +description: 'The following analytic identifies anomalous inbound network traffic + volumes from processes within containerized workloads. It leverages Network Performance + Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability + Cloud. The detection compares recent metrics (tcp.bytes, tcp.new_sockets, tcp.packets, + udp.bytes, udp.packets) over the last hour with the average over the past 30 days. + This activity is significant as it may indicate unauthorized data reception, potential + breaches, vulnerability exploitation, or malware propagation. If confirmed malicious, + it could lead to command and control installation, data integrity damage, container + escape, and further environment compromise.' data_source: [] search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name dest.workload.name dest.process.name span=10s | eval key=''dest.workload.name'' + ":" + ''dest.process.name'' @@ -36,7 +34,7 @@ search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metr | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name dest.workload.name dest.process.name | where count > 5 | rename k8s.cluster.name as host - | `kubernetes_anomalous_inbound_network_activity_from_process_filter` ' + | `kubernetes_anomalous_inbound_network_activity_from_process_filter`' how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup @@ -46,10 +44,6 @@ how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cl * Name sim_npm_metrics_to_metrics_index - * Org ID - - * Signal Flow Program data(''tcp.packets'').publish(label=''A''); data(''tcp.bytes'').publish(label=''B''); data(''tcp.new_sockets'').publish(label=''C''); data(''udp.packets'').publish(label=''D''); data(''udp.bytes'').publish(label=''E'') - * Metric Resolution 10000' known_false_positives: unknown references: @@ -60,7 +54,8 @@ tags: asset_type: Kubernetes confidence: 50 impact: 50 - message: Kubernetes Anomalous Inbound Network Activity from Process in kubernetes cluster $host$ + message: Kubernetes Anomalous Inbound Network Activity from Process in kubernetes + cluster $host$ mitre_attack_id: - T1204 observable: @@ -75,8 +70,8 @@ tags: required_fields: - tcp.* - udp.* - - k8s.cluster.name + - k8s.cluster.name - dest.process.name - - dest.workload.name + - dest.workload.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_anomalous_inbound_outbound_network_io.yml b/detections/cloud/kubernetes_anomalous_inbound_outbound_network_io.yml index 4a4e95fc43..36e40b25e4 100644 --- a/detections/cloud/kubernetes_anomalous_inbound_outbound_network_io.yml +++ b/detections/cloud/kubernetes_anomalous_inbound_outbound_network_io.yml @@ -1,17 +1,18 @@ name: Kubernetes Anomalous Inbound Outbound Network IO id: 4f3b0c97-657e-4547-a89a-9a50c656e3cd -version: 1 -date: '2023-12-19' +version: 2 +date: '2024-05-13' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. - It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. - A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. - An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, - command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, - and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, - potentially leading to data breaches, service outages, financial losses, and reputational damage. +description: The following analytic identifies high inbound or outbound network I/O + anomalies in Kubernetes containers. It leverages process metrics from an OTEL collector + and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. A lookup + table with average and standard deviation values for network I/O is used to detect + anomalies persisting over a 1-hour period. This activity is significant as it may + indicate data exfiltration, command and control communication, or unauthorized data + transfers. If confirmed malicious, it could lead to data breaches, service outages, + financial losses, and reputational damage. data_source: [] search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace(''k8s.pod.name'', "-\w{5}$$|-[abcdef0-9]{8,10}-\w{5}$$", "") @@ -31,29 +32,37 @@ search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8 | rename service as k8s.service | where count > 5 | rename k8s.node.name as host - | `kubernetes_anomalous_inbound_outbound_network_traffic_io_filter` ' + | `kubernetes_anomalous_inbound_outbound_network_io_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -64,7 +73,8 @@ tags: asset_type: Kubernetes confidence: 50 impact: 50 - message: Kubernetes Anomalous Inbound Outbound Network IO from container on host $host$ + message: Kubernetes Anomalous Inbound Outbound Network IO from container on host + $host$ mitre_attack_id: - T1204 observable: @@ -79,8 +89,8 @@ tags: required_fields: - k8s.pod.network.io - direction - - k8s.cluster.name - - k8s.node.name + - k8s.cluster.name + - k8s.node.name - k8s.pod.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_anomalous_inbound_to_outbound_network_io_ratio.yml b/detections/cloud/kubernetes_anomalous_inbound_to_outbound_network_io_ratio.yml index 66d5bb3f25..a115c50b9f 100644 --- a/detections/cloud/kubernetes_anomalous_inbound_to_outbound_network_io_ratio.yml +++ b/detections/cloud/kubernetes_anomalous_inbound_to_outbound_network_io_ratio.yml @@ -1,16 +1,19 @@ name: Kubernetes Anomalous Inbound to Outbound Network IO Ratio id: 9d8f6e3f-39df-46d8-a9d4-96173edc501f -version: 1 -date: '2023-12-19' +version: 2 +date: '2024-05-26' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. - It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. - A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. - An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, - or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. - Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster. +description: The following analytic identifies significant changes in network communication + behavior within Kubernetes containers by examining the inbound to outbound network + IO ratios. It leverages process metrics from an OTEL collector and Kubelet Stats + Receiver, along with data from Splunk Observability Cloud. Anomalies are detected + using a lookup table containing average and standard deviation values for network + IO, triggering an event if the anomaly persists for over an hour. This activity + is significant as it may indicate data exfiltration, command and control communication, + or compromised container behavior. If confirmed malicious, it could lead to data + breaches, service outages, and unauthorized access within the Kubernetes cluster. data_source: [] search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") @@ -33,29 +36,37 @@ search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8 | rename service as k8s.service | where count > 5 | rename k8s.node.name as host - | `kubernetes_anomalous_inbound_to_outbound_network_io_ratio_filter` ' + | `kubernetes_anomalous_inbound_to_outbound_network_io_ratio_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -66,7 +77,8 @@ tags: asset_type: Kubernetes confidence: 50 impact: 50 - message: Kubernetes Anomalous Inbound to Outbound Network IO Ratio from Container on host $host$ + message: Kubernetes Anomalous Inbound to Outbound Network IO Ratio from Container + on host $host$ mitre_attack_id: - T1204 observable: @@ -81,8 +93,8 @@ tags: required_fields: - k8s.pod.network.io - direction - - k8s.cluster.name - - k8s.node.name + - k8s.cluster.name + - k8s.node.name - k8s.pod.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_anomalous_outbound_network_activity_from_process.yml b/detections/cloud/kubernetes_anomalous_outbound_network_activity_from_process.yml index f71a6800fc..bfc7974b65 100644 --- a/detections/cloud/kubernetes_anomalous_outbound_network_activity_from_process.yml +++ b/detections/cloud/kubernetes_anomalous_outbound_network_activity_from_process.yml @@ -1,20 +1,19 @@ name: Kubernetes Anomalous Outbound Network Activity from Process id: dd6afee6-e0a3-4028-a089-f47dd2842c22 -version: 1 -date: '2024-01-10' +version: 2 +date: '2024-05-25' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: 'This detection detects outbound network traffic volume anomalies from processes running within containerised workloads. - Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly. This detection - leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud - using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, - tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for source (transmitting) workload process pairs over the last 1 hout, - with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high outbound network activity. - Anonymously high outbound network traffic from a process running in a container is a potential indication of data exfiltration, or an indication that the process has been modified. - Anomalously high outbound network activity from a process running within a container suggests the potential compromise, which may lead to unauthorized data exfiltration, - communication with malicious entities, or the propagation of malware to external systems. The compromised container could also serve as a pivot point - for further attacks within the containerized environment.' +description: 'The following analytic identifies anomalously high outbound network + activity from processes running within containerized workloads in a Kubernetes environment. + It leverages Network Performance Monitoring metrics collected via an OTEL collector + and pulled from Splunk Observability Cloud. The detection compares recent network + metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the + last hour with the average metrics over the past 30 days. This activity is significant + as it may indicate data exfiltration, process modification, or container compromise. + If confirmed malicious, it could lead to unauthorized data exfiltration, communication + with malicious entities, or further attacks within the containerized environment.' data_source: [] search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name source.process.name span=10s | eval key=''source.workload.name'' + ":" + ''source.process.name'' @@ -35,7 +34,7 @@ search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metr | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name source.workload.name source.process.name | where count > 5 | rename k8s.cluster.name as host - | `kubernetes_anomalous_outbound_network_activity_from_process_filter` ' + | `kubernetes_anomalous_outbound_network_activity_from_process_filter`' how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup @@ -45,10 +44,6 @@ how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cl * Name sim_npm_metrics_to_metrics_index - * Org ID - - * Signal Flow Program data(''tcp.packets'').publish(label=''A''); data(''tcp.bytes'').publish(label=''B''); data(''tcp.new_sockets'').publish(label=''C''); data(''udp.packets'').publish(label=''D''); data(''udp.bytes'').publish(label=''E'') - * Metric Resolution 10000' known_false_positives: unknown references: @@ -59,7 +54,8 @@ tags: asset_type: Kubernetes confidence: 50 impact: 50 - message: Kubernetes Anomalous Outbound Network Activity from Process in kubernetes cluster $host$ + message: Kubernetes Anomalous Outbound Network Activity from Process in kubernetes + cluster $host$ mitre_attack_id: - T1204 observable: @@ -74,9 +70,9 @@ tags: required_fields: - tcp.* - udp.* - - k8s.cluster.name - - source.workload.name - - dest.workload.name + - k8s.cluster.name + - source.workload.name + - dest.workload.name - udp.packets risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_anomalous_traffic_on_network_edge.yml b/detections/cloud/kubernetes_anomalous_traffic_on_network_edge.yml index 23aaaf673b..8d7a99c3bd 100644 --- a/detections/cloud/kubernetes_anomalous_traffic_on_network_edge.yml +++ b/detections/cloud/kubernetes_anomalous_traffic_on_network_edge.yml @@ -1,15 +1,19 @@ name: Kubernetes Anomalous Traffic on Network Edge id: 886c7e51-2ea1-425d-8705-faaca5a64cc6 -version: 1 -date: '2024-01-10' +version: 2 +date: '2024-05-24' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: 'This detection detects network traffic volume anomalies between workloads in a microservices hosted application, or between a workload and the outside world if the workload is shown as (unknown). - This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on (https://splunkbase.splunk.com/app/5247). - This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics between workloads over the last 1 hour, with the average of those metrics over the last 30 days in order - to detect any anonymously high inbound or outbound network activity. Unexpected spikes in network traffic may signify unauthorized data transfers, or abnormal behavior within the microservices ecosystem. - Such activity might signify data exfiltration, unauthorized lateral movement, within the microservices environment. If a bad actor is responsible for this traffic they could compromise additional services or extract sensitive data, potentially leading to data breaches.' +description: 'The following analytic identifies anomalous network traffic volumes + between Kubernetes workloads or between a workload and external sources. It leverages + Network Performance Monitoring metrics collected via an OTEL collector and pulled + from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, + tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the + average over the past 30 days to identify significant deviations. This activity + is significant as unexpected spikes may indicate unauthorized data transfers or + lateral movement. If confirmed malicious, it could lead to data exfiltration or + compromise of additional services, potentially resulting in data breaches.' data_source: [] search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name span=10s | eval key=''source.workload.name'' + ":" + ''dest.workload.name'' @@ -31,7 +35,7 @@ search: '| mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metr | rename service as k8s.service | where count > 5 | rename k8s.cluster.name as host - | `kubernetes_anomalous_traffic_on_network_edge_filter` ' + | `kubernetes_anomalous_traffic_on_network_edge_filter`' how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup @@ -41,10 +45,6 @@ how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cl * Name sim_npm_metrics_to_metrics_index - * Org ID - - * Signal Flow Program data(''tcp.packets'').publish(label=''A''); data(''tcp.bytes'').publish(label=''B''); data(''tcp.new_sockets'').publish(label=''C''); data(''udp.packets'').publish(label=''D''); data(''udp.bytes'').publish(label=''E'') - * Metric Resolution 10000' known_false_positives: unknown references: @@ -70,9 +70,9 @@ tags: required_fields: - tcp.* - udp.* - - k8s.cluster.name - - source.workload.name - - dest.workload.name + - k8s.cluster.name + - source.workload.name + - dest.workload.name - udp.packets risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml b/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml index 1cdaa0841a..2c4d27b19c 100644 --- a/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml +++ b/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml @@ -1,24 +1,24 @@ name: Kubernetes AWS detect suspicious kubectl calls id: 042a3d32-8318-4763-9679-09db2644a8f2 -version: 2 -date: '2023-12-19' +version: 3 +date: '2024-05-18' author: Rod Soto, Patrick Bareiss, Splunk status: experimental type: Anomaly -description: 'The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. - It identifies this behavior by monitoring for API calls from users who have not provided any token or password in their request. - This is a significant behavior to identify for a SOC as it indicates a severe misconfiguration that allows unfettered access to a cluster - with no traceability to a user or service. The impact of such an attack could be substantial, - potentially granting an attacker access to sensitive data or control over the cluster. - This detection rule is crucial for maintaining the security and integrity of your Kubernetes infrastructure.' -data_source: +description: 'The following analytic detects anonymous and unauthenticated requests + to a Kubernetes cluster. It identifies this behavior by monitoring API calls from + users who have not provided any token or password in their request, using data from + `kube_audit` logs. This activity is significant for a SOC as it indicates a severe + misconfiguration, allowing unfettered access to the cluster with no traceability. + If confirmed malicious, an attacker could gain access to sensitive data or control + over the cluster, posing a substantial security risk.' +data_source: - Kubernetes Audit search: '`kube_audit` user.username="system:anonymous" user.groups{} IN ("system:unauthenticated") - | fillnull - | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI - responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb - | rename sourceIPs{} as src_ip, user.username as user - |`kubernetes_aws_detect_suspicious_kubectl_calls_filter`' + | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource + requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} + user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username + as user |`kubernetes_aws_detect_suspicious_kubectl_calls_filter`' how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs. known_false_positives: Kubectl calls are not malicious by nature. However source IP, diff --git a/detections/cloud/kubernetes_create_or_update_privileged_pod.yml b/detections/cloud/kubernetes_create_or_update_privileged_pod.yml index 46084ca99c..b9f1be1cba 100644 --- a/detections/cloud/kubernetes_create_or_update_privileged_pod.yml +++ b/detections/cloud/kubernetes_create_or_update_privileged_pod.yml @@ -1,21 +1,25 @@ name: Kubernetes Create or Update Privileged Pod id: 3c6bd734-334d-4818-ae7c-5234313fc5da -version: 1 -date: '2023-12-14' +version: 2 +date: '2024-05-28' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of privileged pods in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation of pods with root privileges. - This behavior is worth identifying for a SOC as it could potentially allow an attacker to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. - The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. -data_source: +description: The following analytic detects the creation or update of privileged pods + in Kubernetes. It identifies this activity by monitoring Kubernetes Audit logs for + pod configurations that include root privileges. This behavior is significant for + a SOC as it could indicate an attempt to escalate privileges, exploit the kernel, + and gain full access to the host's namespace and devices. If confirmed malicious, + this activity could lead to unauthorized access to sensitive information, data breaches, + and service disruptions, posing a severe threat to the environment. +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"privileged\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_create_or_update_privileged_pod_filter` ' + | `kubernetes_create_or_update_privileged_pod_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -47,17 +51,17 @@ tags: - Splunk Cloud required_fields: - user.groups{} - - kind - - objectRef.name - - objectRef.namespace - - objectRef.resource - - requestObject.kind - - requestObject.spec.type - - responseStatus.code - - sourceIPs{} - - stage - - user.username - - userAgent + - kind + - objectRef.name + - objectRef.namespace + - objectRef.resource + - requestObject.kind + - requestObject.spec.type + - responseStatus.code + - sourceIPs{} + - stage + - user.username + - userAgent - verb - requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration risk_score: 49 @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_cron_job_creation.yml b/detections/cloud/kubernetes_cron_job_creation.yml index 533a2e69cf..fd414326bb 100644 --- a/detections/cloud/kubernetes_cron_job_creation.yml +++ b/detections/cloud/kubernetes_cron_job_creation.yml @@ -1,22 +1,25 @@ name: Kubernetes Cron Job Creation id: 5984dbe8-572f-47d7-9251-3dff6c3f0c0d -version: 1 -date: '2023-12-14' +version: 2 +date: '2024-05-28' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of a Kubernetes cron job, a task scheduled to run automatically at specified intervals. - It identifies this behavior by monitoring Kubernetes Audit logs for creation of a cron job. - This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute malicious tasks repeatedly and automatically, posing a significant threat to the integrity and security of the Kubernetes infrastructure. - The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. -data_source: +description: The following analytic detects the creation of a Kubernetes cron job, + which is a task scheduled to run automatically at specified intervals. It identifies + this activity by monitoring Kubernetes Audit logs for the creation events of cron + jobs. This behavior is significant for a SOC as it could allow an attacker to execute + malicious tasks repeatedly and automatically, posing a threat to the Kubernetes + infrastructure. If confirmed malicious, this activity could lead to persistent attacks, + service disruptions, or unauthorized access to sensitive information. +data_source: - Kubernetes Audit search: '`kube_audit` verb=create "objectRef.resource"=cronjobs | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.schedule requestObject.spec.jobTemplate.spec.template.spec.containers{}.image responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_cron_job_creation_filter` ' + | `kubernetes_cron_job_creation_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -48,24 +51,25 @@ tags: - Splunk Cloud required_fields: - user.groups{} - - kind - - objectRef.name - - objectRef.namespace - - objectRef.resource - - requestObject.kind - - requestObject.spec.schedule - - requestObject.spec.jobTemplate.spec.template.spec.containers{}.image - - responseStatus.code - - sourceIPs{} - - stage - - user.username - - userAgent + - kind + - objectRef.name + - objectRef.namespace + - objectRef.resource + - requestObject.kind + - requestObject.spec.schedule + - requestObject.spec.jobTemplate.spec.template.spec.containers{}.image + - responseStatus.code + - sourceIPs{} + - stage + - user.username + - userAgent - verb risk_score: 49 security_domain: network tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.007/kubernetes_audit_cron_job_creation/kubernetes_audit_cron_job_creation.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.007/kubernetes_audit_cron_job_creation/kubernetes_audit_cron_job_creation.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_daemonset_deployed.yml b/detections/cloud/kubernetes_daemonset_deployed.yml index d2799724c9..059055675a 100644 --- a/detections/cloud/kubernetes_daemonset_deployed.yml +++ b/detections/cloud/kubernetes_daemonset_deployed.yml @@ -1,23 +1,25 @@ name: Kubernetes DaemonSet Deployed id: bf39c3a3-b191-4d42-8738-9d9797bd0c3a -version: 1 -date: '2023-12-14' +version: 2 +date: '2024-05-16' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. - A DaemonSet ensures the presence of a specific pod on every node in the cluster, making it an ideal avenue for persistent access. - This behavior is identified by monitoring Kubernetes Audit logs for the creation of a DaemonSet. - The identified behavior is worth noting for a SOC as it could potentially allow an attacker to maintain persistent access to the Kubernetes infrastructure. - The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. -data_source: +description: The following analytic detects the creation of a DaemonSet in a Kubernetes + cluster. This behavior is identified by monitoring Kubernetes Audit logs for the + creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, + making them a potential vector for persistent access. This activity is significant + for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes + infrastructure. If confirmed malicious, it could lead to persistent attacks, service + disruptions, or unauthorized access to sensitive information. +data_source: - Kubernetes Audit search: '`kube_audit` "objectRef.resource"=daemonsets verb=create | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_daemonset_deployed_filter` ' + | `kubernetes_daemonset_deployed_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -49,22 +51,23 @@ tags: - Splunk Cloud required_fields: - user.groups{} - - kind - - objectRef.name - - objectRef.namespace - - objectRef.resource - - requestObject.kind - - responseStatus.code - - sourceIPs{} - - stage - - user.username - - userAgent + - kind + - objectRef.name + - objectRef.namespace + - objectRef.resource + - requestObject.kind + - responseStatus.code + - sourceIPs{} + - stage + - user.username + - userAgent - verb risk_score: 49 security_domain: network tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_audit_daemonset_created/kubernetes_audit_daemonset_created.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_audit_daemonset_created/kubernetes_audit_daemonset_created.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_falco_shell_spawned.yml b/detections/cloud/kubernetes_falco_shell_spawned.yml index 2bbb940e1b..71c85b1554 100644 --- a/detections/cloud/kubernetes_falco_shell_spawned.yml +++ b/detections/cloud/kubernetes_falco_shell_spawned.yml @@ -1,20 +1,24 @@ name: Kubernetes Falco Shell Spawned id: d2feef92-d54a-4a19-8306-b47c6ceba5b2 -version: 1 -date: '2023-12-13' +version: 2 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects instances where a shell is spawned within a Kubernetes container, a behavior often indicative of an attacker gaining unauthorized access. - Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment, flagging when a shell is spawned in a container. - This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges, posing a significant threat to the integrity and security of the Kubernetes infrastructure. - The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. -data_source: +description: The following analytic detects instances where a shell is spawned within + a Kubernetes container. Leveraging Falco, a cloud-native runtime security tool, + this analytic monitors system calls within the Kubernetes environment and flags + when a shell is spawned. This activity is significant for a SOC as it may indicate + unauthorized access, allowing an attacker to execute arbitrary commands, manipulate + container processes, or escalate privileges. If confirmed malicious, this could + lead to data breaches, service disruptions, or unauthorized access to sensitive + information, severely impacting the Kubernetes infrastructure's integrity and security. +data_source: - Kubernetes Falco search: '`kube_container_falco` "A shell was spawned in a container" | fillnull | stats count by container_image container_image_tag container_name parent proc_exepath process user - | `kubernetes_falco_shell_spawned_filter` ' + | `kubernetes_falco_shell_spawned_filter`' how_to_implement: The detection is based on data that originates from Falco, a cloud native runtime security tool. Falco is designed to detect anomalous activity in your applications and is a crucial component of this detection rule. To implement this detection rule, you need to install and configure Falco in your Kubernetes environment. @@ -42,18 +46,19 @@ tags: - Splunk Enterprise Security - Splunk Cloud required_fields: - - container_image - - container_image_tag - - container_name - - parent - - proc_exepath - - process + - container_image + - container_image_tag + - container_name + - parent + - proc_exepath + - process - user risk_score: 49 security_domain: network tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_falco_shell_spawned/kubernetes_falco_shell_spawned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_falco_shell_spawned/kubernetes_falco_shell_spawned.log sourcetype: kube:container:falco source: kubernetes diff --git a/detections/cloud/kubernetes_newly_seen_tcp_edge.yml b/detections/cloud/kubernetes_newly_seen_tcp_edge.yml index d047b3d339..2425eaa829 100644 --- a/detections/cloud/kubernetes_newly_seen_tcp_edge.yml +++ b/detections/cloud/kubernetes_newly_seen_tcp_edge.yml @@ -1,19 +1,19 @@ name: Kubernetes newly seen TCP edge id: 13f081d6-7052-428a-bbb0-892c79ca7c65 -version: 1 -date: '2024-01-10' +version: 2 +date: '2024-05-15' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: 'This analytic detects TCP communication between a newly seen source and destination workload pair. - This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring - metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). - This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. - Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. - Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. - Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, - or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, - putting the applications integrity, availability, and confidentiality at risk.' +description: 'The following analytic identifies newly seen TCP communication between + source and destination workload pairs within a Kubernetes cluster. It leverages + Network Performance Monitoring metrics collected via an OTEL collector and pulled + from Splunk Observability Cloud. The detection compares network activity over the + last hour with the past 30 days to spot new inter-workload communications. This + is significant as new connections can indicate changes in application behavior or + potential security threats. If malicious, unauthorized connections could lead to + data breaches, privilege escalation, lateral movement, or disruption of critical + services, compromising the application''s integrity, availability, and confidentiality.' data_source: [] search: '| mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" @@ -24,7 +24,7 @@ search: '| mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metr | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host - | `kubernetes_newly_seen_tcp_edge_filter` ' + | `kubernetes_newly_seen_tcp_edge_filter`' how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup @@ -34,10 +34,6 @@ how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cl * Name sim_npm_metrics_to_metrics_index - * Org ID - - * Signal Flow Program data(''tcp.packets'').publish(label=''A''); data(''tcp.bytes'').publish(label=''B''); data(''tcp.new_sockets'').publish(label=''C''); data(''udp.packets'').publish(label=''D''); data(''udp.bytes'').publish(label=''E'') - * Metric Resolution 10000' known_false_positives: unknown references: @@ -61,9 +57,9 @@ tags: - Splunk Enterprise Security - Splunk Cloud required_fields: - - k8s.cluster.name - - source.workload.name - - dest.workload.name + - k8s.cluster.name + - source.workload.name + - dest.workload.name - tcp.packets risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_newly_seen_udp_edge.yml b/detections/cloud/kubernetes_newly_seen_udp_edge.yml index e6803b5f4b..a264bff40e 100644 --- a/detections/cloud/kubernetes_newly_seen_udp_edge.yml +++ b/detections/cloud/kubernetes_newly_seen_udp_edge.yml @@ -1,19 +1,19 @@ name: Kubernetes newly seen UDP edge id: 49b7daca-4e3c-4899-ba15-9a175e056fa9 -version: 1 -date: '2024-01-10' +version: 2 +date: '2024-05-27' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: 'This analytic detects UDP communication between a newly seen source and destination workload pair. - This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring - metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). - This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. - Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. - Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. - Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, - or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, - putting the applications integrity, availability, and confidentiality at risk.' +description: 'The following analytic detects UDP communication between a newly seen + source and destination workload pair within a Kubernetes cluster. It leverages Network + Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk + Observability Cloud. This detection compares network activity over the last hour + with the past 30 days to identify new inter-workload communication. Such changes + in network behavior can indicate potential security threats or anomalies. If confirmed + malicious, unauthorized connections may enable attackers to infiltrate the application + ecosystem, leading to data breaches, privilege escalation, lateral movement, or + disruption of critical services.' data_source: [] search: '| mstats count(udp.packets) as udp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" @@ -24,7 +24,7 @@ search: '| mstats count(udp.packets) as udp.packets_count where `kubernetes_metr | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host - | `kubernetes_newly_seen_udp_edge_filter` ' + | `kubernetes_newly_seen_udp_edge_filter`' how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup @@ -34,10 +34,6 @@ how_to_implement: 'To gather NPM metrics the Open Telemetry to the Kubernetes Cl * Name sim_npm_metrics_to_metrics_index - * Org ID - - * Signal Flow Program data(''tcp.packets'').publish(label=''A''); data(''tcp.bytes'').publish(label=''B''); data(''tcp.new_sockets'').publish(label=''C''); data(''udp.packets'').publish(label=''D''); data(''udp.bytes'').publish(label=''E'') - * Metric Resolution 10000' known_false_positives: unknown references: @@ -61,9 +57,9 @@ tags: - Splunk Enterprise Security - Splunk Cloud required_fields: - - k8s.cluster.name - - source.workload.name - - dest.workload.name + - k8s.cluster.name + - source.workload.name + - dest.workload.name - udp.packets risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_node_port_creation.yml b/detections/cloud/kubernetes_node_port_creation.yml index 46689f2eda..513e043486 100644 --- a/detections/cloud/kubernetes_node_port_creation.yml +++ b/detections/cloud/kubernetes_node_port_creation.yml @@ -1,22 +1,25 @@ name: Kubernetes Node Port Creation id: d7fc865e-b8a1-4029-a960-cf4403b821b6 -version: 1 -date: '2023-12-13' +version: 2 +date: '2024-05-12' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of a Kubernetes node port service, an action that exposes a service to the external network. - It identifies this behavior by monitoring Kubernetes Audit logs for creation of a Node Port service. - This behavior is worth identifying for a SOC as it could potentially allow an attacker to access internal services, posing a significant threat to the integrity and security of the Kubernetes infrastructure. - The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. -data_source: +description: The following analytic detects the creation of a Kubernetes NodePort + service, which exposes a service to the external network. It identifies this activity + by monitoring Kubernetes Audit logs for the creation of NodePort services. This + behavior is significant for a SOC as it could allow an attacker to access internal + services, posing a threat to the Kubernetes infrastructure's integrity and security. + If confirmed malicious, this activity could lead to data breaches, service disruptions, + or unauthorized access to sensitive information. +data_source: - Kubernetes Audit search: '`kube_audit` "objectRef.resource"=services verb=create requestObject.spec.type=NodePort | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.type responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_node_port_creation_filter` ' + | `kubernetes_node_port_creation_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -48,23 +51,24 @@ tags: - Splunk Cloud required_fields: - user.groups{} - - kind - - objectRef.name - - objectRef.namespace - - objectRef.resource - - requestObject.kind - - requestObject.spec.type - - responseStatus.code - - sourceIPs{} - - stage - - user.username - - userAgent + - kind + - objectRef.name + - objectRef.namespace + - objectRef.resource + - requestObject.kind + - requestObject.spec.type + - responseStatus.code + - sourceIPs{} + - stage + - user.username + - userAgent - verb risk_score: 49 security_domain: network tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kube_audit_create_node_port_service/kube_audit_create_node_port_service.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kube_audit_create_node_port_service/kube_audit_create_node_port_service.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_pod_created_in_default_namespace.yml b/detections/cloud/kubernetes_pod_created_in_default_namespace.yml index 563b602178..c5b94b6782 100644 --- a/detections/cloud/kubernetes_pod_created_in_default_namespace.yml +++ b/detections/cloud/kubernetes_pod_created_in_default_namespace.yml @@ -1,22 +1,24 @@ name: Kubernetes Pod Created in Default Namespace id: 3d6b1a81-367b-42d5-a925-6ef90b6b9f1e -version: 1 -date: '2023-12-19' +version: 2 +date: '2024-05-12' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of pods in the default, kube-system, or kube-public namespaces. - It identifies this behavior by monitoring Kubernetes audit logs for pod creation events in these namespaces. - This behavior is worth identifying for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. - Only administrators should typically create pods in the kube-system namespace, and the default and kube-public namespaces should not be used in production. - The impact of the attack could be significant, as it may indicate a successful cluster breach and ongoing malicious activity. -data_source: +description: The following analytic detects the creation of Kubernetes pods in the + default, kube-system, or kube-public namespaces. It leverages Kubernetes audit logs + to identify pod creation events within these specific namespaces. This activity + is significant for a SOC as it may indicate an attacker attempting to hide their + presence or evade defenses. Unauthorized pod creation in these namespaces can suggest + a successful cluster breach, potentially leading to privilege escalation, persistent + access, or further malicious activities within the cluster. +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=pods verb=create objectRef.namespace IN ("default", "kube-system", "kube-public") | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_pod_created_in_default_namespace_filter` ' + | `kubernetes_pod_created_in_default_namespace_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_pod_with_host_network_attachment.yml b/detections/cloud/kubernetes_pod_with_host_network_attachment.yml index ba69d98485..763299bf0c 100644 --- a/detections/cloud/kubernetes_pod_with_host_network_attachment.yml +++ b/detections/cloud/kubernetes_pod_with_host_network_attachment.yml @@ -1,21 +1,25 @@ name: Kubernetes Pod With Host Network Attachment id: cce357cf-43a4-494a-814b-67cea90fe990 -version: 1 -date: '2023-12-14' +version: 2 +date: '2024-05-19' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: The following analytic detects the creation of a pod with host network attachment in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation or update of pods with host network configuration. - This behavior is worth identifying for a SOC as it could potentially allow an attacker to listen to all network traffic on the node and other compute on the network namespace, capturing secrets passed in arguments or connections to escalate their privileges. - The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. -data_source: +description: The following analytic detects the creation or update of a Kubernetes + pod with host network attachment. It leverages Kubernetes Audit logs to identify + pods configured with host network settings. This activity is significant for a SOC + as it could allow an attacker to monitor all network traffic on the node, potentially + capturing sensitive information and escalating privileges. If confirmed malicious, + this could lead to unauthorized access, data breaches, and service disruptions, + severely impacting the security and integrity of the Kubernetes environment. +data_source: - Kubernetes Audit search: '`kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"hostNetwork\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_pod_with_host_network_attachment_filter` ' + | `kubernetes_pod_with_host_network_attachment_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -47,17 +51,17 @@ tags: - Splunk Cloud required_fields: - user.groups{} - - kind - - objectRef.name - - objectRef.namespace - - objectRef.resource - - requestObject.kind - - requestObject.spec.type - - responseStatus.code - - sourceIPs{} - - stage - - user.username - - userAgent + - kind + - objectRef.name + - objectRef.namespace + - objectRef.resource + - requestObject.kind + - requestObject.spec.type + - responseStatus.code + - sourceIPs{} + - stage + - user.username + - userAgent - verb - requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration risk_score: 49 @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_privileged_pod/kubernetes_privileged_pod.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_previously_unseen_container_image_name.yml b/detections/cloud/kubernetes_previously_unseen_container_image_name.yml index 32e877c37e..893fa07fce 100644 --- a/detections/cloud/kubernetes_previously_unseen_container_image_name.yml +++ b/detections/cloud/kubernetes_previously_unseen_container_image_name.yml @@ -1,20 +1,19 @@ name: Kubernetes Previously Unseen Container Image Name id: fea515a4-b1d8-4cd6-80d6-e0d71397b891 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-27' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: The following analytic identifies containerised workloads that have been created using a previously unseen image. - This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). - This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. - When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. - Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. - The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. - The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, - or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. - A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. - Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster +description: The following analytic identifies the creation of containerized workloads + using previously unseen images in a Kubernetes cluster. It leverages process metrics + from an OTEL collector and Kubernetes cluster receiver, pulled from Splunk Observability + Cloud. The detection compares container image names seen in the last hour with those + from the previous 30 days. This activity is significant as unfamiliar container + images may introduce vulnerabilities, malware, or misconfigurations, posing threats + to the cluster's integrity. If confirmed malicious, compromised images can lead + to data breaches, service disruptions, unauthorized access, and potential lateral + movement within the cluster. data_source: [] search: '| mstats count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-24h by host.name k8s.cluster.name k8s.node.name container.image.name | eval current="True" @@ -24,29 +23,37 @@ search: '| mstats count(k8s.container.ready) as k8s.container.ready_count where | stats values(current) as current by host.name k8s.cluster.name k8s.node.name container.image.name | search current="true" AND current!="false" | rename host.name as host - | `kubernetes_previously_unseen_container_image_name_filter` ' + | `kubernetes_previously_unseen_container_image_name_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -71,8 +78,8 @@ tags: - Splunk Cloud required_fields: - k8s.container.ready_count - - host.name - - k8s.cluster.name - - k8s.node.name + - host.name + - k8s.cluster.name + - k8s.node.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_previously_unseen_process.yml b/detections/cloud/kubernetes_previously_unseen_process.yml index 54054fa546..605ca069bb 100644 --- a/detections/cloud/kubernetes_previously_unseen_process.yml +++ b/detections/cloud/kubernetes_previously_unseen_process.yml @@ -1,19 +1,19 @@ name: Kubernetes Previously Unseen Process id: c8119b2f-d7f7-40be-940a-1c582870e8e2 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-13' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an - OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). - This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. - The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and - anomalies that could be related to unauthorized activity. New processes may be introduced in an attempt to compromise the node or gain control of the Kubernetes cluster. - By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, - gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, - denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk. - The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity. +description: The following analytic detects previously unseen processes within the + Kubernetes environment on master or worker nodes. It leverages process metrics collected + via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability + Cloud. This detection compares processes observed in the last hour against those + seen in the previous 30 days. Identifying new processes is crucial as they may indicate + unauthorized activity or attempts to compromise the node. If confirmed malicious, + these processes could lead to data exfiltration, privilege escalation, denial-of-service + attacks, or the introduction of malware, posing significant risks to the Kubernetes + cluster. data_source: [] search: '| mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name | eval current="True" @@ -22,29 +22,37 @@ search: '| mstats count(process.memory.utilization) as process.memory.utilizati | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.executable.name | where count=1 and current="True" | rename host.name as host - | `kubernetes_previously_unseen_process_filter` ' + | `kubernetes_previously_unseen_process_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -69,9 +77,9 @@ tags: - Splunk Cloud required_fields: - process.memory.utilization - - host.name - - k8s.cluster.name - - k8s.node.name + - host.name + - k8s.cluster.name + - k8s.node.name - process.executable.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_process_running_from_new_path.yml b/detections/cloud/kubernetes_process_running_from_new_path.yml index 2c93736f1d..41b969d36b 100644 --- a/detections/cloud/kubernetes_process_running_from_new_path.yml +++ b/detections/cloud/kubernetes_process_running_from_new_path.yml @@ -1,19 +1,19 @@ name: Kubernetes Process Running From New Path id: 454076fb-0e9e-4adf-b93a-da132621c5e6 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-27' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. - This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud - using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for - each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. - The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. - A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software. - If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. - It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. - This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster. +description: The following analytic identifies processes running from newly seen paths + within a Kubernetes environment. It leverages process metrics collected via an OTEL + collector and hostmetrics receiver, and data is pulled from Splunk Observability + Cloud using the Splunk Infrastructure Monitoring Add-on. This detection compares + processes observed in the last hour with those seen over the previous 30 days. This + activity is significant as it may indicate unauthorized changes, compromised nodes, + or the introduction of malicious software. If confirmed malicious, it could lead + to unauthorized process execution, control over critical resources, data exfiltration, + privilege escalation, or malware introduction within the Kubernetes cluster. data_source: [] search: '| mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name | eval current="True" @@ -23,29 +23,37 @@ search: '| mstats count(process.memory.utilization) as process.memory.utilizatio | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name process.executable.path | where count=1 and current="True" | rename host.name as host - | `kubernetes_process_running_from_new_path_filter` ' + | `kubernetes_process_running_from_new_path_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -70,9 +78,9 @@ tags: - Splunk Cloud required_fields: - process.memory.utilization - - host.name - - k8s.cluster.name - - k8s.node.name + - host.name + - k8s.cluster.name + - k8s.node.name - process.executable.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_process_with_anomalous_resource_utilisation.yml b/detections/cloud/kubernetes_process_with_anomalous_resource_utilisation.yml index f0ecb0c57e..44d9d3dce9 100644 --- a/detections/cloud/kubernetes_process_with_anomalous_resource_utilisation.yml +++ b/detections/cloud/kubernetes_process_with_anomalous_resource_utilisation.yml @@ -1,14 +1,18 @@ name: Kubernetes Process with Anomalous Resource Utilisation id: 25ca9594-7a0d-4a95-a5e5-3228d7398ec8 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-27' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, - fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values - for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, - or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. +description: The following analytic identifies high resource utilization anomalies + in Kubernetes processes. It leverages process metrics from an OTEL collector and + hostmetrics receiver, fetched via the Splunk Infrastructure Monitoring Add-on. The + detection uses a lookup table with average and standard deviation values to spot + anomalies. This activity is significant as high resource utilization can indicate + security threats like cryptojacking, unauthorized data exfiltration, or compromised + containers. If confirmed malicious, such anomalies can disrupt services, exhaust + resources, increase costs, and allow attackers to evade detection or maintain access. data_source: [] search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name'' @@ -27,29 +31,37 @@ search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host | sort - count | where count > 5 | rename host.name as host - | `kubernetes_process_with_anomalous_resource_utilisation_filter` ' + | `kubernetes_process_with_anomalous_resource_utilisation_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -74,9 +86,9 @@ tags: - Splunk Cloud required_fields: - process.* - - host.name - - k8s.cluster.name - - k8s.node.name + - host.name + - k8s.cluster.name + - k8s.node.name - process.executable.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_process_with_resource_ratio_anomalies.yml b/detections/cloud/kubernetes_process_with_resource_ratio_anomalies.yml index fb50b5b397..870ba66146 100644 --- a/detections/cloud/kubernetes_process_with_resource_ratio_anomalies.yml +++ b/detections/cloud/kubernetes_process_with_resource_ratio_anomalies.yml @@ -1,62 +1,66 @@ name: Kubernetes Process with Resource Ratio Anomalies id: 0d42b295-0f1f-4183-b75e-377975f47c65 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-30' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node. - This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). - This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios. - This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load. - Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. - Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. - A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container. +description: The following analytic detects anomalous changes in resource utilization + ratios for processes running on a Kubernetes node. It leverages process metrics + collected via an OTEL collector and hostmetrics receiver, analyzed through Splunk + Observability Cloud. The detection uses a lookup table containing average and standard + deviation values for various resource ratios (e.g., CPU:memory, CPU:disk operations). + Significant deviations from these baselines may indicate compromised processes, + malicious activity, or misconfigurations. If confirmed malicious, this could signify + a security breach, allowing attackers to manipulate workloads, potentially leading + to data exfiltration or service disruption. data_source: [] -search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s - | eval cpu:mem = ''process.cpu.utilization''/''process.memory.utilization'' - | eval cpu:disk = ''process.cpu.utilization''/''process.disk.operations'' - | eval mem:disk = ''process.memory.utilization''/''process.disk.operations'' - | eval cpu:threads = ''process.cpu.utilization''/''process.threads'' - | eval disk:threads = ''process.disk.operations''/''process.threads'' - | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name'' - | lookup k8s_process_resource_ratio_baseline key - | fillnull - | eval anomalies = "" - | foreach stdev_* - [ eval anomalies =if( ''<>'' > (''avg_<>'' + 4 * ''stdev_<>''), anomalies + "<> ratio higher than average by " + - tostring(round((''<>'' - ''avg_<>'')/''stdev_<>'' ,2)) + " Standard Deviations. <>=" + tostring(''<>'') + " avg_<>=" - + tostring(''avg_<>'') + " ''stdev_<>''=" + tostring(''stdev_<>'') + ", " - , anomalies) - ] - | eval anomalies = replace(anomalies, ",\s$", "") - | where anomalies!="" - | stats count values(anomalies) as anomalies by host.name k8s.cluster.name k8s.node.name process.executable.name - | where count > 5 - | rename host.name as host +search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name + k8s.cluster.name k8s.node.name process.executable.name span=10s | eval cpu:mem = + ''process.cpu.utilization''/''process.memory.utilization'' | eval cpu:disk = ''process.cpu.utilization''/''process.disk.operations'' + | eval mem:disk = ''process.memory.utilization''/''process.disk.operations'' | eval + cpu:threads = ''process.cpu.utilization''/''process.threads'' | eval disk:threads + = ''process.disk.operations''/''process.threads'' | eval key = ''k8s.cluster.name'' + + ":" + ''host.name'' + ":" + ''process.executable.name'' | lookup k8s_process_resource_ratio_baseline + key | fillnull | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( ''<>'' + > (''avg_<>'' + 4 * ''stdev_<>''), anomalies + "<> + ratio higher than average by " + tostring(round((''<>'' - ''avg_<>'')/''stdev_<>'' + ,2)) + " Standard Deviations. <>=" + tostring(''<>'') + " avg_<>=" + + tostring(''avg_<>'') + " ''stdev_<>''=" + tostring(''stdev_<>'') + + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$", "") | where + anomalies!="" | stats count values(anomalies) as anomalies by host.name k8s.cluster.name + k8s.node.name process.executable.name | where count > 5 | rename host.name as host | `kubernetes_process_with_resource_ratio_anomalies_filter`' -how_to_implement: 'To implement this detection, follow these steps: - +how_to_implement: 'To implement this detection, follow these steps: + * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: @@ -81,9 +85,9 @@ tags: - Splunk Cloud required_fields: - process.* - - host.name - - k8s.cluster.name - - k8s.node.name + - host.name + - k8s.cluster.name + - k8s.node.name - process.executable.name risk_score: 25 security_domain: network diff --git a/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml b/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml index 47e8d49802..a94b5cf3fe 100644 --- a/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml +++ b/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml @@ -1,15 +1,19 @@ name: Kubernetes Scanning by Unauthenticated IP Address id: f9cadf4e-df22-4f4e-a08f-9d3344c2165d -version: 1 -date: '2023-12-07' +version: 2 +date: '2024-05-10' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: This detection rule is designed to identify potential scanning activities within a Kubernetes environment. - Scanning is a common preliminary step in an attack, where the attacker tries to gather information about the system to find potential vulnerabilities. - In the context of Kubernetes, scanning could involve activities like unauthorized access attempts, probing public APIs, or trying to exploit known vulnerabilities. - This rule triggers an alert when such suspicious activities are detected, helping to ensure the security of your Kubernetes infrastructure. -data_source: +description: The following analytic identifies potential scanning activities within + a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes + audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) + from the same source IP. This activity is significant as it may indicate an attacker + probing for vulnerabilities or attempting to exploit known issues. If confirmed + malicious, such scanning could lead to unauthorized access, data breaches, or further + exploitation of the Kubernetes infrastructure, compromising the security and integrity + of the environment. +data_source: - Kubernetes Audit search: '`kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} @@ -17,7 +21,7 @@ search: '`kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.c by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_scanning_by_unauthenticated_ip_address_filter` ' + | `kubernetes_scanning_by_unauthenticated_ip_address_filter`' how_to_implement: You must ingest Kubernetes audit logs. known_false_positives: unknown references: @@ -28,7 +32,7 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Kubernetes scanning from ip $src_ip$ + message: Kubernetes scanning from ip $src_ip$ mitre_attack_id: - T1046 observable: @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1046/kubernetes_scanning/kubernetes_scanning.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1046/kubernetes_scanning/kubernetes_scanning.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_shell_running_on_worker_node.yml b/detections/cloud/kubernetes_shell_running_on_worker_node.yml index fbf7b3d8f6..53ba59cfd2 100644 --- a/detections/cloud/kubernetes_shell_running_on_worker_node.yml +++ b/detections/cloud/kubernetes_shell_running_on_worker_node.yml @@ -1,45 +1,56 @@ name: Kubernetes Shell Running on Worker Node id: efebf0c4-dcf4-496f-85a2-5ab7ad8fa876 -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-25' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. - It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. - Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. - Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation. - Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. - It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data. +description: The following analytic identifies shell activity within the Kubernetes + privilege scope on a worker node. It leverages process metrics from an OTEL collector + hostmetrics receiver, specifically process.cpu.utilization and process.memory.utilization, + pulled from Splunk Observability Cloud. This activity is significant as unauthorized + shell processes can indicate potential security threats, providing attackers an + entry point to compromise the node and the entire Kubernetes cluster. If confirmed + malicious, this activity could lead to data theft, service disruption, privilege + escalation, lateral movement, and further attacks, severely compromising the cluster's + security and integrity. data_source: [] search: '| mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 OR process.memory.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host - | `kubernetes_shell_running_on_worker_node_filter` ' + | `kubernetes_shell_running_on_worker_node_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: diff --git a/detections/cloud/kubernetes_shell_running_on_worker_node_with_cpu_activity.yml b/detections/cloud/kubernetes_shell_running_on_worker_node_with_cpu_activity.yml index c9711414db..7440e985c8 100644 --- a/detections/cloud/kubernetes_shell_running_on_worker_node_with_cpu_activity.yml +++ b/detections/cloud/kubernetes_shell_running_on_worker_node_with_cpu_activity.yml @@ -1,47 +1,57 @@ name: Kubernetes Shell Running on Worker Node with CPU Activity id: cc1448e3-cc7a-4518-bc9f-2fa48f61a22b -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-11' author: Matthew Moore, Splunk status: experimental type: Anomaly -description: This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. - The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. - The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. - Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, - policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. - Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, - privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, - severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach. +description: The following analytic identifies shell activity within the Kubernetes + privilege scope on a worker node, specifically when shell processes are consuming + CPU resources. It leverages process metrics from an OTEL collector hostmetrics receiver, + pulled from Splunk Observability Cloud via the Splunk Infrastructure Monitoring + Add-on, focusing on process.cpu.utilization and process.memory.utilization. This + activity is significant as unauthorized shell processes can indicate a security + threat, potentially compromising the node and the entire Kubernetes cluster. If + confirmed malicious, attackers could gain full control over the host's resources, + leading to data theft, service disruption, privilege escalation, and further attacks + within the cluster. data_source: [] search: '| mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host - | `kubernetes_shell_running_on_worker_node_with_cpu_activity_filter` ' + | `kubernetes_shell_running_on_worker_node_with_cpu_activity_filter`' how_to_implement: 'To implement this detection, follow these steps: * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. - + * Enable the hostmetrics/process receiver in the OTEL configuration. - - * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled. - + + * Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, + are enabled. + * Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247) - - * Configure the SIM add-on with your Observability Cloud Organization ID and Access Token. - + + * Configure the SIM add-on with your Observability Cloud Organization ID and Access + Token. + * Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index". - - * In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID. - - * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') - + + * In the SIM configuration, set the Organization ID to your Observability Cloud + Organization ID. + + * Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); + data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); + data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); + data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); + data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); + data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'') + * Set the Metric Resolution to 10000. - + * Leave all other settings at their default values. - + * Run the Search Baseline Of Kubernetes Container Network IO Ratio ' known_false_positives: unknown references: diff --git a/detections/cloud/kubernetes_suspicious_image_pulling.yml b/detections/cloud/kubernetes_suspicious_image_pulling.yml index 0a00025f0f..4eeaa70812 100644 --- a/detections/cloud/kubernetes_suspicious_image_pulling.yml +++ b/detections/cloud/kubernetes_suspicious_image_pulling.yml @@ -1,15 +1,18 @@ name: Kubernetes Suspicious Image Pulling id: 4d3a17b3-0a6d-4ae0-9421-46623a69c122 -version: 1 -date: '2023-12-07' +version: 2 +date: '2024-05-13' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects instances of suspicious image pulling in Kubernetes. - It identifies this behavior by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. - This behavior is worth identifying for a SOC as it could indicate an attacker attempting to deploy malicious software or infiltrate the system. - The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects suspicious image pulling in Kubernetes + environments. It identifies this activity by monitoring Kubernetes audit logs for + image pull requests that do not match a predefined list of allowed images. This + behavior is significant for a SOC as it may indicate an attacker attempting to deploy + malicious software or infiltrate the system. If confirmed malicious, the impact + could be severe, potentially leading to unauthorized access to sensitive systems + or data, and enabling further malicious activities within the cluster.' +data_source: - Kubernetes Audit search: '`kube_audit` requestObject.message="Pulling image*" | search NOT `kube_allowed_images` @@ -17,7 +20,7 @@ search: '`kube_audit` requestObject.message="Pulling image*" | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_suspicious_image_pulling_filter` ' + | `kubernetes_suspicious_image_pulling_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -31,7 +34,8 @@ tags: asset_type: Kubernetes confidence: 70 impact: 70 - message: Suspicious image $objectRef.name$ pulled in Kubernetes from ip $src_ip$ by user $user$ + message: Suspicious image $objectRef.name$ pulled in Kubernetes from ip $src_ip$ + by user $user$ mitre_attack_id: - T1526 observable: @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1526/kubernetes_audit_pull_image/kubernetes_audit_pull_image.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1526/kubernetes_audit_pull_image/kubernetes_audit_pull_image.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/kubernetes_unauthorized_access.yml b/detections/cloud/kubernetes_unauthorized_access.yml index 019e41d47c..893a445494 100644 --- a/detections/cloud/kubernetes_unauthorized_access.yml +++ b/detections/cloud/kubernetes_unauthorized_access.yml @@ -1,21 +1,25 @@ name: Kubernetes Unauthorized Access id: 9b5f1832-e8b9-453f-93df-07a3d6a72a45 -version: 1 -date: '2023-12-07' +version: 2 +date: '2024-05-21' author: Patrick Bareiss, Splunk status: production type: Anomaly -description: 'The following analytic detects unauthorized access to Kubernetes by monitoring Kubernetes audit logs. - It identifies anomalies in access patterns by segmenting and analyzing the source of requests. Unauthorized access is worth identifying for a SOC as it could indicate - an attacker attempting to infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.' -data_source: +description: 'The following analytic detects unauthorized access attempts to Kubernetes + by analyzing Kubernetes audit logs. It identifies anomalies in access patterns by + examining the source of requests and their response statuses. This activity is significant + for a SOC as it may indicate an attacker attempting to infiltrate the Kubernetes + environment. If confirmed malicious, such access could lead to unauthorized control + over Kubernetes resources, potentially compromising sensitive systems or data within + the cluster.' +data_source: - Kubernetes Audit search: '`kube_audit` verb=create responseStatus.reason=Forbidden | fillnull | stats count by objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code responseStatus.message sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user - | `kubernetes_unauthorized_access_filter` ' + | `kubernetes_unauthorized_access_filter`' how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. @@ -62,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_unauthorized_access/kubernetes_unauthorized_access.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/kubernetes_unauthorized_access/kubernetes_unauthorized_access.json sourcetype: _json source: kubernetes diff --git a/detections/cloud/o365_add_app_role_assignment_grant_user.yml b/detections/cloud/o365_add_app_role_assignment_grant_user.yml index dc90c09b86..bfa016ef7e 100644 --- a/detections/cloud/o365_add_app_role_assignment_grant_user.yml +++ b/detections/cloud/o365_add_app_role_assignment_grant_user.yml @@ -1,21 +1,24 @@ name: O365 Add App Role Assignment Grant User id: b2c81cc6-6040-11eb-ae93-0242ac130002 -version: 2 -date: '2023-07-11' +version: 3 +date: '2024-05-19' author: Rod Soto, Splunk status: production type: TTP -description: This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. - By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. - This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, - providing an additional layer of security for your environment. -data_source: +description: The following analytic detects the addition of an application role assignment + grant to a user in Office 365. It leverages data from the `o365_management_activity` + dataset, specifically monitoring the "Add app role assignment grant to user" operation. + This activity is significant as it can indicate unauthorized privilege escalation + or the assignment of sensitive roles to users. If confirmed malicious, this could + allow an attacker to gain elevated permissions, potentially leading to unauthorized + access to critical resources and data within the Office 365 environment. +data_source: - O365 Add app role assignment grant to user. -search: '`o365_management_activity` Workload=AzureActiveDirectory Operation="Add app role assignment grant to user." - | stats count min(_time) as firstTime max(_time) as lastTime values(Actor{}.ID) as Actor.ID values(Actor{}.Type) as Actor.Type values(ModifiedProperties{}.Name) as modified_properties_name by user dest ResultStatus Operation - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_add_app_role_assignment_grant_user_filter`' +search: '`o365_management_activity` Workload=AzureActiveDirectory Operation="Add app + role assignment grant to user." | stats count min(_time) as firstTime max(_time) + as lastTime values(Actor{}.ID) as Actor.ID values(Actor{}.Type) as Actor.Type values(ModifiedProperties{}.Name) + as modified_properties_name by user dest ResultStatus Operation | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `o365_add_app_role_assignment_grant_user_filter`' how_to_implement: You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity known_false_positives: The creation of a new Federation is not necessarily malicious, @@ -31,7 +34,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 30 - message: User $user$ has created a new federation setting $modified_properties_name$ on $dest$ + message: User $user$ has created a new federation setting $modified_properties_name$ + on $dest$ mitre_attack_id: - T1136.003 - T1136 @@ -62,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_new_federation/o365_new_federation.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_new_federation/o365_new_federation.json sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_added_service_principal.yml b/detections/cloud/o365_added_service_principal.yml index a7cd2c3de4..751bf096e0 100644 --- a/detections/cloud/o365_added_service_principal.yml +++ b/detections/cloud/o365_added_service_principal.yml @@ -1,16 +1,25 @@ name: O365 Added Service Principal id: 1668812a-6047-11eb-ae93-0242ac130002 -version: 3 -date: '2023-08-02' +version: 4 +date: '2024-05-27' author: Rod Soto, Splunk status: production type: TTP -description: The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization. -data_source: -- O365 -search: '`o365_management_activity` Workload=AzureActiveDirectory Operation="*Add service principal*" OR (Operation = "*principal*" AND action = "created") - | stats count values(ModifiedProperties{}.NewValue) as new_value by src_user src_user_type action Operation authentication_service Workload - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_added_service_principal_filter`' +description: The following analytic detects the addition of new service principal + accounts in O365 tenants. It leverages data from the `o365_management_activity` + dataset, specifically monitoring for operations related to adding or creating service + principals. This activity is significant because attackers can exploit service principals + to gain unauthorized access and perform malicious actions within an organization's + environment. If confirmed malicious, this could allow attackers to interact with + APIs, access resources, and execute operations on behalf of the organization, potentially + leading to data breaches or further compromise. +data_source: +- O365 +search: '`o365_management_activity` Workload=AzureActiveDirectory Operation="*Add + service principal*" OR (Operation = "*principal*" AND action = "created") | stats + count values(ModifiedProperties{}.NewValue) as new_value by src_user src_user_type + action Operation authentication_service Workload | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `o365_added_service_principal_filter`' how_to_implement: You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity known_false_positives: The creation of a new Federation is not necessarily malicious, @@ -46,16 +55,17 @@ tags: - _time - Workload - signature - - src_user - - src_user_type - - action - - Operation + - src_user + - src_user_type + - action + - Operation - authentication_service risk_score: 42 security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_added_service_principal/o365_add_service_principal.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_added_service_principal/o365_add_service_principal.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_admin_consent_bypassed_by_service_principal.yml b/detections/cloud/o365_admin_consent_bypassed_by_service_principal.yml index a2ac104a0b..01cee46fbe 100644 --- a/detections/cloud/o365_admin_consent_bypassed_by_service_principal.yml +++ b/detections/cloud/o365_admin_consent_bypassed_by_service_principal.yml @@ -1,15 +1,23 @@ name: O365 Admin Consent Bypassed by Service Principal id: 8a1b22eb-50ce-4e26-a691-97ff52349569 -version: 1 -date: '2024-02-09' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Splunk -data_source: +data_source: - O365 Add app role assignment to service principal. type: TTP status: production -description: This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions. +description: The following analytic identifies instances where a service principal + in Office 365 Azure Active Directory assigns app roles without standard admin consent. + It leverages `o365_management_activity` logs, specifically focusing on the 'Add + app role assignment to service principal' operation. This activity is significant + for SOCs as it may indicate a bypass of critical administrative controls, potentially + leading to unauthorized access or privilege escalation. If confirmed malicious, + this could allow an attacker to misuse automated processes to assign sensitive permissions, + compromising the security of the environment. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Add app role assignment to service principal." + `o365_management_activity` Workload=AzureActiveDirectory Operation="Add app role + assignment to service principal." | eval len=mvcount('Actor{}.ID') | eval userType = mvindex('Actor{}.ID',len-1) | eval roleId = mvindex('ModifiedProperties{}.NewValue', 0) @@ -18,12 +26,14 @@ search: >- | eval dest_user = mvindex('Target{}.ID', 0) | search userType = "ServicePrincipal" | eval src_user = user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by src_user dest_user roleId roleValue roleDescription + | stats count earliest(_time) as firstTime latest(_time) as lastTime by src_user + dest_user roleId roleValue roleDescription | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_admin_consent_bypassed_by_service_principal_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. + | `security_content_ctime(lastTime)` | `o365_admin_consent_bypassed_by_service_principal_filter` +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Service Principals are sometimes configured to legitimately + bypass the consent process for purposes of automation. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ - https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/ @@ -37,7 +47,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 90 - message: Service principal $src_user$ bypassed the admin consent process and granted permissions to $dest_user$ + message: Service principal $src_user$ bypassed the admin consent process and granted + permissions to $dest_user$ mitre_attack_id: - T1098.003 observable: @@ -62,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_bypass_admin_consent/o365_bypass_admin_consent.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_bypass_admin_consent/o365_bypass_admin_consent.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_advanced_audit_disabled.yml b/detections/cloud/o365_advanced_audit_disabled.yml index 9e27b9325e..196993ba67 100644 --- a/detections/cloud/o365_advanced_audit_disabled.yml +++ b/detections/cloud/o365_advanced_audit_disabled.yml @@ -1,28 +1,37 @@ name: O365 Advanced Audit Disabled id: 49862dd4-9cb2-4c48-a542-8c8a588d9361 -version: 1 -date: '2023-09-19' +version: 2 +date: '2024-05-17' author: Mauricio Velazco, Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - O365 Change user license. -description: The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail. +description: The following analytic detects instances where the O365 advanced audit + is disabled for a specific user within the Office 365 tenant. It uses O365 audit + logs, focusing on events related to audit license changes in AzureActiveDirectory + workloads. This activity is significant because the O365 advanced audit provides + critical logging and insights into user and administrator activities. Disabling + it can blind security teams to potential malicious actions. If confirmed malicious, + attackers could operate within the user's mailbox or account with reduced risk of + detection, leading to unauthorized data access, data exfiltration, or account compromise. search: >- - `o365_management_activity` Operation="Change user license." - | eval property_name = mvindex ('ExtendedProperties{}.Name', 1) + `o365_management_activity` Operation="Change user license." | eval property_name + = mvindex ('ExtendedProperties{}.Name', 1) | search property_name = "extendedAuditEventCategory" | eval additionalDetails = mvindex('ExtendedProperties{}.Value',0) | eval split_value=split(additionalDetails, "NewValue") - | eval possible_plan=mvindex(split_value, 1) - | rex field="possible_plan" "DisabledPlans=\[(?P[^\]]+)\]" + | eval possible_plan=mvindex(split_value, 1) | rex field="possible_plan" "DisabledPlans=\[(?P[^\]]+)\]" | search DisabledPlans IN ("*M365_ADVANCED_AUDITING*") - | stats min(_time) as firstTime max(_time) as lastTime by Operation user object DisabledPlans - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | stats min(_time) as firstTime max(_time) as lastTime by Operation user object + DisabledPlans + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_advanced_audit_disabled_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Administrators might temporarily disable the advanced audit for troubleshooting, performance reasons, or other administrative tasks. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Administrators might temporarily disable the advanced audit + for troubleshooting, performance reasons, or other administrative tasks. Filter + as needed. references: - https://attack.mitre.org/techniques/T1562/008/ - https://www.mandiant.com/sites/default/files/2022-08/remediation-hardening-strategies-for-m365-defend-against-apt29-white-paper.pdf @@ -58,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/o365_advanced_audit_disabled/o365_advanced_audit_disabled.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/o365_advanced_audit_disabled/o365_advanced_audit_disabled.log source: o365 - sourcetype: o365:management:activity \ No newline at end of file + sourcetype: o365:management:activity diff --git a/detections/cloud/o365_application_registration_owner_added.yml b/detections/cloud/o365_application_registration_owner_added.yml index 866e283742..732e63150c 100644 --- a/detections/cloud/o365_application_registration_owner_added.yml +++ b/detections/cloud/o365_application_registration_owner_added.yml @@ -1,22 +1,34 @@ name: O365 Application Registration Owner Added id: c068d53f-6aaa-4558-8011-3734df878266 -version: 1 -date: '2023-09-07' +version: 2 +date: '2024-05-11' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Add owner to application. -description: The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations +description: The following analytic identifies instances where a new owner is assigned + to an application registration within an Azure AD and Office 365 tenant. It leverages + O365 audit logs, specifically events related to changes in owner assignments within + the AzureActiveDirectory workload. This activity is significant because assigning + a new owner to an application registration can grant significant control over the + application's configuration, permissions, and behavior. If confirmed malicious, + an attacker could modify the application's settings, permissions, and behavior, + leading to unauthorized data access, privilege escalation, or the introduction of + malicious behavior within the application's operations. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Add owner to application." + `o365_management_activity` Workload=AzureActiveDirectory Operation="Add owner to + application." | eval app_id=mvindex('ModifiedProperties{}.NewValue', 0) | eval app_displayName=mvindex('ModifiedProperties{}.NewValue', 1) - | stats max(_time) as lastTime values(ModifiedProperties{}.NewValue) by Operation, user, app_displayName, object + | stats max(_time) as lastTime values(ModifiedProperties{}.NewValue) by Operation, + user, app_displayName, object | `security_content_ctime(lastTime)` | `o365_application_registration_owner_added_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Application owners may be added for legitimate reasons, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Application owners may be added for legitimate reasons, filter + as needed. references: - https://attack.mitre.org/techniques/T1098/ - https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/overview-assign-app-owners @@ -51,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/o365_add_app_registration_owner/o365_add_app_registration_owner.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/o365_add_app_registration_owner/o365_add_app_registration_owner.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_applicationimpersonation_role_assigned.yml b/detections/cloud/o365_applicationimpersonation_role_assigned.yml index bafd096007..4fdc9c751e 100644 --- a/detections/cloud/o365_applicationimpersonation_role_assigned.yml +++ b/detections/cloud/o365_applicationimpersonation_role_assigned.yml @@ -1,20 +1,27 @@ name: O365 ApplicationImpersonation Role Assigned id: 49cdce75-f814-4d56-a7a4-c64ec3a481f2 -version: 1 -date: '2023-10-17' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 -description: The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization. +description: The following analytic detects the assignment of the ApplicationImpersonation + role in Office 365 to a user or application. It uses the Office 365 Management Activity + API to monitor Azure Active Directory audit logs for role assignment events. This + activity is significant because the ApplicationImpersonation role allows impersonation + of any user, enabling access to and modification of their mailbox. If confirmed + malicious, an attacker could gain unauthorized access to sensitive information, + manipulate mailbox data, and perform actions as a legitimate user, posing a severe + security risk to the organization. search: '`o365_management_activity` Workload=Exchange Operation="New-ManagementRoleAssignment" Role=ApplicationImpersonation - | rename User as target_user - | stats max(_time) as lastTime by Operation, user, object, ObjectId, Role, target_user - | `security_content_ctime(lastTime)` - | `o365_applicationimpersonation_role_assigned_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: While infrequent, the ApplicationImpersonation role may be granted for leigimate reasons, filter as needed. + | rename User as target_user | stats max(_time) as lastTime by Operation, user, + object, ObjectId, Role, target_user | `security_content_ctime(lastTime)` | `o365_applicationimpersonation_role_assigned_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: While infrequent, the ApplicationImpersonation role may be + granted for leigimate reasons, filter as needed. references: - https://attack.mitre.org/techniques/T1098/002/ - https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 @@ -58,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/application_impersonation_role_assigned/application_impersonation_role_assigned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/application_impersonation_role_assigned/application_impersonation_role_assigned.log source: O365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_block_user_consent_for_risky_apps_disabled.yml b/detections/cloud/o365_block_user_consent_for_risky_apps_disabled.yml index e0928565ad..447f87e2d5 100644 --- a/detections/cloud/o365_block_user_consent_for_risky_apps_disabled.yml +++ b/detections/cloud/o365_block_user_consent_for_risky_apps_disabled.yml @@ -1,25 +1,37 @@ name: O365 Block User Consent For Risky Apps Disabled id: 12a23592-e3da-4344-8545-205d3290647c -version: 1 -date: '2023-10-26' +version: 2 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Update authorization policy. -description: This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization. +description: The following analytic detects when the "risk-based step-up consent" + security setting in Microsoft 365 is disabled. It monitors Azure Active Directory + logs for the "Update authorization policy" operation, specifically changes to the + "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling + this feature can expose the organization to OAuth phishing threats, allowing users + to grant consent to malicious applications. If confirmed malicious, attackers could + gain unauthorized access to user data and sensitive information, leading to data + breaches and further compromise within the organization. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Update authorization policy." - | eval index_number = if(mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps") >= 0, mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps"), -1) - | search index_number >= 0 - | eval AllowUserConsentForRiskyApps = mvindex('ModifiedProperties{}.NewValue',index_number) + `o365_management_activity` Workload=AzureActiveDirectory Operation="Update authorization + policy." + | eval index_number = if(mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps") + >= 0, mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps"), -1) + | search index_number >= 0 | eval AllowUserConsentForRiskyApps = mvindex('ModifiedProperties{}.NewValue',index_number) | where AllowUserConsentForRiskyApps like "%true%" - | stats count min(_time) as firstTime max(_time) as lastTime by user, Operation, AllowUserConsentForRiskyApps, user_agent + | stats count min(_time) as firstTime max(_time) as lastTime by user, Operation, + AllowUserConsentForRiskyApps, user_agent | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_block_user_consent_for_risky_apps_disabled_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting + by administrators, perhaps as part of a policy update or security assessment, may + trigger this alert, necessitating verification of the change's intent and authorization. references: - https://attack.mitre.org/techniques/T1562/ - https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/ @@ -57,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/o365_disable_blockconsent_for_riskapps/o365_disable_blockconsent_for_riskapps.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/o365_disable_blockconsent_for_riskapps/o365_disable_blockconsent_for_riskapps.log source: O365 - sourcetype: o365:management:activity \ No newline at end of file + sourcetype: o365:management:activity diff --git a/detections/cloud/o365_bypass_mfa_via_trusted_ip.yml b/detections/cloud/o365_bypass_mfa_via_trusted_ip.yml index 5119d0f1d8..a33d96cb85 100644 --- a/detections/cloud/o365_bypass_mfa_via_trusted_ip.yml +++ b/detections/cloud/o365_bypass_mfa_via_trusted_ip.yml @@ -1,12 +1,20 @@ name: O365 Bypass MFA via Trusted IP id: c783dd98-c703-4252-9e8a-f19d9f66949e -version: 3 -date: '2022-02-03' +version: 4 +date: '2024-05-15' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications. -data_source: +description: The following analytic identifies instances where new IP addresses are + added to the trusted IPs list in Office 365, potentially allowing users from these + IPs to bypass Multi-Factor Authentication (MFA) during login. It leverages O365 + audit logs, specifically focusing on events related to the modification of trusted + IP settings. This activity is significant because adding trusted IPs can weaken + the security posture by bypassing MFA, which is a critical security control. If + confirmed malicious, this could lead to unauthorized access, compromising sensitive + information and systems. Immediate investigation is required to validate the legitimacy + of the IP addition. +data_source: - O365 Set Company Information. search: '`o365_management_activity` Operation="Set Company Information." ModifiedProperties{}.Name=StrongAuthenticationPolicy | rex max_match=100 field=ModifiedProperties{}.NewValue "(?\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\d{1,2})" @@ -65,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.007/o365_bypass_mfa_via_trusted_ip/o365_bypass_mfa_via_trusted_ip.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.007/o365_bypass_mfa_via_trusted_ip/o365_bypass_mfa_via_trusted_ip.json sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_compliance_content_search_exported.yml b/detections/cloud/o365_compliance_content_search_exported.yml index 94da773222..2103c7707a 100644 --- a/detections/cloud/o365_compliance_content_search_exported.yml +++ b/detections/cloud/o365_compliance_content_search_exported.yml @@ -1,19 +1,27 @@ name: O365 Compliance Content Search Exported id: 2ce9f31d-ab4f-4179-b2b7-c77a9652e1d8 -version: 1 -date: '2024-04-01' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations. +description: The following analytic identifies when the results of a content search + within the Office 365 Security and Compliance Center are exported. It uses the SearchExported + operation from the SecurityComplianceCenter workload in the o365_management_activity + data source. This activity is significant because exporting search results can involve + sensitive or critical organizational data, potentially leading to data exfiltration. + If confirmed malicious, an attacker could gain access to and exfiltrate sensitive + information, posing a severe risk to the organization's data security and compliance + posture. search: ' `o365_management_activity` Workload=SecurityComplianceCenter Operation="SearchExported" - | rename user_id as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, ObjectId, ExchangeLocations, user, Query |`security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` - | `o365_compliance_content_search_exported_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Compliance content searche exports may be executed for legitimate purposes, filter as needed. + | rename user_id as user | stats count earliest(_time) as firstTime latest(_time) + as lastTime by Operation, ObjectId, ExchangeLocations, user, Query |`security_content_ctime(firstTime)` + |`security_content_ctime(lastTime)` | `o365_compliance_content_search_exported_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Compliance content searche exports may be executed for legitimate + purposes, filter as needed. references: - https://attack.mitre.org/techniques/T1114/002/ - https://learn.microsoft.com/en-us/purview/ediscovery-content-search-overview @@ -51,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_compliance_content_search_exported/o365_compliance_content_search_exported.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_compliance_content_search_exported/o365_compliance_content_search_exported.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_compliance_content_search_started.yml b/detections/cloud/o365_compliance_content_search_started.yml index 0de0995ca2..28eeaca71b 100644 --- a/detections/cloud/o365_compliance_content_search_started.yml +++ b/detections/cloud/o365_compliance_content_search_started.yml @@ -1,19 +1,27 @@ name: O365 Compliance Content Search Started id: f4cabbc7-c19a-4e41-8be5-98daeaccbb50 -version: 1 -date: '2024-04-01' +version: 2 +date: '2024-05-15' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations. +description: The following analytic detects when a content search is initiated within + the Office 365 Security and Compliance Center. It leverages the SearchCreated operation + from the o365_management_activity logs under the SecurityComplianceCenter workload. + This activity is significant as it may indicate an attempt to access sensitive organizational + data, including emails and documents. If confirmed malicious, this could lead to + unauthorized data access, potential data exfiltration, and compliance violations. + Monitoring this behavior helps ensure the integrity and security of organizational + data. search: ' `o365_management_activity` Workload=SecurityComplianceCenter Operation=SearchCreated - | rename user_id as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, ObjectId, ExchangeLocations, user, Query |`security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` - | `o365_compliance_content_search_started_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Compliance content searches may be executed for legitimate purposes, filter as needed. + | rename user_id as user | stats count earliest(_time) as firstTime latest(_time) + as lastTime by Operation, ObjectId, ExchangeLocations, user, Query |`security_content_ctime(firstTime)` + |`security_content_ctime(lastTime)` | `o365_compliance_content_search_started_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Compliance content searches may be executed for legitimate + purposes, filter as needed. references: - https://attack.mitre.org/techniques/T1114/002/ - https://learn.microsoft.com/en-us/purview/ediscovery-content-search-overview @@ -51,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_compliance_content_search_started/o365_compliance_content_search_started.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_compliance_content_search_started/o365_compliance_content_search_started.log sourcetype: o365:management:activity - source: o365 \ No newline at end of file + source: o365 diff --git a/detections/cloud/o365_concurrent_sessions_from_different_ips.yml b/detections/cloud/o365_concurrent_sessions_from_different_ips.yml index 8e4b402825..94efdef9cd 100644 --- a/detections/cloud/o365_concurrent_sessions_from_different_ips.yml +++ b/detections/cloud/o365_concurrent_sessions_from_different_ips.yml @@ -1,19 +1,24 @@ name: O365 Concurrent Sessions From Different Ips id: 58e034de-1f87-4812-9dc3-a4f68c7db930 -version: 1 -date: '2023-12-04' +version: 2 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. -data_source: +description: The following analytic identifies user sessions in Office 365 accessed + from multiple IP addresses, indicating potential adversary-in-the-middle (AiTM) + phishing attacks. It detects this activity by analyzing Azure Active Directory logs + for 'UserLoggedIn' operations and flags sessions with more than one associated IP + address. This behavior is significant as it suggests unauthorized concurrent access, + which is uncommon in normal usage. If confirmed malicious, the impact could include + data theft, account takeover, and the launching of internal phishing campaigns, + posing severe risks to organizational security. +data_source: - O365 UserLoggedIn search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoggedIn - | stats min(_time) as firstTime max(_time) as lastTime values(src_ip) as ips values(user_agent) as user_agents by Operation, user, SessionId - | where mvcount(ips) > 1 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_concurrent_sessions_from_different_ips_filter`' + | stats min(_time) as firstTime max(_time) as lastTime values(src_ip) as ips values(user_agent) + as user_agents by Operation, user, SessionId | where mvcount(ips) > 1 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `o365_concurrent_sessions_from_different_ips_filter`' how_to_implement: You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity known_false_positives: Unknown @@ -27,7 +32,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: User $user$ has logged in with the same session id from more than one unique IP address + message: User $user$ has logged in with the same session id from more than one unique + IP address mitre_attack_id: - T1185 observable: @@ -55,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/o365_concurrent_sessions_from_different_ips/o365_concurrent_sessions_from_different_ips.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/o365_concurrent_sessions_from_different_ips/o365_concurrent_sessions_from_different_ips.log sourcetype: o365:management:activity source: o365 update_timestamp: true diff --git a/detections/cloud/o365_disable_mfa.yml b/detections/cloud/o365_disable_mfa.yml index 49a20fede9..9b85e10668 100644 --- a/detections/cloud/o365_disable_mfa.yml +++ b/detections/cloud/o365_disable_mfa.yml @@ -1,12 +1,20 @@ name: O365 Disable MFA id: c783dd98-c703-4252-9e8a-f19d9f5c949e -version: 2 -date: '2022-02-03' +version: 3 +date: '2024-05-11' author: Rod Soto, Splunk status: production type: TTP -description: This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. -data_source: +description: The following analytic identifies instances where Multi-Factor Authentication + (MFA) is disabled for a user within the Office 365 environment. It leverages O365 + audit logs, specifically focusing on events related to MFA settings. Disabling MFA + removes a critical security layer, making accounts more vulnerable to unauthorized + access. If confirmed malicious, this activity could indicate an attacker attempting + to maintain persistence or an insider threat, significantly increasing the risk + of unauthorized access. Immediate investigation is required to validate the reason + for disabling MFA, potentially re-enable it, and assess any other suspicious activities + related to the affected account. +data_source: - O365 Disable Strong Authentication. search: '`o365_management_activity` Operation="Disable Strong Authentication." | stats count earliest(_time) as firstTime latest(_time) as lastTime by UserType Operation @@ -51,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/o365_disable_mfa/o365_disable_mfa.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/o365_disable_mfa/o365_disable_mfa.json sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_elevated_mailbox_permission_assigned.yml b/detections/cloud/o365_elevated_mailbox_permission_assigned.yml index 6e63a5203e..b2c1c243e6 100644 --- a/detections/cloud/o365_elevated_mailbox_permission_assigned.yml +++ b/detections/cloud/o365_elevated_mailbox_permission_assigned.yml @@ -1,21 +1,28 @@ name: O365 Elevated Mailbox Permission Assigned id: 2246c142-a678-45f8-8546-aaed7e0efd30 -version: 1 -date: '2024-03-31' +version: 2 +date: '2024-05-15' author: Patrick Bareiss, Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls. -search: ' `o365_management_activity` Workload=Exchange Operation=Add-MailboxPermission +description: The following analytic identifies the assignment of elevated mailbox + permissions in an Office 365 environment via the Add-MailboxPermission operation. + It leverages logs from the Exchange workload in the o365_management_activity data + source, focusing on permissions such as FullAccess, ChangePermission, or ChangeOwner. + This activity is significant as it indicates potential unauthorized access or control + over mailboxes, which could lead to data exfiltration or privilege escalation. If + confirmed malicious, attackers could gain extensive access to sensitive email data + and potentially manipulate mailbox settings, posing a severe security risk. +search: ' `o365_management_activity` Workload=Exchange Operation=Add-MailboxPermission | search (AccessRights=FullAccess OR AccessRights=ChangePermission OR AccessRights=ChangeOwner) - | rename Identity AS dest_user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by user dest_user Operation AccessRights - |`security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` - | `o365_elevated_mailbox_permission_assigned_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: FullAccess mailbox delegation may be assigned for legitimate purposes, filter as needed. + | rename Identity AS dest_user | stats count earliest(_time) as firstTime latest(_time) + as lastTime by user dest_user Operation AccessRights |`security_content_ctime(firstTime)` + |`security_content_ctime(lastTime)` | `o365_elevated_mailbox_permission_assigned_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: FullAccess mailbox delegation may be assigned for legitimate + purposes, filter as needed. references: - https://attack.mitre.org/techniques/T1098/002/ - https://learn.microsoft.com/en-us/powershell/module/exchange/add-mailboxpermission @@ -52,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/suspicious_rights_delegation/suspicious_rights_delegation.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/suspicious_rights_delegation/suspicious_rights_delegation.json source: o365:management:activity sourcetype: o365:management:activity diff --git a/detections/cloud/o365_file_permissioned_application_consent_granted_by_user.yml b/detections/cloud/o365_file_permissioned_application_consent_granted_by_user.yml index fa4b941926..f0fbd80d5d 100644 --- a/detections/cloud/o365_file_permissioned_application_consent_granted_by_user.yml +++ b/detections/cloud/o365_file_permissioned_application_consent_granted_by_user.yml @@ -1,26 +1,37 @@ name: O365 File Permissioned Application Consent Granted by User id: 6c382336-22b8-4023-9b80-1689e799f21f -version: 1 -date: '2023-10-18' +version: 2 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Consent to application. -description: This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted. +description: The following analytic identifies instances where a user in the Office + 365 environment grants consent to an application requesting file permissions for + OneDrive or SharePoint. It leverages O365 audit logs, focusing on OAuth application + consent events. This activity is significant because granting such permissions can + allow applications to access, modify, or delete files, posing a risk if the application + is malicious or overly permissive. If confirmed malicious, this could lead to data + breaches, data loss, or unauthorized data manipulation, necessitating immediate + investigation to validate the application's legitimacy and assess potential risks. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." ResultStatus=Success + `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." + ResultStatus=Success | eval admin_consent =mvindex('ModifiedProperties{}.NewValue', 0) | search admin_consent=False | eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) | rex field=permissions "Scope: (?[^,]+)" | makemv delim=" " Scope - | search Scope IN ("Files.Read", "Files.Read.All", "Files.ReadWrite", "Files.ReadWrite.All", "Files.ReadWrite.AppFolder") + | search Scope IN ("Files.Read", "Files.Read.All", "Files.ReadWrite", "Files.ReadWrite.All", + "Files.ReadWrite.AppFolder") | stats max(_time) as lastTime values(Scope) by Operation, user, object, ObjectId | `security_content_ctime(lastTime)` | `o365_file_permissioned_application_consent_granted_by_user_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: OAuth applications that require file permissions may be legitimate, investigate and filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: OAuth applications that require file permissions may be legitimate, + investigate and filter as needed. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -58,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_file_permissions/o365_user_consent_file_permissions.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_file_permissions/o365_user_consent_file_permissions.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_fullaccessasapp_permission_assigned.yml b/detections/cloud/o365_fullaccessasapp_permission_assigned.yml index 93b792ad1f..c6f2706e01 100644 --- a/detections/cloud/o365_fullaccessasapp_permission_assigned.yml +++ b/detections/cloud/o365_fullaccessasapp_permission_assigned.yml @@ -1,25 +1,34 @@ name: O365 FullAccessAsApp Permission Assigned id: 01a510b3-a6ac-4d50-8812-7e8a3cde3d79 -version: 1 -date: '2024-01-29' +version: 2 +date: '2024-05-11' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Update application. -description: The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss. +description: The following analytic detects the assignment of the 'full_access_as_app' + permission to an application registration in Office 365 Exchange Online. This detection + leverages Office 365 management activity logs and filters Azure Active Directory + workload events to identify when the specific permission, identified by GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', + is granted. This activity is significant because it provides extensive control over + Office 365 operations, including access to all mailboxes and the ability to send + mail as any user. If confirmed malicious, this could lead to unauthorized data access, + exfiltration, or account compromise. Immediate investigation is required. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Update application." - | eval newvalue = mvindex('ModifiedProperties{}.NewValue',0) - | spath input=newvalue - | search "{}.ResourceAppId"="00000002-0000-0ff1-ce00-000000000000" "{}.RequiredAppPermissions{}.EntitlementId"="dc890d15-9560-4a4c-9b7f-a736ec74ec40" - | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) by user, object, user_agent, Operation - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_fullaccessasapp_permission_assigned_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. + `o365_management_activity` Workload=AzureActiveDirectory Operation="Update application." + | eval newvalue = mvindex('ModifiedProperties{}.NewValue',0) + | spath input=newvalue | search "{}.ResourceAppId"="00000002-0000-0ff1-ce00-000000000000" "{}.RequiredAppPermissions{}.EntitlementId"="dc890d15-9560-4a4c-9b7f-a736ec74ec40" + | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) + by user, object, user_agent, Operation + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `o365_fullaccessasapp_permission_assigned_filter` +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: The full_access_as_app API permission may be assigned to legitimate + applications. Filter as needed. references: - https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -31,7 +40,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 80 - message: User $user$ assigned the full_access_as_app permission to the app registration $object$ + message: User $user$ assigned the full_access_as_app permission to the app registration + $object$ mitre_attack_id: - T1098.002 - T1098.003 @@ -57,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_full_access_as_app_permission_assigned/o365_full_access_as_app_permission_assigned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_full_access_as_app_permission_assigned/o365_full_access_as_app_permission_assigned.log source: o365:management:activity sourcetype: o365:management:activity diff --git a/detections/cloud/o365_high_number_of_failed_authentications_for_user.yml b/detections/cloud/o365_high_number_of_failed_authentications_for_user.yml index 312dae8668..e684d23e4c 100644 --- a/detections/cloud/o365_high_number_of_failed_authentications_for_user.yml +++ b/detections/cloud/o365_high_number_of_failed_authentications_for_user.yml @@ -1,20 +1,27 @@ name: O365 High Number Of Failed Authentications for User id: 31641378-2fa9-42b1-948e-25e281cb98f7 -version: 1 -date: '2023-10-10' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 UserLoginFailed -description: The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data. -search: ' `o365_management_activity` Operation=UserLoginFailed record_type=AzureActiveDirectoryStsLogon Workload=AzureActiveDirectory - | bucket span=5m _time - | stats dc(_raw) AS failed_attempts values(src_ip) as src_ip by user, _time - | where failed_attempts > 10 - | `o365_high_number_of_failed_authentications_for_user_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Although unusual, users who have lost their passwords may trigger this detection. Filter as needed. +description: The following analytic identifies an O365 account experiencing more than + 20 failed authentication attempts within 5 minutes. It uses O365 Unified Audit Logs, + specifically "UserLoginFailed" events, to monitor and flag accounts exceeding this + threshold. This activity is significant as it may indicate a brute force attack + or password guessing attempt. If confirmed malicious, an attacker could gain unauthorized + access to the O365 environment, potentially compromising sensitive emails, documents, + and other data. Prompt investigation and action are crucial to prevent unauthorized + access and data breaches. +search: ' `o365_management_activity` Operation=UserLoginFailed record_type=AzureActiveDirectoryStsLogon + Workload=AzureActiveDirectory | bucket span=5m _time | stats dc(_raw) AS failed_attempts values(src_ip) + as src_ip by user, _time | where failed_attempts > 10 | `o365_high_number_of_failed_authentications_for_user_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Although unusual, users who have lost their passwords may trigger + this detection. Filter as needed. references: - https://attack.mitre.org/techniques/T1110/ - https://attack.mitre.org/techniques/T1110/001/ @@ -24,7 +31,8 @@ tags: asset_type: O365 Tenant confidence: 70 impact: 50 - message: User $user$ failed to authenticate more than 10 times in the span of 5 minutes. + message: User $user$ failed to authenticate more than 10 times in the span of 5 + minutes. mitre_attack_id: - T1110 - T1110.001 @@ -53,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/o365_high_number_authentications_for_user/o365_high_number_authentications_for_user.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/o365_high_number_authentications_for_user/o365_high_number_authentications_for_user.log source: o365:management:activity sourcetype: o365:management:activity diff --git a/detections/cloud/o365_high_privilege_role_granted.yml b/detections/cloud/o365_high_privilege_role_granted.yml index d7d1adadee..da3e718fb0 100644 --- a/detections/cloud/o365_high_privilege_role_granted.yml +++ b/detections/cloud/o365_high_privilege_role_granted.yml @@ -1,24 +1,34 @@ name: O365 High Privilege Role Granted id: e78a1037-4548-4072-bb1b-ad99ae416426 -version: 1 -date: '2023-10-20' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Add member to role. -description: This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment. +description: The following analytic detects when high-privilege roles such as "Exchange + Administrator," "SharePoint Administrator," or "Global Administrator" are granted + within Office 365. It leverages O365 audit logs to identify events where these roles + are assigned to any user or service account. This activity is significant for SOCs + as these roles provide extensive permissions, allowing broad access and control + over critical resources and data. If confirmed malicious, this could enable attackers + to gain significant control over O365 resources, access, modify, or delete critical + data, and compromise the overall security and functionality of the O365 environment. search: >- `o365_management_activity` Operation="Add member to role." Workload=AzureActiveDirectory | eval role_id = mvindex('ModifiedProperties{}.NewValue',2) | eval role_name = mvindex('ModifiedProperties{}.NewValue',1) - | where role_id IN ("29232cdf-9323-42fd-ade2-1d097af3e4de", "f28a1f50-f6e7-4571-818b-6a12f2af6b6c", "62e90394-69f5-4237-9190-012177145e10") - | stats earliest(_time) as firstTime latest(_time) as lastTime by user Operation ObjectId role_name + | where role_id IN ("29232cdf-9323-42fd-ade2-1d097af3e4de", "f28a1f50-f6e7-4571-818b-6a12f2af6b6c", + "62e90394-69f5-4237-9190-012177145e10") | stats earliest(_time) as firstTime latest(_time) + as lastTime by user Operation ObjectId role_name | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_high_privilege_role_granted_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Privilege roles may be assigned for legitimate purposes, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Privilege roles may be assigned for legitimate purposes, filter + as needed. references: - https://attack.mitre.org/techniques/T1098/003/ - https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference @@ -55,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_high_priv_role_assigned/o365_high_priv_role_assigned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_high_priv_role_assigned/o365_high_priv_role_assigned.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_mail_permissioned_application_consent_granted_by_user.yml b/detections/cloud/o365_mail_permissioned_application_consent_granted_by_user.yml index 38509dc825..41b81db2a0 100644 --- a/detections/cloud/o365_mail_permissioned_application_consent_granted_by_user.yml +++ b/detections/cloud/o365_mail_permissioned_application_consent_granted_by_user.yml @@ -1,26 +1,38 @@ name: O365 Mail Permissioned Application Consent Granted by User id: fddad083-cdf5-419d-83c6-baa85e329595 -version: 1 -date: '2023-10-12' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Consent to application. -description: The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities. +description: The following analytic identifies instances where a user grants consent + to an application requesting mail-related permissions within the Office 365 environment. + It leverages O365 audit logs, specifically focusing on events related to application + permissions and user consent actions. This activity is significant as it can indicate + potential security risks, such as data exfiltration or spear phishing, if malicious + applications gain access. If confirmed malicious, this could lead to unauthorized + data access, email forwarding, or sending malicious emails from the compromised + account. Validating the legitimacy of the application and consent context is crucial + to prevent data breaches. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." ResultStatus=Success + `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." + ResultStatus=Success | eval admin_consent =mvindex('ModifiedProperties{}.NewValue', 0) | search admin_consent=False | eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) | rex field=permissions "Scope: (?[^,]+)" | makemv delim=" " Scope - | search Scope IN ("Mail.Read", "Mail.ReadBasic", "Mail.ReadWrite", "Mail.Read.Shared", "Mail.ReadWrite.Shared", "Mail.Send", "Mail.Send.Shared") + | search Scope IN ("Mail.Read", "Mail.ReadBasic", "Mail.ReadWrite", "Mail.Read.Shared", + "Mail.ReadWrite.Shared", "Mail.Send", "Mail.Send.Shared") | stats max(_time) as lastTime values(Scope) by Operation, user, object, ObjectId | `security_content_ctime(lastTime)` | `o365_mail_permissioned_application_consent_granted_by_user_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: OAuth applications that require mail permissions may be legitimate, + investigate and filter as needed. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -59,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_mail_permissions/o365_user_consent_mail_permissions.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_mail_permissions/o365_user_consent_mail_permissions.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_mailbox_email_forwarding_enabled.yml b/detections/cloud/o365_mailbox_email_forwarding_enabled.yml index 01acd539a9..feb85ab074 100644 --- a/detections/cloud/o365_mailbox_email_forwarding_enabled.yml +++ b/detections/cloud/o365_mailbox_email_forwarding_enabled.yml @@ -1,26 +1,34 @@ name: O365 Mailbox Email Forwarding Enabled id: 0b6bc75c-05d1-4101-9fc3-97e706168f24 -version: 1 -date: '2024-03-26' +version: 2 +date: '2024-05-24' author: Patrick Bareiss, Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox. +description: The following analytic identifies instances where email forwarding has + been enabled on mailboxes within an Office 365 environment. It detects this activity + by monitoring the Set-Mailbox operation within the o365_management_activity logs, + specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress + parameters. This activity is significant as unauthorized email forwarding can lead + to data exfiltration and unauthorized access to sensitive information. If confirmed + malicious, attackers could intercept and redirect emails, potentially compromising + confidential communications and leading to data breaches. search: >- - `o365_management_activity` Operation=Set-Mailbox - | eval match1=mvfind('Parameters{}.Name', "ForwardingAddress") + `o365_management_activity` Operation=Set-Mailbox | eval match1=mvfind('Parameters{}.Name', + "ForwardingAddress") | eval match2=mvfind('Parameters{}.Name', "ForwardingSmtpAddress") | where match1>= 0 OR match2>= 0 | eval ForwardTo=coalesce(ForwardingAddress, ForwardingSmtpAddress) - | search ForwardTo!="" - | rename user_id as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ForwardTo) as ForwardTo by user ObjectId - |`security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` + | search ForwardTo!="" | rename user_id as user + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ForwardTo) + as ForwardTo by user ObjectId + |`security_content_ctime(firstTime)` |`security_content_ctime(lastTime)` | `o365_mailbox_email_forwarding_enabled_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Email forwarding may be configured for legitimate purposes, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Email forwarding may be configured for legitimate purposes, + filter as needed. references: - https://attack.mitre.org/techniques/T1114/003/ - https://learn.microsoft.com/en-us/exchange/recipients/user-mailboxes/email-forwarding?view=exchserver-2019 @@ -55,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_mailbox_forwarding_enabled/o365_mailbox_forwarding_enabled.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_mailbox_forwarding_enabled/o365_mailbox_forwarding_enabled.json sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_mailbox_folder_read_permission_assigned.yml b/detections/cloud/o365_mailbox_folder_read_permission_assigned.yml index 955e6a71b0..49bbeb8296 100644 --- a/detections/cloud/o365_mailbox_folder_read_permission_assigned.yml +++ b/detections/cloud/o365_mailbox_folder_read_permission_assigned.yml @@ -1,22 +1,33 @@ name: O365 Mailbox Folder Read Permission Assigned id: 1435475e-2128-4417-a34f-59770733b0d5 -version: 1 -date: '2024-03-29' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders. +description: The following analytic identifies instances where read permissions are + assigned to mailbox folders within an Office 365 environment. It leverages the `o365_management_activity` + data source, specifically monitoring the `ModifyFolderPermissions` and `AddFolderPermissions` + operations, while excluding Calendar, Contacts, and PersonMetadata objects. This + activity is significant as unauthorized read permissions can lead to data exposure + and potential information leakage. If confirmed malicious, an attacker could gain + unauthorized access to sensitive emails, leading to data breaches and compromising + the confidentiality of organizational communications. search: >- - `o365_management_activity` Workload=Exchange (Operation=ModifyFolderPermissions OR Operation=AddFolderPermissions) Workload=Exchange object!=Calendar object!=Contacts object!=PersonMetadata - | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", "false") - | rename UserId as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, user, object, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights + `o365_management_activity` Workload=Exchange (Operation=ModifyFolderPermissions + OR Operation=AddFolderPermissions) Workload=Exchange object!=Calendar object!=Contacts + object!=PersonMetadata + | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", + "false") | rename UserId as user | stats count earliest(_time) as firstTime latest(_time) + as lastTime by Operation, user, object, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_mailbox_folder_read_permission_assigned_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Mailbox folder permissions may be configured for legitimate purposes, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Mailbox folder permissions may be configured for legitimate + purposes, filter as needed. references: - https://attack.mitre.org/techniques/T1098/002/ - https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxodlgt/5610c6e6-3268-44e3-adff-8804f5315946 @@ -52,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_mailbox_folder_read_granted/o365_mailbox_folder_read_granted.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_mailbox_folder_read_granted/o365_mailbox_folder_read_granted.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_mailbox_folder_read_permission_granted.yml b/detections/cloud/o365_mailbox_folder_read_permission_granted.yml index 0fb03e72d8..7d13aaa76c 100644 --- a/detections/cloud/o365_mailbox_folder_read_permission_granted.yml +++ b/detections/cloud/o365_mailbox_folder_read_permission_granted.yml @@ -1,22 +1,29 @@ name: O365 Mailbox Folder Read Permission Granted id: cd15c0a8-470e-4b12-9517-046e4927db30 -version: 1 -date: '2024-03-28' +version: 2 +date: '2024-05-25' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents. -search: ' `o365_management_activity` Workload=Exchange (Operation="Set-MailboxFolderPermission" OR Operation="Add-MailboxFolderPermission" ) - | eval isReadRole=if(match(AccessRights, "^(ReadItems|Author|NonEditingAuthor|Owner|PublishingAuthor|Reviewer)$"), "true", "false") - | search isReadRole="true" - | rename UserId as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, user, Identity, AccessRights - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_mailbox_folder_read_permission_granted_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Mailbox folder permissions may be configured for legitimate purposes, filter as needed. +description: The following analytic identifies instances where read permissions are + granted to mailbox folders within an Office 365 environment. It detects this activity + by monitoring the `o365_management_activity` data source for the `Set-MailboxFolderPermission` + and `Add-MailboxFolderPermission` operations. This behavior is significant as it + may indicate unauthorized access or changes to mailbox folder permissions, potentially + exposing sensitive email content. If confirmed malicious, an attacker could gain + unauthorized access to read email communications, leading to data breaches or information + leakage. +search: ' `o365_management_activity` Workload=Exchange (Operation="Set-MailboxFolderPermission" + OR Operation="Add-MailboxFolderPermission" ) | eval isReadRole=if(match(AccessRights, + "^(ReadItems|Author|NonEditingAuthor|Owner|PublishingAuthor|Reviewer)$"), "true", + "false") | search isReadRole="true" | rename UserId as user | stats count earliest(_time) + as firstTime latest(_time) as lastTime by Operation, user, Identity, AccessRights + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_mailbox_folder_read_permission_granted_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Mailbox folder permissions may be configured for legitimate + purposes, filter as needed. references: - https://attack.mitre.org/techniques/T1098/002/ - https://learn.microsoft.com/en-us/powershell/module/exchange/add-mailboxfolderpermission?view=exchange-ps @@ -52,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_mailbox_folder_read_granted/o365_mailbox_folder_read_granted.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.002/o365_mailbox_folder_read_granted/o365_mailbox_folder_read_granted.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_mailbox_inbox_folder_shared_with_all_users.yml b/detections/cloud/o365_mailbox_inbox_folder_shared_with_all_users.yml index bb295bdbe0..a47d64ad76 100644 --- a/detections/cloud/o365_mailbox_inbox_folder_shared_with_all_users.yml +++ b/detections/cloud/o365_mailbox_inbox_folder_shared_with_all_users.yml @@ -1,23 +1,36 @@ name: O365 Mailbox Inbox Folder Shared with All Users id: 21421896-a692-4594-9888-5faeb8a53106 -version: 1 -date: '2023-09-07' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 ModifyFolderPermissions -description: The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox. +description: The following analytic detects instances where the inbox folder of an + Office 365 mailbox is shared with all users within the tenant. It leverages Office + 365 management activity events to identify when the 'Inbox' folder permissions are + modified to include 'Everyone' with read rights. This activity is significant as + it represents a potential security risk, allowing unauthorized access to sensitive + emails. If confirmed malicious, this could lead to data breaches, exfiltration of + confidential information, and further compromise through spear-phishing or other + malicious activities based on the accessed email content. search: >- - `o365_management_activity` Operation=ModifyFolderPermissions Workload=Exchange object=Inbox Item.ParentFolder.MemberUpn=Everyone - | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", "false") - | search isReadRole = "true" - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, UserId, object, MailboxOwnerUPN, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights + `o365_management_activity` Operation=ModifyFolderPermissions Workload=Exchange object=Inbox + Item.ParentFolder.MemberUpn=Everyone + | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", + "false") | search isReadRole = "true" + | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, + UserId, object, MailboxOwnerUPN, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_mailbox_inbox_folder_shared_with_all_users_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Administrators might temporarily share a mailbox with all users for legitimate reasons, such as troubleshooting, migrations, or other administrative tasks. Some organizations use shared mailboxes for teams or departments where multiple users need access to the same mailbox. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Administrators might temporarily share a mailbox with all users + for legitimate reasons, such as troubleshooting, migrations, or other administrative + tasks. Some organizations use shared mailboxes for teams or departments where multiple + users need access to the same mailbox. Filter as needed. references: - https://attack.mitre.org/techniques/T1114/002/ - https://www.mandiant.com/sites/default/files/2022-08/remediation-hardening-strategies-for-m365-defend-against-apt29-white-paper.pdf @@ -57,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_inbox_shared_with_all_users/o365_inbox_shared_with_all_users.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_inbox_shared_with_all_users/o365_inbox_shared_with_all_users.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_mailbox_read_access_granted_to_application.yml b/detections/cloud/o365_mailbox_read_access_granted_to_application.yml index be3de57bf8..d8a3f346dc 100644 --- a/detections/cloud/o365_mailbox_read_access_granted_to_application.yml +++ b/detections/cloud/o365_mailbox_read_access_granted_to_application.yml @@ -1,19 +1,20 @@ name: O365 Mailbox Read Access Granted to Application id: 27ab61c5-f08a-438a-b4d3-325e666490b3 -version: 1 -date: '2023-09-01' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Update application. -description: The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 - tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. - The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, - and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such - access and that any inadvertent or malicious assignments are promptly identified. - If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to - data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. +description: The following analytic identifies instances where the Mail.Read Graph + API permissions are granted to an application registration within an Office 365 + tenant. It leverages O365 audit logs, specifically events related to changes in + application permissions within the AzureActiveDirectory workload. This activity + is significant because the Mail.Read permission allows applications to access and + read all emails within a user's mailbox, which often contain sensitive or confidential + information. If confirmed malicious, this could lead to data exfiltration, spear-phishing + attacks, or further compromise based on the information gathered from the emails. search: >- `o365_management_activity` Operation="Update application." | eval json_data=mvindex('ModifiedProperties{}.NewValue', 0) @@ -22,11 +23,14 @@ search: >- | spath input=json_data path=RequiredAppPermissions{}.EntitlementId output=EntitlementIds | eval match_found=mvfind(EntitlementIds, "810c84a8-4a9e-49e6-bf7d-12d183f40d01") | where isnotnull(match_found) - | stats max(_time) as lastTime values(EntitlementIds) as EntitlementIds by Operation, user, object + | stats max(_time) as lastTime values(EntitlementIds) as EntitlementIds by Operation, + user, object | `security_content_ctime(lastTime)` | `o365_mailbox_read_access_granted_to_application_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: There are legitimate scenarios in wich an Application registrations requires Mailbox read access. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: There are legitimate scenarios in wich an Application registrations + requires Mailbox read access. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ - https://attack.mitre.org/techniques/T1114/002/ @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_grant_mail_read/o365_grant_mail_read.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_grant_mail_read/o365_grant_mail_read.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multi_source_failed_authentications_spike.yml b/detections/cloud/o365_multi_source_failed_authentications_spike.yml index 340816b5f0..2972dea980 100644 --- a/detections/cloud/o365_multi_source_failed_authentications_spike.yml +++ b/detections/cloud/o365_multi_source_failed_authentications_spike.yml @@ -1,22 +1,38 @@ name: O365 Multi-Source Failed Authentications Spike id: ea4e2c41-dbfb-4f5f-a7b6-9ac1b7f104aa -version: 1 -date: '2023-11-09' +version: 2 +date: '2024-05-31' author: Mauricio Velazco, Splunk status: production type: Hunting -data_source: +data_source: - O365 UserLoginFailed -description: This analytic detects potential distributed password spraying attacks within an Office 365 environment. It identifies a significant increase in failed authentication attempts characterized by diverse user-and-IP address combinations, originating from multiple source IP addresses, and utilizing various user agents. These patterns may indicate an adversary's attempt to circumvent security controls by employing a spectrum of IP addresses to test commonly used passwords against a wide range of user accounts. The detection examines UserLoginFailed events from O365 Management Activity logs, with a particular focus on events with ErrorNumber 50126, which indicates a failed authentication due to incorrect credentials. By aggregating data over a five-minute interval, the analytic calculates the distinct counts of user-and-IP combinations and unique users and source IPs. It then applies a set of thresholds to these metrics to identify abnormal activities that could suggest a coordinated attack. The predefined thresholds within the analytic (such as unique IPs, unique users, etc.) serve as initial benchmarks and should be tailored to align with the organization's typical user behavior and risk tolerance. Early detection of such distributed activities is crucial for security operations centers (SOCs) to intercept unauthorized access attempts, avert account takeovers, and reduce the risk of subsequent malevolent actions within the organization's systems. A true positive alert from this analytic would indicate an ongoing distributed password spraying campaign targeting the organization's Office 365 tenant. If such an attack is successful, it could lead to unauthorized access, especially to accounts with administrative privileges, resulting in data breaches, privilege escalation, persistent threats, and lateral movement within the organization's digital environment. -search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed ErrorNumber=50126 - | bucket span=5m _time - | eval uniqueIPUserCombo = src_ip . "-" . user - | stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, values(user) as user, values(src_ip) as ips, values(user_agent) as user_agents by _time - | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20 - | `o365_multi_source_failed_authentications_spike_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. - The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. -known_false_positives: This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. +description: The following analytic identifies a spike in failed authentication attempts + within an Office 365 environment, indicative of a potential distributed password + spraying attack. It leverages UserLoginFailed events from O365 Management Activity + logs, focusing on ErrorNumber 50126. This detection is significant as it highlights + attempts to bypass security controls using multiple IP addresses and user agents. + If confirmed malicious, this activity could lead to unauthorized access, data breaches, + privilege escalation, and lateral movement within the organization. Early detection + is crucial to prevent account takeovers and mitigate subsequent threats. +search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed + ErrorNumber=50126 | bucket span=5m _time | eval uniqueIPUserCombo = src_ip . "-" + . user | stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, + dc(src_ip) as uniqueIPs, values(user) as user, values(src_ip) as ips, values(user_agent) + as user_agents by _time | where uniqueIpUserCombinations > 20 AND uniqueUsers > + 20 AND uniqueIPs > 20 | `o365_multi_source_failed_authentications_spike_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. The thresholds set within the analytic (such + as unique IPs, unique users, etc.) are initial guidelines and should be customized + based on the organization's user behavior and risk profile. Security teams are encouraged + to adjust these thresholds to optimize the balance between detecting genuine threats + and minimizing false positives, ensuring the detection is tailored to their specific + environment. +known_false_positives: This detection may yield false positives in scenarios where + legitimate bulk sign-in activities occur, such as during company-wide system updates + or when users are accessing resources from varying locations in a short time frame, + such as in the case of VPNs or cloud services that rotate IP addresses. Filter as + needed. references: - https://attack.mitre.org/techniques/T1110/003/ - https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray @@ -59,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/o365_distributed_spray/o365_distributed_spray.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/o365_distributed_spray/o365_distributed_spray.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/o365_multiple_appids_and_useragents_authentication_spike.yml index 93aef5578d..bd9b79e5ff 100644 --- a/detections/cloud/o365_multiple_appids_and_useragents_authentication_spike.yml +++ b/detections/cloud/o365_multiple_appids_and_useragents_authentication_spike.yml @@ -1,21 +1,32 @@ name: O365 Multiple AppIDs and UserAgents Authentication Spike id: 66adc486-224d-45c1-8e4d-9e7eeaba988f -version: 1 -date: '2023-10-24' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: Anomaly -data_source: +data_source: - O365 UserLoggedIn - O365 UserLoginFailed -description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an O365 environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of O365 audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. -search: ' `o365_management_activity` Workload=AzureActiveDirectory (Operation=UserLoggedIn OR Operation=UserLoginFailed) - | bucket span=5m _time - | stats dc(_raw) as failed_attempts dc(ApplicationId) as unique_app_ids dc(UserAgent) as unique_user_agents values(ApplicationId) values(OS) by _time user src_ip - | where failed_attempts > 5 and unique_user_agents > 5 and unique_app_ids > 2 - | `o365_multiple_appids_and_useragents_authentication_spike_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. +description: The following analytic identifies unusual authentication activity in + an O365 environment, where a single user account experiences more than 8 authentication + attempts using 3 or more unique application IDs and over 5 unique user agents within + a short timeframe. It leverages O365 audit logs, focusing on authentication events + and applying statistical thresholds. This behavior is significant as it may indicate + an adversary probing for multi-factor authentication weaknesses. If confirmed malicious, + it suggests a compromised account, potentially leading to unauthorized access, privilege + escalation, and data exfiltration. Early detection is crucial to prevent further + exploitation. +search: ' `o365_management_activity` Workload=AzureActiveDirectory (Operation=UserLoggedIn + OR Operation=UserLoginFailed) | bucket span=5m _time | stats dc(_raw) as failed_attempts + dc(ApplicationId) as unique_app_ids dc(UserAgent) as unique_user_agents values(ApplicationId) + values(OS) by _time user src_ip | where failed_attempts > 5 and unique_user_agents + > 5 and unique_app_ids > 2 | `o365_multiple_appids_and_useragents_authentication_spike_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Rapid authentication from the same user using more than 5 different + user agents and 3 application IDs is highly unlikely under normal circumstances. + However, there are potential scenarios that could lead to false positives. references: - https://attack.mitre.org/techniques/T1078/ - https://www.blackhillsinfosec.com/exploiting-mfa-inconsistencies-on-microsoft-services/ @@ -27,7 +38,8 @@ tags: asset_type: O365 Tenant confidence: 80 impact: 60 - message: $user$ authenticated in a short period of time with more than 5 different user agents across 3 or more unique application ids. + message: $user$ authenticated in a short period of time with more than 5 different + user agents across 3 or more unique application ids. mitre_attack_id: - T1078 observable: @@ -55,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/o365_multiple_appids_and_useragents_auth/o365_multiple_appids_and_useragents_auth.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/o365_multiple_appids_and_useragents_auth/o365_multiple_appids_and_useragents_auth.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/o365_multiple_failed_mfa_requests_for_user.yml index d9da40acf8..778080e17c 100644 --- a/detections/cloud/o365_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/o365_multiple_failed_mfa_requests_for_user.yml @@ -1,19 +1,27 @@ name: O365 Multiple Failed MFA Requests For User id: fd22124e-dbac-4744-a8ce-be10d8ec3e26 -version: 1 -date: '2023-10-19' +version: 2 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 UserLoginFailed -description: This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach. -search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed ResultStatus=Success ErrorNumber=500121 - | bucket span=10m _time - | stats dc(_raw) as mfa_prompts values(LogonError) as LogonError values(signature) as signature by user, _time - | where mfa_prompts > 9 - | `o365_multiple_failed_mfa_requests_for_user_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. +description: The following analytic identifies potential "MFA fatigue" attacks targeting + Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts + within a 10-minute timeframe. It leverages O365 management activity logs, focusing + on Azure Active Directory events with the UserLoginFailed operation, a Success ResultStatus, + and an ErrorNumber of 500121. This activity is significant as attackers may exploit + MFA fatigue to gain unauthorized access by overwhelming users with repeated MFA + requests. If confirmed malicious, this could lead to data breaches, unauthorized + data access, or further compromise within the O365 environment. Immediate investigation + is crucial. +search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed + ResultStatus=Success ErrorNumber=500121 | bucket span=10m _time | stats dc(_raw) + as mfa_prompts values(LogonError) as LogonError values(signature) as signature by + user, _time | where mfa_prompts > 9 | `o365_multiple_failed_mfa_requests_for_user_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. references: @@ -50,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/o365_multiple_failed_mfa_requests/o365_multiple_failed_mfa_requests.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/o365_multiple_failed_mfa_requests/o365_multiple_failed_mfa_requests.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_mailboxes_accessed_via_api.yml b/detections/cloud/o365_multiple_mailboxes_accessed_via_api.yml index 7bcdc9aaa3..4ade3a6007 100644 --- a/detections/cloud/o365_multiple_mailboxes_accessed_via_api.yml +++ b/detections/cloud/o365_multiple_mailboxes_accessed_via_api.yml @@ -1,22 +1,31 @@ name: O365 Multiple Mailboxes Accessed via API id: 7cd853e9-d370-412f-965d-a2bcff2a2908 -version: 1 -date: '2024-02-01' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk -data_source: +data_source: - O365 MailItemsAccessed type: TTP status: production -description: The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold - set here to flag over five unique mailboxes accessed within 10 minutes - to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency. -search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* ClientAppId=* - | bucket span=10m _time - | eval matchRegex=if(match(ClientInfoString, "^Client=WebServices;ExchangeWebServices"), 1, 0) - | search (AppId="00000003-0000-0000-c000-000000000000" OR matchRegex=1) - | stats values(ClientIPAddress) as src_ip dc(user) as unique_mailboxes values(user) as user by _time ClientAppId ClientInfoString - | where unique_mailboxes > 5 - | `o365_multiple_mailboxes_accessed_via_api_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Legitimate applications may access multiple mailboxes via an API. You can filter by the ClientAppId or the CLientIpAddress fields. +description: The following analytic detects when a high number of Office 365 Exchange + mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) within + a short timeframe. It leverages 'MailItemsAccessed' operations in Exchange, using + AppId and regex to identify API interactions. This activity is significant as it + may indicate unauthorized mass email access, potentially signaling data exfiltration + or account compromise. If confirmed malicious, attackers could gain access to sensitive + information, leading to data breaches and further exploitation of compromised accounts. + The threshold is set to flag over five unique mailboxes accessed within 10 minutes, + but should be tailored to your environment. +search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed + AppId=* ClientAppId=* | bucket span=10m _time | eval matchRegex=if(match(ClientInfoString, + "^Client=WebServices;ExchangeWebServices"), 1, 0) | search (AppId="00000003-0000-0000-c000-000000000000" + OR matchRegex=1) | stats values(ClientIPAddress) as src_ip dc(user) as unique_mailboxes + values(user) as user by _time ClientAppId ClientInfoString | where unique_mailboxes + > 5 | `o365_multiple_mailboxes_accessed_via_api_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Legitimate applications may access multiple mailboxes via an + API. You can filter by the ClientAppId or the CLientIpAddress fields. references: - https://attack.mitre.org/techniques/T1114/002/ - https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in @@ -31,7 +40,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: An Oauth application identified with id $ClientAppId$ accessed multiple mailboxes in a short period of time via an API. + message: An Oauth application identified with id $ClientAppId$ accessed multiple + mailboxes in a short period of time via an API. mitre_attack_id: - T1114.002 observable: @@ -57,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_multiple_mailboxes_accessed_via_api/o365_multiple_mailboxes_accessed_via_api.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_multiple_mailboxes_accessed_via_api/o365_multiple_mailboxes_accessed_via_api.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_service_principals_created_by_sp.yml b/detections/cloud/o365_multiple_service_principals_created_by_sp.yml index 1619ceb232..89a32250e8 100644 --- a/detections/cloud/o365_multiple_service_principals_created_by_sp.yml +++ b/detections/cloud/o365_multiple_service_principals_created_by_sp.yml @@ -1,27 +1,37 @@ name: O365 Multiple Service Principals Created by SP id: ef4c3f20-d1ad-4ad1-a3f4-d5f391c005fe -version: 1 -date: '2024-02-07' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk -data_source: +data_source: - O365 Add service principal. type: Anomaly status: production -description: This detection aims to identify instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe, using O365 logs from the Unified Audit Log. The focus is on tracking the 'Add service principal' operation within the Office 365 Azure Active Directory environment. The query effectively buckets events in 10-minute intervals, specifically scrutinizing the actions of service principals. By quantifying the number of distinct OAuth applications each service principal establishes, the analytic provides critical insights for SOC teams into potentially anomalous or malicious activities. These activities could include a compromised or malicious service principal being used to create multiple service principals, which might be indicative of an attempt to expand control or access within the network. Security teams are advised to adapt the threshold of three applications to align with their typical operational baseline +description: The following analytic identifies instances where a single service principal + creates more than three unique OAuth applications within a 10-minute timeframe. + It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service + principal' operation in the Office 365 Azure Active Directory environment. This + activity is significant as it may indicate a compromised or malicious service principal + attempting to expand control or access within the network. If confirmed malicious, + this could lead to unauthorized access and potential lateral movement within the + environment, posing a significant security risk. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Add service principal." - | bucket span=10m _time - | eval len=mvcount('Actor{}.ID') - | eval userType = mvindex('Actor{}.ID',len-1) - | search userType = "ServicePrincipal" - | eval displayName = object - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(displayName) as displayName dc(displayName) as unique_apps by src_user - | where unique_apps > 3 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_multiple_service_principals_created_by_sp_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. + `o365_management_activity` Workload=AzureActiveDirectory Operation="Add service + principal." | bucket span=10m _time + | eval len=mvcount('Actor{}.ID') + | eval userType = mvindex('Actor{}.ID',len-1) + | search userType = "ServicePrincipal" + | eval displayName = object + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(displayName) + as displayName dc(displayName) as unique_apps by src_user + | where unique_apps > 3 + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `o365_multiple_service_principals_created_by_sp_filter` +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Certain users or applications may create multiple service principals + in a short period of time for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1136/003/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -32,7 +42,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: Multiple OAuth applications were created by $src_user$ in a short period of time + message: Multiple OAuth applications were created by $src_user$ in a short period + of time mitre_attack_id: - T1136.003 observable: @@ -56,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_multiple_service_principals_created/o365_multiple_service_principals_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_multiple_service_principals_created/o365_multiple_service_principals_created.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_service_principals_created_by_user.yml b/detections/cloud/o365_multiple_service_principals_created_by_user.yml index eae0e797ef..f726e973c7 100644 --- a/detections/cloud/o365_multiple_service_principals_created_by_user.yml +++ b/detections/cloud/o365_multiple_service_principals_created_by_user.yml @@ -1,27 +1,37 @@ name: O365 Multiple Service Principals Created by User id: a34e65d0-54de-4b02-9db8-5a04522067f6 -version: 1 -date: '2024-02-07' +version: 2 +date: '2024-05-21' author: Mauricio Velazco, Splunk -data_source: +data_source: - O365 Add service principal. type: Anomaly status: production -description: This detection is tailored to spot occurrences where a single user, rather than a service principal, creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. Utilizing O365 logs from the Unified Audit Log, it focuses on the 'Add service principal' operation in Azure Active Directory. The query segments events into 10-minute intervals, exclusively monitoring user activities. It calculates the number of distinct OAuth applications initiated by each user, providing SOC teams with essential data for identifying potential security threats. Such activity could suggest that a user account is either compromised or engaged in unauthorized activities, potentially setting the stage for broader network infiltration or privilege escalation. It's important for security teams to adjust the threshold of three applications to fit their operational context. +description: The following analytic identifies instances where a single user creates + more than three unique OAuth applications within a 10-minute window in the Office + 365 environment. It leverages O365 logs from the Unified Audit Log, focusing on + the 'Add service principal' operation in Azure Active Directory. This activity is + significant as it may indicate a compromised user account or unauthorized actions, + potentially leading to broader network infiltration or privilege escalation. If + confirmed malicious, this behavior could allow attackers to gain persistent access, + escalate privileges, or exfiltrate sensitive information. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Add service principal." - | bucket span=10m _time + `o365_management_activity` Workload=AzureActiveDirectory Operation="Add service + principal." | bucket span=10m _time | eval len=mvcount('Actor{}.ID') | eval userType = mvindex('Actor{}.ID',len-1) | search userType = "User" | eval displayName = object - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(displayName) as displayName dc(displayName) as unique_apps by src_user + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(displayName) + as displayName dc(displayName) as unique_apps by src_user | where unique_apps > 3 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_multiple_service_principals_created_by_user_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Certain users or applications may create multiple service principals + in a short period of time for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1136/003/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -32,7 +42,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: Multiple OAuth applications were created by $src_user$ in a short period of time + message: Multiple OAuth applications were created by $src_user$ in a short period + of time mitre_attack_id: - T1136.003 observable: @@ -56,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_multiple_service_principals_created/o365_multiple_service_principals_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_multiple_service_principals_created/o365_multiple_service_principals_created.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_multiple_users_failing_to_authenticate_from_ip.yml b/detections/cloud/o365_multiple_users_failing_to_authenticate_from_ip.yml index 0b3ceb1405..b8f4cbcd51 100644 --- a/detections/cloud/o365_multiple_users_failing_to_authenticate_from_ip.yml +++ b/detections/cloud/o365_multiple_users_failing_to_authenticate_from_ip.yml @@ -1,20 +1,29 @@ name: O365 Multiple Users Failing To Authenticate From Ip id: 8d486e2e-3235-4cfe-ac35-0d042e24ecb4 -version: 2 -date: '2024-03-19' +version: 3 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 UserLoginFailed -description: This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication. -search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed ErrorNumber=50126 - | bucket span=5m _time - | stats dc(user) as unique_accounts values(user) as user values(LogonError) as LogonError values(signature) as signature values(UserAgent) as UserAgent by _time, src_ip - | where unique_accounts > 10 - | `o365_multiple_users_failing_to_authenticate_from_ip_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. +description: The following analytic identifies instances where more than 10 unique + user accounts fail to authenticate from a single IP address within a 5-minute window. + This detection leverages O365 audit logs, specifically Azure Active Directory login + failures (AzureActiveDirectoryStsLogon). Such activity is significant as it may + indicate brute-force attacks or password spraying attempts. If confirmed malicious, + this behavior suggests an external entity is attempting to breach security by targeting + multiple accounts, potentially leading to unauthorized access. Immediate action + is required to block or monitor the suspicious IP and notify affected users to enhance + their security measures. +search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation=UserLoginFailed + ErrorNumber=50126 | bucket span=5m _time | stats dc(user) as unique_accounts values(user) + as user values(LogonError) as LogonError values(signature) as signature values(UserAgent) + as UserAgent by _time, src_ip | where unique_accounts > 10 | `o365_multiple_users_failing_to_authenticate_from_ip_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: A source Ip failing to authenticate with multiple users in + a short period of time is not common legitimate behavior. references: - https://attack.mitre.org/techniques/T1110/003/ - https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray @@ -62,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/o365_multiple_users_from_ip/o365_multiple_users_from_ip.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/o365_multiple_users_from_ip/o365_multiple_users_from_ip.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_new_email_forwarding_rule_created.yml b/detections/cloud/o365_new_email_forwarding_rule_created.yml index 33aad7699c..eb75fa4a3e 100644 --- a/detections/cloud/o365_new_email_forwarding_rule_created.yml +++ b/detections/cloud/o365_new_email_forwarding_rule_created.yml @@ -1,12 +1,19 @@ name: O365 New Email Forwarding Rule Created id: 68469fd0-1315-44ba-b7e4-e92847bb76d6 -version: 1 -date: '2024-03-27' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior. +description: The following analytic identifies the creation of new email forwarding + rules in an Office 365 environment. It detects events logged under New-InboxRule + and Set-InboxRule operations within the o365_management_activity data source, focusing + on parameters like ForwardTo, ForwardAsAttachmentTo, and RedirectTo. This activity + is significant as unauthorized email forwarding can lead to data exfiltration and + unauthorized access to sensitive information. If confirmed malicious, attackers + could intercept and redirect emails, potentially compromising confidential communications + and leading to data breaches. search: >- `o365_management_activity` (Operation=New-InboxRule OR Operation=set-InboxRule) | eval match1=mvfind('Parameters{}.Name', "ForwardTo") @@ -14,12 +21,15 @@ search: >- | eval match3=mvfind('Parameters{}.Name', "RedirectTo") | where match1>= 0 OR match2>= 0 OR match3>= 0 | eval ForwardTo=coalesce(ForwardTo, ForwardAsAttachmentTo, RedirectTo) - | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name by user Operation ForwardTo + | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name + by user Operation ForwardTo | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_new_email_forwarding_rule_created_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Users may create email forwarding rules for legitimate purposes. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Users may create email forwarding rules for legitimate purposes. + Filter as needed. references: - https://attack.mitre.org/techniques/T1114/003/ tags: @@ -28,7 +38,7 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: A forwarding email inbox rule was created for $user$ + message: A forwarding email inbox rule was created for $user$ mitre_attack_id: - T1114 - T1114.003 @@ -53,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_email_forwarding_rule_created/o365_email_forwarding_rule_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_email_forwarding_rule_created/o365_email_forwarding_rule_created.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_new_email_forwarding_rule_enabled.yml b/detections/cloud/o365_new_email_forwarding_rule_enabled.yml index f4c948908d..d11d1a2f55 100644 --- a/detections/cloud/o365_new_email_forwarding_rule_enabled.yml +++ b/detections/cloud/o365_new_email_forwarding_rule_enabled.yml @@ -1,15 +1,21 @@ name: O365 New Email Forwarding Rule Enabled id: ac7c4d0a-06a3-4278-aa59-88a5e537f981 -version: 1 -date: '2024-03-28' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format. +description: The following analytic identifies the creation of new email forwarding + rules in an Office 365 environment via the UpdateInboxRules operation. It leverages + Office 365 management activity events to detect rules that forward emails to external + recipients by examining the OperationProperties for specific forwarding actions. + This activity is significant as it may indicate unauthorized email redirection, + potentially leading to data exfiltration. If confirmed malicious, attackers could + intercept sensitive communications, leading to data breaches and information leakage. search: >- - `o365_management_activity` Workload=Exchange Operation=UpdateInboxRules - | eval match1=mvfind('OperationProperties{}.Value', "ForwardToRecipientsAction") + `o365_management_activity` Workload=Exchange Operation=UpdateInboxRules | eval + match1=mvfind('OperationProperties{}.Value', "ForwardToRecipientsAction") | eval match2=mvfind('OperationProperties{}.Value', "ForwardAsAttachmentToRecipientsAction") | eval match3=mvfind('OperationProperties{}.Value', "RedirectToRecipientsAction") | eval index = mvfind('OperationProperties{}.Name', "ServerRule") @@ -18,15 +24,19 @@ search: >- | spath input=ServerRule path=Actions{}.Recipients{}.Values{}.Value output=valueExtracted | mvexpand valueExtracted | search valueExtracted="*@*.*" - | eval ForwardTo=if(match(valueExtracted, "^[^@]+@[^@]+\\.[^@]+$"), valueExtracted, null) + | eval ForwardTo=if(match(valueExtracted, "^[^@]+@[^@]+\\.[^@]+$"), valueExtracted, + null) | dedup ForwardTo | where isnotnull(ForwardTo) - | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name by user Operation ForwardTo + | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name + by user Operation ForwardTo | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_new_email_forwarding_rule_enabled_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Users may create email forwarding rules for legitimate purposes. Filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Users may create email forwarding rules for legitimate purposes. + Filter as needed. references: - https://attack.mitre.org/techniques/T1114/003/ tags: @@ -35,7 +45,7 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: A forwarding email inbox rule was created for $user$ + message: A forwarding email inbox rule was created for $user$ mitre_attack_id: - T1114 - T1114.003 @@ -59,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_email_forwarding_rule_created/o365_email_forwarding_rule_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.003/o365_email_forwarding_rule_created/o365_email_forwarding_rule_created.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_new_federated_domain_added.yml b/detections/cloud/o365_new_federated_domain_added.yml index 8094d4ba8e..f52ee289bb 100644 --- a/detections/cloud/o365_new_federated_domain_added.yml +++ b/detections/cloud/o365_new_federated_domain_added.yml @@ -1,12 +1,19 @@ name: O365 New Federated Domain Added id: e155876a-6048-11eb-ae93-0242ac130002 -version: 3 -date: '2023-08-02' +version: 4 +date: '2024-05-28' author: Rod Soto, Mauricio Velazco Splunk status: production type: TTP -description: The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach. -data_source: +description: The following analytic identifies the addition of a new federated domain + in an Office 365 environment. This behavior is detected by analyzing Office 365 + management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". + The addition of a new federated domain is significant as it may indicate unauthorized + changes or potential compromises. If confirmed malicious, attackers could establish + a backdoor, bypass security measures, or exfiltrate data, leading to data breaches + and unauthorized access to sensitive information. Immediate investigation is required + to review the details of the added domain and any concurrent suspicious activities. +data_source: - O365 search: '`o365_management_activity` Operation IN ("*add*", "*new*") AND Operation="*domain*" | stats count values(ModifiedProperties{}.NewValue) as new_value by user user_agent @@ -57,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_new_federated_domain_added/o365_add_federated_domain.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/o365_new_federated_domain_added/o365_add_federated_domain.log sourcetype: o365:management:activity source: o365 update_timestamp: true diff --git a/detections/cloud/o365_new_forwarding_mailflow_rule_created.yml b/detections/cloud/o365_new_forwarding_mailflow_rule_created.yml index 537d8e423b..3abb02e02f 100644 --- a/detections/cloud/o365_new_forwarding_mailflow_rule_created.yml +++ b/detections/cloud/o365_new_forwarding_mailflow_rule_created.yml @@ -1,26 +1,32 @@ name: O365 New Forwarding Mailflow Rule Created id: 289ed0a1-4c78-4a43-9321-44ea2e089c14 -version: 1 -date: '2024-04-10' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification. -search: >- +description: The following analytic detects the creation of new mail flow rules in + Office 365 that may redirect or copy emails to unauthorized or external addresses. + It leverages Office 365 Management Activity logs, specifically querying for the + "New-TransportRule" operation and parameters like "BlindCopyTo", "CopyTo", and "RedirectMessageTo". + This activity is significant as it can indicate potential data exfiltration or unauthorized + access to sensitive information. If confirmed malicious, attackers could intercept + or redirect email communications, leading to data breaches or information leakage. +search: >- `o365_management_activity` Workload=Exchange Operation="New-TransportRule" | eval match1=mvfind('Parameters{}.Name', "BlindCopyTo") | eval match2=mvfind('Parameters{}.Name', "CopyTo") | eval match3=mvfind('Parameters{}.Name', "RedirectMessageTo") | where match1>= 0 OR match2>= 0 OR match3>=0 | eval ForwardTo=coalesce(BlindCopyTo, CopyTo, RedirectMessageTo) - | search ForwardTo!="" - | rename UserId as user - | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, user, Name, ForwardTo | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_new_forwarding_mailflow_rule_created_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Forwarding mail flow rules may be created for legitimate reasons, filter as needed. + | search ForwardTo!="" | rename UserId as user | stats count earliest(_time) as + firstTime latest(_time) as lastTime by Operation, user, Name, ForwardTo | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `o365_new_forwarding_mailflow_rule_created_filter` +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Forwarding mail flow rules may be created for legitimate reasons, + filter as needed. references: - https://attack.mitre.org/techniques/T1114/ - https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules @@ -54,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114/o365_new_forwarding_mailflow_rule_created/o365_new_forwarding_mailflow_rule_created.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114/o365_new_forwarding_mailflow_rule_created/o365_new_forwarding_mailflow_rule_created.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_new_mfa_method_registered.yml b/detections/cloud/o365_new_mfa_method_registered.yml index 3fdcbf3824..29478235b8 100644 --- a/detections/cloud/o365_new_mfa_method_registered.yml +++ b/detections/cloud/o365_new_mfa_method_registered.yml @@ -1,16 +1,22 @@ name: O365 New MFA Method Registered id: 4e12db1f-f7c7-486d-8152-a221cad6ac2b -version: 1 -date: '2023-10-20' +version: 2 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Update user. -description: This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +description: The following analytic detects the registration of a new Multi-Factor + Authentication (MFA) method for a user account within Office 365. It leverages O365 + audit logs to identify changes in MFA configurations. This activity is significant + as it may indicate an attacker's attempt to maintain persistence on a compromised + account. If confirmed malicious, the attacker could bypass existing security measures, + solidify their access, and potentially escalate privileges or access sensitive data. + Immediate verification and remediation are required to secure the affected account. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Update user." - | eval propertyName = mvindex('ModifiedProperties{}.Name', 0) + `o365_management_activity` Workload=AzureActiveDirectory Operation="Update user." | + eval propertyName = mvindex('ModifiedProperties{}.Name', 0) | search propertyName = StrongAuthenticationMethod | eval oldvalue = mvindex('ModifiedProperties{}.OldValue',0) | eval newvalue = mvindex('ModifiedProperties{}.NewValue',0) @@ -19,12 +25,15 @@ search: >- | eval count_new_method_type = coalesce(mvcount(new_method_type), 0) | eval count_old_method_type = coalesce(mvcount(old_method_type), 0) | where count_new_method_type > count_old_method_type - | stats earliest(_time) as firstTime latest(_time) as lastTime values(propertyName) by user newvalue oldvalue + | stats earliest(_time) as firstTime latest(_time) as lastTime values(propertyName) + by user newvalue oldvalue | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_new_mfa_method_registered_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Users may register MFA methods legitimally, investigate and filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Users may register MFA methods legitimally, investigate and + filter as needed. references: - https://attack.mitre.org/techniques/T1098/005/ - https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/ @@ -60,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/o365_register_new_mfa_method/o365_register_new_mfa_method.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/o365_register_new_mfa_method/o365_register_new_mfa_method.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_oauth_app_mailbox_access_via_ews.yml b/detections/cloud/o365_oauth_app_mailbox_access_via_ews.yml index 3dc01e51c2..7f866b4325 100644 --- a/detections/cloud/o365_oauth_app_mailbox_access_via_ews.yml +++ b/detections/cloud/o365_oauth_app_mailbox_access_via_ews.yml @@ -1,21 +1,29 @@ name: O365 OAuth App Mailbox Access via EWS id: e600cf1a-0bef-4426-b42e-00176d610a4d -version: 1 -date: '2024-01-31' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production -data_source: +data_source: - O365 MailItemsAccessed type: TTP -description: The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access. -search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* ClientAppId=* - | regex ClientInfoString="^Client=WebServices;ExchangeWebServices" - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ClientIPAddress) as src_ip by user ClientAppId OperationCount AppId ClientInfoString - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_oauth_app_mailbox_access_via_ews_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: OAuth applications may access mailboxes for legitimate purposes, you can use the src_ip to add trusted sources to an allow list. +description: The following analytic detects when emails are accessed in Office 365 + Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. + It leverages the ClientInfoString field to identify EWS interactions and aggregates + metrics such as access counts, timing, and client IP addresses, categorized by user, + ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing + emails through EWS is crucial for identifying potential abuse or unauthorized data + access. If confirmed malicious, this activity could lead to unauthorized email access, + data exfiltration, or further compromise of sensitive information. +search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed + AppId=* ClientAppId=* | regex ClientInfoString="^Client=WebServices;ExchangeWebServices" + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ClientIPAddress) + as src_ip by user ClientAppId OperationCount AppId ClientInfoString | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `o365_oauth_app_mailbox_access_via_ews_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: OAuth applications may access mailboxes for legitimate purposes, + you can use the src_ip to add trusted sources to an allow list. references: - https://attack.mitre.org/techniques/T1114/002/ - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ @@ -27,7 +35,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: An OAuth application identified with id $ClientAppId$ accesed mailboxes through the Graph API. + message: An OAuth application identified with id $ClientAppId$ accesed mailboxes + through the Graph API. mitre_attack_id: - T1114.002 observable: @@ -51,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_oauth_app_ews_mailbox_access/o365_oauth_app_ews_mailbox_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_oauth_app_ews_mailbox_access/o365_oauth_app_ews_mailbox_access.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_oauth_app_mailbox_access_via_graph_api.yml b/detections/cloud/o365_oauth_app_mailbox_access_via_graph_api.yml index bf879f39f6..bd66c03848 100644 --- a/detections/cloud/o365_oauth_app_mailbox_access_via_graph_api.yml +++ b/detections/cloud/o365_oauth_app_mailbox_access_via_graph_api.yml @@ -1,20 +1,28 @@ name: O365 OAuth App Mailbox Access via Graph API id: 9db0d5b0-4058-4cb7-baaf-77d8143539a2 -version: 1 -date: '2024-01-31' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Splunk status: production -data_source: +data_source: - O365 MailItemsAccessed type: TTP -description: This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns. -search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* AppId=00000003-0000-0000-c000-000000000000 - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ClientIPAddress) by user ClientAppId OperationCount AppId - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects when emails are accessed in Office 365 + Exchange via the Microsoft Graph API using the client ID '00000003-0000-0000-c000-000000000000'. + It leverages the 'MailItemsAccessed' operation within the Exchange workload, focusing + on OAuth-authenticated applications. This activity is significant as unauthorized + access to emails can lead to data breaches and information theft. If confirmed malicious, + attackers could exfiltrate sensitive information, compromise user accounts, and + further infiltrate the organization’s network. +search: ' `o365_management_activity` Workload=Exchange Operation=MailItemsAccessed + AppId=* AppId=00000003-0000-0000-c000-000000000000 | stats count earliest(_time) + as firstTime latest(_time) as lastTime values(ClientIPAddress) by user ClientAppId + OperationCount AppId | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_oauth_app_mailbox_access_via_graph_api_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: OAuth applications may access mailboxes for legitimate purposes, you can use the ClientAppId to add trusted applications to an allow list. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: OAuth applications may access mailboxes for legitimate purposes, + you can use the ClientAppId to add trusted applications to an allow list. references: - https://attack.mitre.org/techniques/T1114/002/ - https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in @@ -26,7 +34,8 @@ tags: asset_type: O365 Tenant confidence: 60 impact: 70 - message: An OAuth application identified with id $ClientAppId$ accesed mailboxes through the Graph API. + message: An OAuth application identified with id $ClientAppId$ accesed mailboxes + through the Graph API. mitre_attack_id: - T1114.002 observable: @@ -50,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_oauth_app_graph_mailbox_access/o365_oauth_app_graph_mailbox_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114.002/o365_oauth_app_graph_mailbox_access/o365_oauth_app_graph_mailbox_access.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_privileged_graph_api_permission_assigned.yml b/detections/cloud/o365_privileged_graph_api_permission_assigned.yml index 49c9ba456e..b122535a63 100644 --- a/detections/cloud/o365_privileged_graph_api_permission_assigned.yml +++ b/detections/cloud/o365_privileged_graph_api_permission_assigned.yml @@ -1,25 +1,36 @@ name: O365 Privileged Graph API Permission Assigned id: 868f3131-d5e1-4bf1-af5b-9b0fbaaaedbb -version: 1 -date: '2024-01-30' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Update application. -description: This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications. +description: The following analytic detects the assignment of critical Graph API permissions + in Azure AD using the O365 Unified Audit Log. It focuses on permissions such as + Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. + The detection method leverages Azure Active Directory workload events, specifically + 'Update application' operations. This activity is significant as these permissions + provide extensive control over Azure AD settings, posing a high risk if misused. + If confirmed malicious, this could allow unauthorized modifications, leading to + potential data breaches or privilege escalation. Immediate investigation is crucial. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Update application." - | eval newvalue = mvindex('ModifiedProperties{}.NewValue',0) - | spath input=newvalue - | search "{}.RequiredAppPermissions{}.EntitlementId"="1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9" OR "{}.RequiredAppPermissions{}.EntitlementId"="06b708a9-e830-4db3-a914-8e69da51d44f" OR "{}.RequiredAppPermissions{}.EntitlementId"="9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" - | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' - | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) by user, object, user_agent, Operation - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_privileged_graph_api_permission_assigned_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. + `o365_management_activity` Workload=AzureActiveDirectory Operation="Update application." + | eval newvalue = mvindex('ModifiedProperties{}.NewValue',0) + | spath input=newvalue | search "{}.RequiredAppPermissions{}.EntitlementId"="1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9" + OR "{}.RequiredAppPermissions{}.EntitlementId"="06b708a9-e830-4db3-a914-8e69da51d44f" + OR "{}.RequiredAppPermissions{}.EntitlementId"="9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" | + eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' + | stats count earliest(_time) as firstTime latest(_time) as lastTime values(Permissions) + by user, object, user_agent, Operation + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `o365_privileged_graph_api_permission_assigned_filter` +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Privileged Graph API permissions may be assigned for legitimate + purposes. Filter as needed. references: - https://cloudbrothers.info/en/azure-attack-paths/ - https://github.com/mandiant/Mandiant-Azure-AD-Investigator/blob/master/MandiantAzureADInvestigator.json @@ -60,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_privileged_graph_perm_assigned/o365_privileged_graph_perm_assigned.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_privileged_graph_perm_assigned/o365_privileged_graph_perm_assigned.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_pst_export_alert.yml b/detections/cloud/o365_pst_export_alert.yml index 099bcb420b..d6aa52da7a 100644 --- a/detections/cloud/o365_pst_export_alert.yml +++ b/detections/cloud/o365_pst_export_alert.yml @@ -1,12 +1,20 @@ name: O365 PST export alert id: 5f694cc4-a678-4a60-9410-bffca1b647dc -version: 2 -date: '2020-12-16' +version: 3 +date: '2024-05-16' author: Rod Soto, Splunk status: production type: TTP -description: This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions. -data_source: +description: The following analytic detects instances where a user has initiated an + eDiscovery search or exported a PST file in an Office 365 environment. It leverages + Office 365 management activity logs, specifically filtering for events under ThreatManagement + with the name "eDiscovery search started or exported." This activity is significant + as it may indicate data exfiltration attempts or unauthorized access to sensitive + information. If confirmed malicious, it suggests an attacker or insider threat is + attempting to gather or exfiltrate data, potentially leading to data breaches, loss + of intellectual property, or unauthorized access to confidential communications. + Immediate investigation is required. +data_source: - O365 search: '`o365_management_activity` Category=ThreatManagement Name="eDiscovery search started or exported" | stats count earliest(_time) as firstTime latest(_time) as @@ -51,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114/o365_export_pst_file/o365_export_pst_file.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1114/o365_export_pst_file/o365_export_pst_file.json sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_security_and_compliance_alert_triggered.yml b/detections/cloud/o365_security_and_compliance_alert_triggered.yml index a927ab4ea4..814038f5f3 100644 --- a/detections/cloud/o365_security_and_compliance_alert_triggered.yml +++ b/detections/cloud/o365_security_and_compliance_alert_triggered.yml @@ -1,26 +1,33 @@ name: O365 Security And Compliance Alert Triggered id: 5b367cdd-8dfc-49ac-a9b7-6406cf27f33e -version: 1 -date: '2024-03-25' +version: 2 +date: '2024-05-09' author: Mauricio Velazco, Splunk data_source: [] type: TTP status: production -description: The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace. -search: ' `o365_management_activity` Workload=SecurityComplianceCenter Category=ThreatManagement Operation=AlertTriggered - | spath input=Data path=f3u output=user - | spath input=Data path=op output=operation | spath input=_raw path=wl - | spath input=Data path=rid output=rule_id - | spath input=Data path=ad output=alert_description - | spath input=Data path=lon output=operation_name - | spath input=Data path=an output=alert_name - | spath input=Data path=sev output=severity - | stats count earliest(_time) as firstTime latest(_time) as lastTime by user, Name, operation, rule_id, alert_description, alert_name, severity - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies alerts triggered by the Office 365 + Security and Compliance Center, indicating potential threats or policy violations. + It leverages data from the `o365_management_activity` dataset, focusing on events + where the workload is SecurityComplianceCenter and the operation is AlertTriggered. + This activity is significant as it highlights security and compliance issues within + the O365 environment, which are crucial for maintaining organizational security. + If confirmed malicious, these alerts could indicate attempts to breach security + policies, leading to unauthorized access, data exfiltration, or other malicious + activities. +search: ' `o365_management_activity` Workload=SecurityComplianceCenter Category=ThreatManagement + Operation=AlertTriggered | spath input=Data path=f3u output=user | spath input=Data + path=op output=operation | spath input=_raw path=wl | spath input=Data path=rid + output=rule_id | spath input=Data path=ad output=alert_description | spath input=Data + path=lon output=operation_name | spath input=Data path=an output=alert_name | spath + input=Data path=sev output=severity | stats count earliest(_time) as firstTime + latest(_time) as lastTime by user, Name, operation, rule_id, alert_description, + alert_name, severity | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_security_and_compliance_alert_triggered_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: O365 Security and Compliance may also generate false positives or trigger on legitimate behavior, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: O365 Security and Compliance may also generate false positives + or trigger on legitimate behavior, filter as needed. references: - https://attack.mitre.org/techniques/T1078/004/ - https://learn.microsoft.com/en-us/purview/alert-policies?view=o365-worldwide @@ -56,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/o365_security_and_compliance_alert_triggered/o365_security_and_compliance_alert_triggered.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/o365_security_and_compliance_alert_triggered/o365_security_and_compliance_alert_triggered.log sourcetype: o365:management:activity source: o365 diff --git a/detections/cloud/o365_service_principal_new_client_credentials.yml b/detections/cloud/o365_service_principal_new_client_credentials.yml index 1652e26b56..4dd03b4f3c 100644 --- a/detections/cloud/o365_service_principal_new_client_credentials.yml +++ b/detections/cloud/o365_service_principal_new_client_credentials.yml @@ -1,29 +1,33 @@ name: O365 Service Principal New Client Credentials id: a1b229e9-d962-4222-8c62-905a8a010453 -version: 1 -date: '2023-08-31' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies the addition of new credentials for Service - Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. - Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent - If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application -data_source: +description: The following analytic detects the addition of new credentials for Service + Principals within an Office 365 tenant. It uses O365 audit logs, focusing on events + related to credential modifications or additions in the AzureActiveDirectory workload. + This activity is significant because Service Principals represent application identities, + and their credentials allow applications to authenticate and access resources. If + an attacker successfully adds or modifies these credentials, they can impersonate + the application, leading to unauthorized data access, data exfiltration, or malicious + operations under the application's identity. +data_source: - O365 -search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation="Update application*Certificates and secrets management " - | stats earliest(_time) as firstTime latest(_time) as lastTime by user ModifiedProperties{}.NewValue object ObjectId - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `o365_service_principal_new_client_credentials_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. +search: ' `o365_management_activity` Workload=AzureActiveDirectory Operation="Update + application*Certificates and secrets management " | stats earliest(_time) as firstTime + latest(_time) as lastTime by user ModifiedProperties{}.NewValue object ObjectId + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_service_principal_new_client_credentials_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. known_false_positives: Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/001/ - https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 -- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ -- https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Cloud%20-%20Azure%20Pentest.md#add-credentials-to-all-enterprise-applications +- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ +- https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Cloud%20-%20Azure%20Pentest.md#add-credentials-to-all-enterprise-applications tags: analytic_story: - Office 365 Persistence Mechanisms @@ -59,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/o365_service_principal_credentials/o365_service_principal_credentials.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/o365_service_principal_credentials/o365_service_principal_credentials.log sourcetype: o365:management:activity - source: o365 \ No newline at end of file + source: o365 diff --git a/detections/cloud/o365_tenant_wide_admin_consent_granted.yml b/detections/cloud/o365_tenant_wide_admin_consent_granted.yml index b0ea78c553..8b5a9bc611 100644 --- a/detections/cloud/o365_tenant_wide_admin_consent_granted.yml +++ b/detections/cloud/o365_tenant_wide_admin_consent_granted.yml @@ -1,31 +1,39 @@ name: O365 Tenant Wide Admin Consent Granted id: 50eaabf8-5180-4e86-bfb2-011472c359fc -version: 1 -date: '2023-09-06' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Consent to application. -description: The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +description: The following analytic identifies instances where admin consent is granted + to an application within an Azure AD and Office 365 tenant. It leverages O365 audit + logs, specifically events related to the admin consent action within the AzureActiveDirectory + workload. This activity is significant because admin consent allows applications + to access data across the entire tenant, potentially exposing vast amounts of organizational + data. If confirmed malicious, an attacker could gain extensive and persistent access + to organizational data, leading to data exfiltration, espionage, further malicious + activities, and potential compliance violations. search: >- - `o365_management_activity` Operation="Consent to application." - | eval new_field=mvindex('ModifiedProperties{}.NewValue', 4) + `o365_management_activity` Operation="Consent to application." | eval new_field=mvindex('ModifiedProperties{}.NewValue', + 4) | rex field=new_field "ConsentType: (?[^\,]+)" - | rex field=new_field "Scope: (?[^\,]+)" - | search ConsentType = "AllPrincipals" - | stats count min(_time) as firstTime max(_time) as lastTime by Operation, user, object, ObjectId, ConsentType, Scope - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | rex field=new_field "Scope: (?[^\,]+)" | search ConsentType = "AllPrincipals" | + stats count min(_time) as firstTime max(_time) as lastTime by Operation, user, object, + ObjectId, ConsentType, Scope + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_tenant_wide_admin_consent_granted_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Legitimate applications may be granted tenant wide consent, filter as needed. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Legitimate applications may be granted tenant wide consent, + filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ - https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 - https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent - https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal -- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ +- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ tags: analytic_story: - Office 365 Persistence Mechanisms @@ -58,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_admin_consent/o365_admin_consent.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/o365_admin_consent/o365_admin_consent.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_user_consent_blocked_for_risky_application.yml b/detections/cloud/o365_user_consent_blocked_for_risky_application.yml index 43d2d1bd02..5ff69a0f26 100644 --- a/detections/cloud/o365_user_consent_blocked_for_risky_application.yml +++ b/detections/cloud/o365_user_consent_blocked_for_risky_application.yml @@ -1,15 +1,24 @@ name: O365 User Consent Blocked for Risky Application id: 242e4d30-cb59-4051-b0cf-58895e218f40 -version: 1 -date: '2023-10-11' +version: 2 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 Consent to application. -description: The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +description: The following analytic identifies instances where Office 365 has blocked + a user's attempt to grant consent to an application deemed risky or potentially + malicious. This detection leverages O365 audit logs, specifically focusing on failed + user consent actions due to system-driven blocks. Monitoring these blocked consent + attempts is crucial as it highlights potential threats early on, indicating that + a user might be targeted or that malicious applications are attempting to infiltrate + the organization. If confirmed malicious, this activity suggests that O365's security + measures successfully prevented a harmful application from accessing organizational + data, warranting immediate investigation. search: >- - `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." ResultStatus=Failure + `o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." + ResultStatus=Failure | eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) | eval reason =mvindex('ModifiedProperties{}.NewValue', 5) | search reason = "Risky application detected" @@ -17,8 +26,10 @@ search: >- | stats max(_time) as lastTime by Operation, user, reason, object, Scope | `security_content_ctime(lastTime)` | `o365_user_consent_blocked_for_risky_application_filter` -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. -known_false_positives: Microsofts algorithm to identify risky applications is unknown and may flag legitimate applications. +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 management activity events. +known_false_positives: Microsofts algorithm to identify risky applications is unknown + and may flag legitimate applications. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -32,7 +43,8 @@ tags: asset_type: O365 Tenant confidence: 100 impact: 30 - message: O365 has blocked $user$ attempt to grant to consent to an application deemed risky. + message: O365 has blocked $user$ attempt to grant to consent to an application deemed + risky. mitre_attack_id: - T1528 observable: @@ -57,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_blocked/o365_user_consent_blocked.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_blocked/o365_user_consent_blocked.log source: o365 sourcetype: o365:management:activity diff --git a/detections/cloud/o365_user_consent_denied_for_oauth_application.yml b/detections/cloud/o365_user_consent_denied_for_oauth_application.yml index ddf43b50a4..f38efad892 100644 --- a/detections/cloud/o365_user_consent_denied_for_oauth_application.yml +++ b/detections/cloud/o365_user_consent_denied_for_oauth_application.yml @@ -1,21 +1,28 @@ name: O365 User Consent Denied for OAuth Application id: 2d8679ef-b075-46be-8059-c25116cb1072 -version: 1 -date: '2023-10-12' +version: 2 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: +data_source: - O365 -description: The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. -search: ' `o365_graph` status.errorCode=65004 - | rename userPrincipalName as user - | rename ipAddress as src_ip - | stats max(_time) as lastTime by user src_ip appDisplayName status.failureReason - | `security_content_ctime(lastTime)` - | `o365_user_consent_denied_for_oauth_application_filter`' -how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 events. -known_false_positives: OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. +description: The following analytic identifies instances where a user has denied consent + to an OAuth application seeking permissions within the Office 365 environment. This + detection leverages O365 audit logs, focusing on events related to user consent + actions. By filtering for denied consent actions associated with OAuth applications, + it captures instances where users have actively rejected permission requests. This + activity is significant as it may indicate users spotting potentially suspicious + or unfamiliar applications. If confirmed malicious, it suggests an attempt by a + potentially harmful application to gain unauthorized access, which was proactively + blocked by the user. +search: ' `o365_graph` status.errorCode=65004 | rename userPrincipalName as user | + rename ipAddress as src_ip | stats max(_time) as lastTime by user src_ip appDisplayName + status.failureReason | `security_content_ctime(lastTime)` | `o365_user_consent_denied_for_oauth_application_filter`' +how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest + Office 365 events. +known_false_positives: OAuth applications that require mail permissions may be legitimate, + investigate and filter as needed. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -56,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_declined/o365_user_consent_declined.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/o365_user_consent_declined/o365_user_consent_declined.log source: o365 sourcetype: o365:graph:api diff --git a/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml b/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml index 9d0f037175..e1746bf9b1 100644 --- a/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml +++ b/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml @@ -1,15 +1,24 @@ name: Risk Rule for Dev Sec Ops by Repository id: 161bc0ca-4651-4c13-9c27-27770660cf67 -version: 1 -date: '2023-10-27' +version: 2 +date: '2024-05-24' author: Bhavin Patel status: production type: Correlation description: |- - The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts. + The following analytic identifies high-risk activities within repositories by correlating repository data with risk scores. It leverages risk events from the Dev Sec Ops analytic stories, summing risk scores and capturing source and user information. The detection focuses on high-risk scores above 100 and sources with more than three occurrences. This activity is significant as it highlights repositories frequently targeted by threats, providing insights into potential vulnerabilities. If confirmed malicious, attackers could exploit these repositories, leading to data breaches or infrastructure compromise. data_source: [] -search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime sum(All_Risk.calculated_risk_score) as sum_risk_score, values(All_Risk.annotations.mitre_attack.mitre_tactic) as annotations.mitre_attack.mitre_tactic, 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(source) as source, dc(source) as source_count from datamodel=Risk.All_Risk where All_Risk.analyticstories="Dev Sec Ops" All_Risk.risk_object_type = "other" by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic | `drop_dm_object_name(All_Risk)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where source_count > 3 and sum_risk_score > 100 | `risk_rule_for_dev_sec_ops_by_repository_filter`' -how_to_implement: Ensure that all relevant detections in the Dev Sec Ops analytic stories are enabled and are configured to create risk events in Enterprise Security. +search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) + as lastTime sum(All_Risk.calculated_risk_score) as sum_risk_score, values(All_Risk.annotations.mitre_attack.mitre_tactic) + as annotations.mitre_attack.mitre_tactic, 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(source) as source, dc(source) as source_count + from datamodel=Risk.All_Risk where All_Risk.analyticstories="Dev Sec Ops" All_Risk.risk_object_type + = "other" by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic + | `drop_dm_object_name(All_Risk)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | where source_count > 3 and sum_risk_score > 100 | `risk_rule_for_dev_sec_ops_by_repository_filter`' +how_to_implement: Ensure that all relevant detections in the Dev Sec Ops analytic + stories are enabled and are configured to create risk events in Enterprise Security. known_false_positives: Unknown references: [] tags: @@ -38,6 +47,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1204.003/risk_dataset/aws_ecr_risk_dataset.log + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1204.003/risk_dataset/aws_ecr_risk_dataset.log source: aws_ecr_risk_dataset.log sourcetype: stash diff --git a/detections/deprecated/clients_connecting_to_multiple_dns_servers.yml b/detections/deprecated/clients_connecting_to_multiple_dns_servers.yml index 02add903d3..ad4302443a 100644 --- a/detections/deprecated/clients_connecting_to_multiple_dns_servers.yml +++ b/detections/deprecated/clients_connecting_to_multiple_dns_servers.yml @@ -11,7 +11,7 @@ data_source: [] search: '| tstats `security_content_summariesonly` count, values(DNS.dest) AS dest dc(DNS.dest) as dest_count from datamodel=Network_Resolution where DNS.message_type=QUERY by DNS.src | `drop_dm_object_name("Network_Resolution")` |where dest_count > 5 | - `clients_connecting_to_multiple_dns_servers_filter` ' + `clients_connecting_to_multiple_dns_servers_filter`' how_to_implement: 'This search requires that DNS data is being ingested and populating the `Network_Resolution` data model. This data can come from DNS logs or from solutions that parse network traffic for this data, such as Splunk Stream or Bro. diff --git a/detections/deprecated/dns_query_requests_resolved_by_unauthorized_dns_servers.yml b/detections/deprecated/dns_query_requests_resolved_by_unauthorized_dns_servers.yml index 9dc6f0de3f..078029a1fe 100644 --- a/detections/deprecated/dns_query_requests_resolved_by_unauthorized_dns_servers.yml +++ b/detections/deprecated/dns_query_requests_resolved_by_unauthorized_dns_servers.yml @@ -11,7 +11,7 @@ description: This search will detect DNS requests resolved by unauthorized DNS s data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Network_Resolution where DNS.dest_category != dns_server AND DNS.src_category != dns_server by DNS.src - DNS.dest | `drop_dm_object_name("DNS")` | `dns_query_requests_resolved_by_unauthorized_dns_servers_filter` ' + DNS.dest | `drop_dm_object_name("DNS")` | `dns_query_requests_resolved_by_unauthorized_dns_servers_filter`' how_to_implement: To successfully implement this search you will need to ensure that DNS data is populating the Network_Resolution data model. It also requires that your DNS servers are identified correctly in the Assets and Identity table of Enterprise diff --git a/detections/deprecated/first_time_seen_command_line_argument.yml b/detections/deprecated/first_time_seen_command_line_argument.yml index 3094fd5e77..3e63b16ad4 100644 --- a/detections/deprecated/first_time_seen_command_line_argument.yml +++ b/detections/deprecated/first_time_seen_command_line_argument.yml @@ -20,7 +20,7 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_ | stats min(firstTime) as firstTime, max(lastTime) as lastTime by process | outputlookup previously_seen_cmd_line_arguments | eval newCmdLineArgument=if(firstTime >= relative_time(now(), "-70m@m"), 1, 0) | where newCmdLineArgument=1 | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | table process] | `first_time_seen_command_line_argument_filter` ' + | `security_content_ctime(lastTime)` | table process] | `first_time_seen_command_line_argument_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/deprecated/gcp_kubernetes_cluster_scan_detection.yml b/detections/deprecated/gcp_kubernetes_cluster_scan_detection.yml index c0c0eb2e9d..8639f1dc7a 100644 --- a/detections/deprecated/gcp_kubernetes_cluster_scan_detection.yml +++ b/detections/deprecated/gcp_kubernetes_cluster_scan_detection.yml @@ -16,7 +16,7 @@ search: '`google_gcp_pubsub_message` data.protoPayload.requestMetadata.callerIp! values(data.protoPayload.resourceName) as resource_name values(data.protoPayload.requestMetadata.callerSuppliedUserAgent) as http_user_agent by src_ip data.resource.labels.cluster_name | rename data.resource.labels.cluster_name as cluster_name| `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | - `gcp_kubernetes_cluster_scan_detection_filter` ' + `gcp_kubernetes_cluster_scan_detection_filter`' how_to_implement: You must install the GCP App for Splunk (version 2.0.0 or later), then configure stackdriver and set a Pub/Sub subscription to be imported to Splunk. You must also install Cloud Infrastructure data model.Customize the macro kubernetes_gcp_scan_fingerprint_attack_detection diff --git a/detections/deprecated/multiple_okta_users_with_invalid_credentials_from_the_same_ip.yml b/detections/deprecated/multiple_okta_users_with_invalid_credentials_from_the_same_ip.yml index 0c3ed3bfb5..26d54ddf4c 100644 --- a/detections/deprecated/multiple_okta_users_with_invalid_credentials_from_the_same_ip.yml +++ b/detections/deprecated/multiple_okta_users_with_invalid_credentials_from_the_same_ip.yml @@ -17,7 +17,7 @@ search: '`okta` eventType=user.session.start outcome.result=FAILURE | rename cli as city | stats min(_time) as firstTime max(_time) as lastTime dc(src_user) as distinct_users values(src_user) as users by src_ip, displayMessage, outcome.reason, country, state, city | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | search distinct_users > 5| `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter` ' + | search distinct_users > 5| `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter`' how_to_implement: This search is specific to Okta and requires Okta logs are being ingested in your Splunk deployment. known_false_positives: A single public IP address servicing multiple legitmate users diff --git a/detections/deprecated/okta_failed_sso_attempts.yml b/detections/deprecated/okta_failed_sso_attempts.yml index eb18442740..22f2a00260 100644 --- a/detections/deprecated/okta_failed_sso_attempts.yml +++ b/detections/deprecated/okta_failed_sso_attempts.yml @@ -10,7 +10,7 @@ data_source: [] search: '`okta` eventType=app.generic.unauth_app_access_attempt | stats min(_time) as firstTime max(_time) as lastTime values(app) as Apps count by src_user, result ,displayMessage, src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `okta_failed_sso_attempts_filter` ' + | `okta_failed_sso_attempts_filter`' how_to_implement: This search is specific to Okta and requires Okta logs are being ingested in your Splunk deployment. known_false_positives: There may be a faulty config preventing legitmate users from diff --git a/detections/deprecated/prohibited_software_on_endpoint.yml b/detections/deprecated/prohibited_software_on_endpoint.yml index 0ced386a69..19c26ef4b0 100644 --- a/detections/deprecated/prohibited_software_on_endpoint.yml +++ b/detections/deprecated/prohibited_software_on_endpoint.yml @@ -12,7 +12,7 @@ data_source: search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` - | `prohibited_processes` | `prohibited_software_on_endpoint_filter`' + | `prohibited_softwares` | `prohibited_software_on_endpoint_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/deprecated/suspicious_changes_to_file_associations.yml b/detections/deprecated/suspicious_changes_to_file_associations.yml index ade4a24926..1d0f536cf9 100644 --- a/detections/deprecated/suspicious_changes_to_file_associations.yml +++ b/detections/deprecated/suspicious_changes_to_file_associations.yml @@ -18,7 +18,7 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime | join [| tstats `security_content_summariesonly` values(Registry.registry_path) as registry_path count from datamodel=Endpoint.Registry where Registry.registry_path=*\\Explorer\\FileExts* by Registry.process_id Registry.dest | `drop_dm_object_name("Registry")` | table - process_id dest registry_path]| `suspicious_changes_to_file_associations_filter` ' + process_id dest registry_path]| `suspicious_changes_to_file_associations_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/deprecated/uncommon_processes_on_endpoint.yml b/detections/deprecated/uncommon_processes_on_endpoint.yml index e24e18fe44..3332774ef7 100644 --- a/detections/deprecated/uncommon_processes_on_endpoint.yml +++ b/detections/deprecated/uncommon_processes_on_endpoint.yml @@ -12,7 +12,7 @@ data_source: search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `drop_dm_object_name(Processes)` | `uncommon_processes` |`uncommon_processes_on_endpoint_filter` ' + | `drop_dm_object_name(Processes)` | `uncommon_processes` |`uncommon_processes_on_endpoint_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/deprecated/unsigned_image_loaded_by_lsass.yml b/detections/deprecated/unsigned_image_loaded_by_lsass.yml index 9651f6f1c8..51423fd51a 100644 --- a/detections/deprecated/unsigned_image_loaded_by_lsass.yml +++ b/detections/deprecated/unsigned_image_loaded_by_lsass.yml @@ -12,7 +12,7 @@ data_source: search: '`sysmon` EventID=7 Image=*lsass.exe Signed=false | stats count min(_time) as firstTime max(_time) as lastTime by dest, Image, ImageLoaded, Signed, SHA1 | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `unsigned_image_loaded_by_lsass_filter` ' + | `unsigned_image_loaded_by_lsass_filter`' how_to_implement: This search needs Sysmon Logs with a sysmon configuration, which includes EventCode 7 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations diff --git a/detections/endpoint/7zip_commandline_to_smb_share_path.yml b/detections/endpoint/7zip_commandline_to_smb_share_path.yml index eb0a25a225..76c046406f 100644 --- a/detections/endpoint/7zip_commandline_to_smb_share_path.yml +++ b/detections/endpoint/7zip_commandline_to_smb_share_path.yml @@ -1,15 +1,17 @@ name: 7zip CommandLine To SMB Share Path id: 01d29b48-ff6f-11eb-b81e-acde48001123 -version: 1 -date: '2021-08-17' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This search is to detect a suspicious 7z process with commandline pointing - to SMB network share. This technique was seen in CONTI LEAK tools where it use 7z - to archive a sensitive files and place it in network share tmp folder. This search - is a good hunting query that may give analyst a hint why specific user try to archive - a file pointing to SMB user which is un usual. +description: The following analytic detects the execution of 7z or 7za processes with + command lines pointing to SMB network shares. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line arguments. + This activity is significant as it may indicate an attempt to archive and exfiltrate + sensitive files to a network share, a technique observed in CONTI LEAK tools. If + confirmed malicious, this behavior could lead to data exfiltration, compromising + sensitive information and potentially aiding further attacks. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon_7z.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon_7z.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/access_lsass_memory_for_dump_creation.yml b/detections/endpoint/access_lsass_memory_for_dump_creation.yml index 4ff7e38731..04d4d021a0 100644 --- a/detections/endpoint/access_lsass_memory_for_dump_creation.yml +++ b/detections/endpoint/access_lsass_memory_for_dump_creation.yml @@ -1,25 +1,23 @@ name: Access LSASS Memory for Dump Creation id: fb4c31b0-13e8-4155-8aa5-24de4b8d6717 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-13' author: Patrick Bareiss, Splunk status: production type: TTP -description: The following analytic detects the dumping of the LSASS process memory, - which occurs during credential dumping attacks.The detection is made by using Sysmon - logs, specifically EventCode 10, which is related to lsass.exe. This helps to search - for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll - and dbghelp.dll. This detection is important because it prevents credential dumping - attacks and the theft of sensitive information such as login credentials, which - can be used to gain unauthorized access to systems and data. False positives might - occur due to legitimate administrative tasks. Next steps include reviewing and investigating - each case, given the high risk associated with potential credential dumping attacks. +description: The following analytic detects attempts to dump the LSASS process memory, + a common technique in credential dumping attacks. It leverages Sysmon logs, specifically + EventCode 10, to identify suspicious call traces to dbgcore.dll and dbghelp.dll + associated with lsass.exe. This activity is significant as it often precedes the + theft of sensitive login credentials, posing a high risk of unauthorized access + to systems and data. If confirmed malicious, attackers could gain access to critical + credentials, enabling further compromise and lateral movement within the network. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll* | stats count min(_time) as firstTime max(_time) as lastTime by dest, TargetImage, TargetProcessId, SourceImage, SourceProcessId | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `access_lsass_memory_for_dump_creation_filter` ' + `security_content_ctime(lastTime)` | `access_lsass_memory_for_dump_creation_filter`' how_to_implement: This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations @@ -71,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/account_discovery_with_net_app.yml b/detections/endpoint/account_discovery_with_net_app.yml index df82586f50..2f4a8fd313 100644 --- a/detections/endpoint/account_discovery_with_net_app.yml +++ b/detections/endpoint/account_discovery_with_net_app.yml @@ -1,17 +1,18 @@ name: Account Discovery With Net App id: 339805ce-ac30-11eb-b87d-acde48001122 -version: 4 -date: '2023-01-04' +version: 5 +date: '2024-05-22' author: Teoderick Contreras, Splunk, TheLawsOfChaos, Github Community status: production type: TTP -description: This search is to detect a potential account discovery series of command - used by several malware or attack to recon the target machine. This technique is - also seen in some note worthy malware like trickbot where it runs a cmd process, - or even drop its module that will execute the said series of net command. This series - of command are good correlation search and indicator of attacker recon if seen in - the machines within a none technical user or department (HR, finance, ceo and etc) - network. +description: The following analytic detects potential account discovery activities + using the 'net' command, commonly employed by malware like Trickbot for reconnaissance. + It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line + patterns and process relationships. This activity is significant as it often precedes + further malicious actions, such as lateral movement or privilege escalation. If + confirmed malicious, attackers could gain valuable information about user accounts, + enabling them to escalate privileges or move laterally within the network, posing + a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -81,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/active_directory_lateral_movement_identified.yml b/detections/endpoint/active_directory_lateral_movement_identified.yml index f98e28e872..461d0227f5 100644 --- a/detections/endpoint/active_directory_lateral_movement_identified.yml +++ b/detections/endpoint/active_directory_lateral_movement_identified.yml @@ -1,25 +1,45 @@ name: Active Directory Lateral Movement Identified id: 6aa6f9dd-adfe-45a8-8f74-c4c7a0d7d037 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Correlation data_source: [] -description: The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. - The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. - The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. -search: '| 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 All_Risk.analyticstories="Active Directory Lateral Movement" All_Risk.risk_object_type="system" by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where source_count >= 4 - | `active_directory_lateral_movement_identified_filter`' -how_to_implement: 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 as the analytic story includes over 30 analytics. 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 most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. +description: The following analytic identifies potential lateral movement activities + within an organization's Active Directory (AD) environment. It detects this activity + by correlating multiple analytics from the Active Directory Lateral Movement analytic + story within a specified time frame. This is significant for a SOC as lateral movement + is a common tactic used by attackers to expand their access within a network, posing + a substantial risk. If confirmed malicious, this activity could allow attackers + to escalate privileges, access sensitive information, and persist within the environment, + leading to severe security breaches. +search: '| 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 All_Risk.analyticstories="Active + Directory Lateral Movement" All_Risk.risk_object_type="system" by All_Risk.risk_object + All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 4 | `active_directory_lateral_movement_identified_filter`' +how_to_implement: 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 as + the analytic story includes over 30 analytics. 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 most likely be present based on risk scoring + and how the organization handles system to system communication. Filter, or modify + as needed. In addition to count by analytics, adding a risk score may be useful. + In our testing, with 22 events over 30 days, the risk scores ranged from 500 to + 80,000. Your organization will be different, monitor and modify as needed. references: - - https://attack.mitre.org/tactics/TA0008/ - - https://research.splunk.com/stories/active_directory_lateral_movement/ +- https://attack.mitre.org/tactics/TA0008/ +- https://research.splunk.com/stories/active_directory_lateral_movement/ tags: analytic_story: - Active Directory Lateral Movement @@ -53,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/living_off_the_land/adlm_risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/living_off_the_land/adlm_risk.log source: adlm sourcetype: stash diff --git a/detections/endpoint/active_directory_privilege_escalation_identified.yml b/detections/endpoint/active_directory_privilege_escalation_identified.yml index bba5f6ad64..f22fc57f3e 100644 --- a/detections/endpoint/active_directory_privilege_escalation_identified.yml +++ b/detections/endpoint/active_directory_privilege_escalation_identified.yml @@ -1,25 +1,45 @@ name: Active Directory Privilege Escalation Identified id: 583e8a68-f2f7-45be-8fc9-bf725f0e22fd -version: 1 -date: '2023-05-23' +version: 2 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: Correlation data_source: [] -description: The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. - The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. - The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. -search: '| 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 All_Risk.analyticstories="Active Directory Privilege Escalation" All_Risk.risk_object_type="system" by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where source_count >= 4 - | `active_directory_privilege_escalation_identified_filter`' -how_to_implement: 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 as the analytic story includes over 30 analytics. 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 most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. +description: The following analytic identifies potential privilege escalation activities + within an organization's Active Directory (AD) environment. It detects this activity + by correlating multiple analytics from the Active Directory Privilege Escalation + analytic story within a specified time frame. This is significant for a SOC as it + helps identify coordinated attempts to gain elevated privileges, which could indicate + a serious security threat. If confirmed malicious, this activity could allow attackers + to gain unauthorized access to sensitive systems and data, leading to potential + data breaches and further compromise of the network. +search: '| 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 All_Risk.analyticstories="Active + Directory Privilege Escalation" All_Risk.risk_object_type="system" by All_Risk.risk_object + All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 4 | `active_directory_privilege_escalation_identified_filter`' +how_to_implement: 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 as + the analytic story includes over 30 analytics. 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 most likely be present based on risk scoring + and how the organization handles system to system communication. Filter, or modify + as needed. In addition to count by analytics, adding a risk score may be useful. + In our testing, with 22 events over 30 days, the risk scores ranged from 500 to + 80,000. Your organization will be different, monitor and modify as needed. references: - - https://attack.mitre.org/tactics/TA0004/ - - https://research.splunk.com/stories/active_directory_privilege_escalation/ +- https://attack.mitre.org/tactics/TA0004/ +- https://research.splunk.com/stories/active_directory_privilege_escalation/ tags: analytic_story: - Active Directory Privilege Escalation @@ -53,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1484/privesc/priv_esc.log + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1484/privesc/priv_esc.log source: adlm sourcetype: stash diff --git a/detections/endpoint/active_setup_registry_autostart.yml b/detections/endpoint/active_setup_registry_autostart.yml index 6c491ac7b4..203813afd5 100644 --- a/detections/endpoint/active_setup_registry_autostart.yml +++ b/detections/endpoint/active_setup_registry_autostart.yml @@ -1,23 +1,26 @@ name: Active Setup Registry Autostart id: f64579c0-203f-11ec-abcc-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-27' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious modification of the active setup - registry for persistence and privilege escalation. This technique was seen in several - malware (poisonIvy), adware and APT to gain persistence to the compromised machine - upon boot up. This TTP is a good indicator to further check the process id that - do the modification since modification of this registry is not commonly done. check - the legitimacy of the file and process involve in this rules to check if it is a - valid setup installer that creating or modifying this registry. +description: The following analytic detects suspicious modifications to the Active + Setup registry for persistence and privilege escalation. It leverages data from + the Endpoint.Registry data model, focusing on changes to the "StubPath" value within + the "SOFTWARE\\Microsoft\\Active Setup\\Installed Components" path. This activity + is significant as it is commonly used by malware, adware, and APTs to maintain persistence + on compromised machines. If confirmed malicious, this could allow attackers to execute + code upon system startup, potentially leading to further system compromise and unauthorized + access. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_value_name= "StubPath" Registry.registry_path = "*\\SOFTWARE\\Microsoft\\Active Setup\\Installed Components*") BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest Registry.user - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_value_name= "StubPath" Registry.registry_path = "*\\SOFTWARE\\Microsoft\\Active + Setup\\Installed Components*") BY _time span=1h Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + Registry.dest Registry.user | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `active_setup_registry_autostart_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1547.014/active_setup_stubpath/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1547.014/active_setup_stubpath/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/add_defaultuser_and_password_in_registry.yml b/detections/endpoint/add_defaultuser_and_password_in_registry.yml index 919be7da2f..e84b56e1ef 100644 --- a/detections/endpoint/add_defaultuser_and_password_in_registry.yml +++ b/detections/endpoint/add_defaultuser_and_password_in_registry.yml @@ -1,24 +1,29 @@ name: Add DefaultUser And Password In Registry id: d4a3eb62-0f1e-11ec-a971-acde48001122 -version: 4 -date: '2023-03-29' +version: 5 +date: '2024-05-28' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: this search is to detect a suspicious registry modification to implement - auto admin logon to a host. This technique was seen in BlackMatter ransomware to - automatically logon to the compromise host after triggering a safemode boot to - continue encrypting the whole network. This behavior is not a common practice and - really a suspicious TTP or alert need to be consider if found within then network - premise. +description: The following analytic detects suspicious registry modifications that + implement auto admin logon by adding DefaultUserName and DefaultPassword values. + It leverages data from the Endpoint.Registry data model, specifically monitoring + changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry + path. This activity is significant because it is associated with BlackMatter ransomware, + which uses this technique to automatically log on to compromised hosts and continue + encryption after a safe mode boot. If confirmed malicious, this could allow attackers + to maintain persistence and further encrypt the network, leading to significant + data loss and operational disruption. data_source: - Sysmon EventID 1 - Sysmon EventID 13 - Sysmon EventID 14 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*" AND Registry.registry_value_name= DefaultPassword OR Registry.registry_value_name= DefaultUserName) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.dest Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*" + AND Registry.registry_value_name= DefaultPassword OR Registry.registry_value_name= + DefaultUserName) BY _time span=1h Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.dest Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `add_defaultuser_and_password_in_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -60,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/add_or_set_windows_defender_exclusion.yml b/detections/endpoint/add_or_set_windows_defender_exclusion.yml index 9446f58a19..693246971c 100644 --- a/detections/endpoint/add_or_set_windows_defender_exclusion.yml +++ b/detections/endpoint/add_or_set_windows_defender_exclusion.yml @@ -1,16 +1,18 @@ name: Add or Set Windows Defender Exclusion id: 773b66fe-4dd9-11ec-8289-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will identify a suspicious process command-line related - to Windows Defender exclusion feature. This command is abused by adversaries, malware - authors and red teams to bypass Windows Defender Antivirus products by excluding - folder path, file path, process and extensions. From its real time or schedule scan - to execute their malicious code. This is a good indicator for defense evasion and - to look further for events after this behavior. +description: The following analytic detects the use of commands to add or set exclusions + in Windows Defender. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on command-line executions involving "Add-MpPreference" or "Set-MpPreference" + with exclusion parameters. This activity is significant because adversaries often + use it to bypass Windows Defender, allowing malicious code to execute undetected. + If confirmed malicious, this behavior could enable attackers to evade antivirus + detection, maintain persistence, and execute further malicious activities without + interference from Windows Defender. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/defender_exclusion_sysmon/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/defender_exclusion_sysmon/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/adsisearcher_account_discovery.yml b/detections/endpoint/adsisearcher_account_discovery.yml index 63cbb14e05..caeba199f2 100644 --- a/detections/endpoint/adsisearcher_account_discovery.yml +++ b/detections/endpoint/adsisearcher_account_discovery.yml @@ -1,14 +1,18 @@ name: AdsiSearcher Account Discovery id: de7fcadc-04f3-11ec-a241-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-24' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the `[Adsisearcher]` type accelerator being used to query Active Directory - for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate - domain users for situational awareness and Active Directory Discovery. +description: The following analytic detects the use of the `[Adsisearcher]` type accelerator + in PowerShell to query Active Directory for domain users. It leverages PowerShell + Script Block Logging (EventCode=4104) to identify script blocks containing `[adsisearcher]`, + `objectcategory=user`, and `.findAll()`. This activity is significant as it may + indicate an attempt by adversaries or Red Teams to enumerate domain users for situational + awareness and Active Directory discovery. If confirmed malicious, this could lead + to further reconnaissance, privilege escalation, or lateral movement within the + network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*[adsisearcher]*" ScriptBlockText @@ -62,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/adsisearcher_powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/adsisearcher_powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/allow_file_and_printing_sharing_in_firewall.yml b/detections/endpoint/allow_file_and_printing_sharing_in_firewall.yml index baa13cd1cf..1a2a11b37c 100644 --- a/detections/endpoint/allow_file_and_printing_sharing_in_firewall.yml +++ b/detections/endpoint/allow_file_and_printing_sharing_in_firewall.yml @@ -1,13 +1,18 @@ name: Allow File And Printing Sharing In Firewall id: ce27646e-d411-11eb-8a00-acde48001122 -version: 3 -date: '2023-12-15' +version: 4 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious modification of firewall to allow - file and printer sharing. This technique was seen in ransomware to be able to discover - more machine connected to the compromised host to encrypt more files +description: The following analytic detects the modification of firewall settings + to allow file and printer sharing. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command-line executions involving 'netsh' commands + that enable file and printer sharing. This activity is significant because it can + indicate an attempt by ransomware to discover and encrypt files on additional machines + connected to the compromised host. If confirmed malicious, this could lead to widespread + file encryption across the network, significantly increasing the impact of a ransomware + attack. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -38,7 +43,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A suspicious modification of firewall to allow file and printer sharing detected on host - $dest$ + message: A suspicious modification of firewall to allow file and printer sharing + detected on host - $dest$ mitre_attack_id: - T1562.007 - T1562 @@ -73,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/allow_inbound_traffic_by_firewall_rule_registry.yml b/detections/endpoint/allow_inbound_traffic_by_firewall_rule_registry.yml index 818e9a5c0b..ae793efaed 100644 --- a/detections/endpoint/allow_inbound_traffic_by_firewall_rule_registry.yml +++ b/detections/endpoint/allow_inbound_traffic_by_firewall_rule_registry.yml @@ -1,22 +1,28 @@ name: Allow Inbound Traffic By Firewall Rule Registry id: 0a46537c-be02-11eb-92ca-acde48001122 -version: 5 -date: '2023-03-29' +version: 6 +date: '2024-05-22' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects a potential suspicious modification of firewall - rule registry allowing inbound traffic in specific port with public profile. This - technique was identified when an adversary wants to grant remote access to a machine - by allowing the traffic in a firewall rule. +description: The following analytic detects suspicious modifications to firewall rule + registry settings that allow inbound traffic on specific ports with a public profile. + It leverages data from the Endpoint.Registry data model, focusing on registry paths + and values indicative of such changes. This activity is significant as it may indicate + an adversary attempting to grant remote access to a machine by modifying firewall + rules. If confirmed malicious, this could enable unauthorized remote access, potentially + leading to further exploitation, data exfiltration, or lateral movement within the + network. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\System\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules\\*" Registry.registry_value_data = "*|Action=Allow|*" Registry.registry_value_data = "*|Dir=In|*" Registry.registry_value_data = "*|LPort=*") BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest Registry.user - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `allow_inbound_traffic_by_firewall_rule_registry_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*\\System\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules\\*" + Registry.registry_value_data = "*|Action=Allow|*" Registry.registry_value_data = + "*|Dir=In|*" Registry.registry_value_data = "*|LPort=*") BY _time span=1h Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.dest Registry.user | `drop_dm_object_name(Registry)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `allow_inbound_traffic_by_firewall_rule_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -66,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/allow_inbound_traffic_in_firewall_rule.yml b/detections/endpoint/allow_inbound_traffic_in_firewall_rule.yml index 1ac40f9da6..e5c93cfb36 100644 --- a/detections/endpoint/allow_inbound_traffic_in_firewall_rule.yml +++ b/detections/endpoint/allow_inbound_traffic_in_firewall_rule.yml @@ -1,19 +1,23 @@ name: Allow Inbound Traffic In Firewall Rule id: a5d85486-b89c-11eb-8267-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious PowerShell command to allow - inbound traffic inbound to a specific local port within the public profile. This - technique was seen in some attacker want to have a remote access to a machine by - allowing the traffic in firewall rule. +description: The following analytic detects a suspicious PowerShell command that allows + inbound traffic to a specific local port within the public profile. It leverages + PowerShell script block logging (EventCode 4104) to identify commands containing + keywords like "firewall," "Inbound," "Allow," and "-LocalPort." This activity is + significant because it may indicate an attacker attempting to establish remote access + by modifying firewall rules. If confirmed malicious, this could allow unauthorized + access to the machine, potentially leading to further exploitation and data exfiltration. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 ScriptBlockText = "*firewall*" ScriptBlockText = "*Inbound*" - ScriptBlockText = "*Allow*" ScriptBlockText = "*-LocalPort*" | stats count min(_time) as firstTime - max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` +search: '`powershell` EventCode=4104 ScriptBlockText = "*firewall*" ScriptBlockText + = "*Inbound*" ScriptBlockText = "*Allow*" ScriptBlockText = "*-LocalPort*" | stats + count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `allow_inbound_traffic_in_firewall_rule_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed @@ -28,8 +32,7 @@ tags: asset_type: Endpoint confidence: 30 impact: 10 - message: Suspicious firewall modification detected on endpoint $dest$ by - user $user$. + message: Suspicious firewall modification detected on endpoint $dest$ by user $user$. mitre_attack_id: - T1021.001 - T1021 @@ -49,14 +52,15 @@ tags: required_fields: - _time - EventCode - - Message - - ComputerName - - User + - ScriptBlockText + - Computer + - UserID risk_score: 3 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021/allow_inbound_traffic_in_firewall_rule/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021/allow_inbound_traffic_in_firewall_rule/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/allow_network_discovery_in_firewall.yml b/detections/endpoint/allow_network_discovery_in_firewall.yml index 78d5509e0e..07192c9714 100644 --- a/detections/endpoint/allow_network_discovery_in_firewall.yml +++ b/detections/endpoint/allow_network_discovery_in_firewall.yml @@ -1,14 +1,18 @@ name: Allow Network Discovery In Firewall id: ccd6a38c-d40b-11eb-85a5-acde48001122 -version: 2 -date: '2021-06-23' +version: 3 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious modification to the firewall to - allow network discovery on a machine. This technique was seen in couple of ransomware - (revil, reddot) to discover other machine connected to the compromised host to encrypt - more files. +description: The following analytic detects a suspicious modification to the firewall + to allow network discovery on a machine. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions involving the 'netsh' + command to enable network discovery. This activity is significant because it is + commonly used by ransomware, such as REvil and RedDot, to discover and compromise + additional machines on the network. If confirmed malicious, this could lead to widespread + file encryption across multiple hosts, significantly amplifying the impact of the + ransomware attack. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -41,7 +45,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious modification to the firewall to allow network discovery detected on host - $dest$ + message: Suspicious modification to the firewall to allow network discovery detected + on host - $dest$ mitre_attack_id: - T1562.007 - T1562 @@ -72,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/allow_operation_with_consent_admin.yml b/detections/endpoint/allow_operation_with_consent_admin.yml index 829bf5ed42..1d37f3adf4 100644 --- a/detections/endpoint/allow_operation_with_consent_admin.yml +++ b/detections/endpoint/allow_operation_with_consent_admin.yml @@ -1,23 +1,29 @@ name: Allow Operation with Consent Admin id: 7de17d7a-c9d8-11eb-a812-acde48001122 -version: 4 -date: '2023-03-29' +version: 5 +date: '2024-05-20' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies a potential privilege escalation attempt to - perform malicious task. This registry modification is designed to allow the `Consent - Admin` to perform an operation that requires elevation without consent or credentials. - We also found this in some attacker to gain privilege escalation to the compromise - machine. +description: The following analytic detects a registry modification that allows the + 'Consent Admin' to perform operations requiring elevation without user consent or + credentials. It leverages data from the Endpoint.Registry data model, specifically + monitoring changes to the 'ConsentPromptBehaviorAdmin' value within the Windows + Policies System registry path. This activity is significant as it indicates a potential + privilege escalation attempt, which could allow an attacker to execute high-privilege + tasks without user approval. If confirmed malicious, this could lead to unauthorized + administrative access and control over the compromised machine, posing a severe + security risk. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System*" Registry.registry_value_name = ConsentPromptBehaviorAdmin Registry.registry_value_data = "0x00000000") BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest Registry.user - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `allow_operation_with_consent_admin_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System*" + Registry.registry_value_name = ConsentPromptBehaviorAdmin Registry.registry_value_data + = "0x00000000") BY _time span=1h Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + Registry.dest Registry.user | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `allow_operation_with_consent_admin_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -64,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/anomalous_usage_of_7zip.yml b/detections/endpoint/anomalous_usage_of_7zip.yml index 77cd112674..73420cfda5 100644 --- a/detections/endpoint/anomalous_usage_of_7zip.yml +++ b/detections/endpoint/anomalous_usage_of_7zip.yml @@ -1,24 +1,24 @@ name: Anomalous usage of 7zip id: 9364ee8e-a39a-11eb-8f1d-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-25' author: Michael Haag, Teoderick Contreras, Splunk status: production type: Anomaly -description: The following detection identifies a 7z.exe spawned from `Rundll32.exe` - or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`. - It has been observed where an adversary will rename `7z.exe`. Additional coverage - may be required to identify the behavior of renamed instances of `7z.exe`. During - triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture - any files written to disk and analyze as needed. Review parallel processes for additional - behaviors. Typically, archiving files will result in exfiltration. +description: The following analytic detects the execution of 7z.exe, a 7-Zip utility, + spawned from rundll32.exe or dllhost.exe. This behavior is identified using Endpoint + Detection and Response (EDR) telemetry, focusing on process names and parent processes. + This activity is significant as it may indicate an adversary attempting to use 7-Zip + for data exfiltration, often by renaming the executable to evade detection. If confirmed + malicious, this could lead to unauthorized data archiving and exfiltration, compromising + sensitive information and potentially leading to further system exploitation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("rundll32.exe", "dllhost.exe") Processes.process_name=*7z* by Processes.dest - Processes.user Processes.parent_process Processes.parent_process_name Processes.process_name Processes.process - Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + Processes.user Processes.parent_process Processes.parent_process_name Processes.process_name + Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `anomalous_usage_of_7zip_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -87,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/any_powershell_downloadfile.yml b/detections/endpoint/any_powershell_downloadfile.yml index 2cc3f4b142..8731471376 100644 --- a/detections/endpoint/any_powershell_downloadfile.yml +++ b/detections/endpoint/any_powershell_downloadfile.yml @@ -1,15 +1,18 @@ name: Any Powershell DownloadFile id: 1a93b7ea-7af7-11eb-adb5-acde48001122 -version: 3 -date: '2023-04-14' +version: 4 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of PowerShell downloading a - file using `DownloadFile` method. This particular method is utilized in many different - PowerShell frameworks to download files and output to disk. Identify the source - (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell - transaction logs are available, review for further details of the implant. +description: The following analytic detects the use of PowerShell's `DownloadFile` + method to download files. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs. This activity is significant as + it is commonly used in malicious frameworks to download and execute additional payloads. + If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, + or further compromise of the system. Analysts should investigate the source and + destination of the download and review AMSI or PowerShell transaction logs for additional + context. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -94,6 +97,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/any_powershell_downloadstring.yml b/detections/endpoint/any_powershell_downloadstring.yml index 1fbbaa1089..f811a1c48b 100644 --- a/detections/endpoint/any_powershell_downloadstring.yml +++ b/detections/endpoint/any_powershell_downloadstring.yml @@ -1,15 +1,18 @@ name: Any Powershell DownloadString id: 4d015ef2-7adf-11eb-95da-acde48001122 -version: 3 -date: '2023-04-05' +version: 4 +date: '2024-05-10' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of PowerShell downloading a - file using `DownloadString` method. This particular method is utilized in many different - PowerShell frameworks to download files and output to disk. Identify the source - (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell - transaction logs are available, review for further details of the implant. +description: The following analytic detects the use of PowerShell's `DownloadString` + method to download files. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs that include command-line details. + This activity is significant because `DownloadString` is commonly used in malicious + PowerShell scripts to fetch and execute remote code. If confirmed malicious, this + behavior could allow an attacker to download and run arbitrary code, potentially + leading to unauthorized access, data exfiltration, or further compromise of the + affected system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -95,6 +98,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/attacker_tools_on_endpoint.yml b/detections/endpoint/attacker_tools_on_endpoint.yml index bb1e265ef2..d5be08b6a2 100644 --- a/detections/endpoint/attacker_tools_on_endpoint.yml +++ b/detections/endpoint/attacker_tools_on_endpoint.yml @@ -1,12 +1,12 @@ name: Attacker Tools On Endpoint id: a51bfe1a-94f0-48cc-b4e4-16a110145893 -version: 3 -date: '2024-01-01' +version: 4 +date: '2024-05-29' author: Bhavin Patel, Splunk status: production type: TTP description: |- - The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives. + The following analytic detects the execution of tools commonly exploited by cybercriminals, such as those used for unauthorized access, network scanning, or data exfiltration. It leverages process activity data from Endpoint Detection and Response (EDR) agents, focusing on known attacker tool names. This activity is significant because it serves as an early warning system for potential security incidents, enabling prompt response. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further network compromise, posing a severe threat to the organization's security infrastructure. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1595/attacker_scan_tools/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1595/attacker_scan_tools/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/attempt_to_add_certificate_to_untrusted_store.yml b/detections/endpoint/attempt_to_add_certificate_to_untrusted_store.yml index d8d60065bf..be0059ec9e 100644 --- a/detections/endpoint/attempt_to_add_certificate_to_untrusted_store.yml +++ b/detections/endpoint/attempt_to_add_certificate_to_untrusted_store.yml @@ -1,12 +1,12 @@ name: Attempt To Add Certificate To Untrusted Store id: 6bc5243e-ef36-45dc-9b12-f4a6be131159 -version: 7 -date: '2021-09-16' +version: 8 +date: '2024-05-12' author: Patrick Bareiss, Rico Valdez, Splunk status: production type: TTP description: |- - The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security. + The following analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. It leverages process activity and command-line arguments from Endpoint Detection and Response (EDR) logs mapped to the Splunk `Processes` data model. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime values(Processes.process) @@ -76,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/attempt_to_stop_security_service.yml b/detections/endpoint/attempt_to_stop_security_service.yml index 32d26e832b..d1b6bad955 100644 --- a/detections/endpoint/attempt_to_stop_security_service.yml +++ b/detections/endpoint/attempt_to_stop_security_service.yml @@ -1,12 +1,12 @@ name: Attempt To Stop Security Service id: c8e349c6-b97c-486e-8949-bd7bcd1f3910 -version: 4 -date: '2023-06-13' +version: 5 +date: '2024-05-21' author: Rico Valdez, Splunk status: production type: TTP description: |- - The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack. + The following analytic detects attempts to stop security-related services on an endpoint, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, specifically searching for processes involving the "sc.exe" command with the "stop" parameter. This activity is significant because disabling security services can undermine the organization's security posture, potentially leading to unauthorized access, data exfiltration, or further attacks like malware installation or privilege escalation. If confirmed malicious, this behavior could compromise the endpoint and the entire network, necessitating immediate investigation and response. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -86,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_defend_service_stop/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_defend_service_stop/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/auto_admin_logon_registry_entry.yml b/detections/endpoint/auto_admin_logon_registry_entry.yml index a43f996819..c11c8a7094 100644 --- a/detections/endpoint/auto_admin_logon_registry_entry.yml +++ b/detections/endpoint/auto_admin_logon_registry_entry.yml @@ -1,24 +1,28 @@ name: Auto Admin Logon Registry Entry id: 1379d2b8-0f18-11ec-8ca3-acde48001122 -version: 4 -date: '2023-04-11' +version: 5 +date: '2024-05-10' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: this search is to detect a suspicious registry modification to implement - auto admin logon to a host. This technique was seen in BlackMatter ransomware to - automatically logon to the compromise host after triggering a safemode boot to - continue encrypting the whole network. This behavior is not a common practice and - really a suspicious TTP or alert need to be consider if found within then network - premise. +description: The following analytic detects a suspicious registry modification that + enables auto admin logon on a host. It leverages data from the Endpoint.Registry + data model, specifically looking for changes to the "AutoAdminLogon" value within + the "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" registry path. This + activity is significant because it was observed in BlackMatter ransomware attacks + to maintain access after a safe mode reboot, facilitating further encryption. If + confirmed malicious, this could allow attackers to automatically log in and continue + their operations, potentially leading to widespread network encryption and data + loss. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*" AND Registry.registry_value_name=AutoAdminLogon AND Registry.registry_value_data=1) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*" + AND Registry.registry_value_name=AutoAdminLogon AND Registry.registry_value_data=1) + BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.process_guid Registry.dest | `drop_dm_object_name(Registry)` + | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `auto_admin_logon_registry_entry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/bcdedit_command_back_to_normal_mode_boot.yml b/detections/endpoint/bcdedit_command_back_to_normal_mode_boot.yml index afe16d9a0b..e6e58b0986 100644 --- a/detections/endpoint/bcdedit_command_back_to_normal_mode_boot.yml +++ b/detections/endpoint/bcdedit_command_back_to_normal_mode_boot.yml @@ -1,16 +1,18 @@ name: Bcdedit Command Back To Normal Mode Boot id: dc7a8004-0f18-11ec-8c54-acde48001122 -version: 1 -date: '2021-09-06' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious bcdedit commandline to configure - the host from safe mode back to normal boot configuration. This technique was seen - in blackMatter ransomware where it force the compromised host to boot in safe mode - to continue its encryption and bring back to normal boot using bcdedit deletevalue - command. This TTP can be a good alert for host that booted from safe mode forcefully - since it need to modify the boot configuration to bring it back to normal. +description: The following analytic detects the execution of a suspicious `bcdedit` + command that reconfigures a host from safe mode back to normal boot. This detection + leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions + involving `bcdedit.exe` with specific parameters. This activity is significant as + it may indicate the presence of ransomware, such as BlackMatter, which manipulates + boot configurations to facilitate encryption processes. If confirmed malicious, + this behavior could allow attackers to maintain control over the boot process, potentially + leading to further system compromise and data encryption. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/bits_job_persistence.yml b/detections/endpoint/bits_job_persistence.yml index 6be342dcce..e67abbaf5b 100644 --- a/detections/endpoint/bits_job_persistence.yml +++ b/detections/endpoint/bits_job_persistence.yml @@ -1,17 +1,18 @@ name: BITS Job Persistence id: e97a5ffe-90bf-11eb-928a-acde48001122 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: TTP -description: The following query identifies Microsoft Background Intelligent Transfer - Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. - The query identifies the parameters used to create, resume or add a file to a BITS - job. Typically seen combined in a oneliner or ran in sequence. If identified, review - the BITS job created and capture any files written to disk. It is possible for BITS - to be used to upload files and this may require further network data analysis to - identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +description: The following analytic detects the use of `bitsadmin.exe` to schedule + a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on specific command-line parameters such as + `create`, `addfile`, and `resume`. This activity is significant because BITS jobs + can be used by attackers to maintain persistence, download malicious payloads, or + exfiltrate data. If confirmed malicious, this could allow an attacker to persist + in the environment, execute arbitrary code, or transfer sensitive information, necessitating + further investigation and potential remediation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,11 +89,13 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/crowdstrike_falcon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/crowdstrike_falcon.log source: crowdstrike sourcetype: crowdstrike:events:sensor diff --git a/detections/endpoint/bitsadmin_download_file.yml b/detections/endpoint/bitsadmin_download_file.yml index 7339e7429a..384bdf2eb3 100644 --- a/detections/endpoint/bitsadmin_download_file.yml +++ b/detections/endpoint/bitsadmin_download_file.yml @@ -1,22 +1,19 @@ name: BITSAdmin Download File id: 80630ff4-8e4c-11eb-aab5-acde48001122 -version: 3 -date: '2022-11-29' +version: 4 +date: '2024-05-20' author: Michael Haag, Sittikorn S status: production type: TTP -description: The following query identifies Microsoft Background Intelligent Transfer - Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote - object. In addition, look for `download` or `upload` on the command-line, the switches - are not required to perform a transfer. Capture any files downloaded. Review the - reputation of the IP or domain used. Typically once executed, a follow on command - will be used to execute the dropped file. Note that the network connection or file - modification events related will not spawn or create from `bitsadmin.exe`, but the - artifacts will appear in a parallel process of `svchost.exe` with a command-line - similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel - and child processes to capture any behaviors and artifacts. In some suspicious and - malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` - to list out the jobs during investigation. +description: The following analytic detects the use of `bitsadmin.exe` with the `transfer` + parameter to download a remote object. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process and command-line telemetry. This + activity is significant because `bitsadmin.exe` can be exploited to download and + execute malicious files without immediate detection. If confirmed malicious, an + attacker could use this technique to download and execute payloads, potentially + leading to code execution, privilege escalation, or persistent access within the + environment. Review parallel and child processes, especially `svchost.exe`, for + associated artifacts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -95,11 +92,13 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/crowdstrike_falcon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/crowdstrike_falcon.log source: crowdstrike sourcetype: crowdstrike:events:sensor diff --git a/detections/endpoint/certutil_download_with_urlcache_and_split_arguments.yml b/detections/endpoint/certutil_download_with_urlcache_and_split_arguments.yml index 22d80c1593..f7617cb6e4 100644 --- a/detections/endpoint/certutil_download_with_urlcache_and_split_arguments.yml +++ b/detections/endpoint/certutil_download_with_urlcache_and_split_arguments.yml @@ -1,17 +1,18 @@ name: CertUtil Download With URLCache and Split Arguments id: 415b4306-8bfb-11eb-85c4-acde48001122 -version: 3 -date: '2022-02-03' +version: 4 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: Certutil.exe may download a file from a remote destination using `-urlcache`. - This behavior does require a URL to be passed on the command-line. In addition, - `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will - be used. It is not entirely common for `certutil.exe` to contact public IP space. - However, it is uncommon for `certutil.exe` to write files to world writeable paths. - During triage, capture any files on disk and review. Review the reputation of the - remote IP or domain in question. +description: The following analytic detects the use of certutil.exe to download files + using the `-urlcache` and `-split` arguments. It leverages Endpoint Detection and + Response (EDR) data, focusing on command-line executions that include these specific + arguments. This activity is significant because certutil.exe is typically used for + certificate services, and its use to download files from remote locations is uncommon + and potentially malicious. If confirmed, this behavior could indicate an attempt + to download and execute malicious payloads, leading to potential system compromise + and unauthorized data access. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/certutil_download_with_verifyctl_and_split_arguments.yml b/detections/endpoint/certutil_download_with_verifyctl_and_split_arguments.yml index 7724b2f5fa..ab76a73504 100644 --- a/detections/endpoint/certutil_download_with_verifyctl_and_split_arguments.yml +++ b/detections/endpoint/certutil_download_with_verifyctl_and_split_arguments.yml @@ -1,17 +1,18 @@ name: CertUtil Download With VerifyCtl and Split Arguments id: 801ad9e4-8bfb-11eb-8b31-acde48001122 -version: 3 -date: '2022-02-03' +version: 4 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: 'Certutil.exe may download a file from a remote destination using `-VerifyCtl`. - This behavior does require a URL to be passed on the command-line. In addition, - `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will - be used. It is not entirely common for `certutil.exe` to contact public IP space. - \ During triage, capture any files on disk and review. Review the reputation of - the remote IP or domain in question. Using `-VerifyCtl`, the file will either be - written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\`. ' +description: 'The following analytic detects the use of `certutil.exe` to download + files using the `-VerifyCtl` and `-split` arguments. This behavior is identified + by monitoring command-line executions for these specific arguments via Endpoint + Detection and Response (EDR) telemetry. This activity is significant because `certutil.exe` + is a legitimate tool often abused by attackers to download and execute malicious + payloads. If confirmed malicious, this could allow an attacker to download and execute + arbitrary files, potentially leading to code execution, data exfiltration, or further + compromise of the system.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/certutil_with_decode_argument.yml b/detections/endpoint/certutil_with_decode_argument.yml index e5f322bd05..cdd65c8aa1 100644 --- a/detections/endpoint/certutil_with_decode_argument.yml +++ b/detections/endpoint/certutil_with_decode_argument.yml @@ -1,18 +1,18 @@ name: CertUtil With Decode Argument id: bfe94226-8c10-11eb-a4b3-acde48001122 -version: 2 -date: '2021-03-23' +version: 3 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: CertUtil.exe may be used to `encode` and `decode` a file, including PE - and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` - and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded - file that was downloaded. Once decoded, it will be loaded by a parallel process. - Note that there are two additional command switches that may be used - `encodehex` - and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for - further execution. During triage, identify the source of the file being decoded. - Review its contents or execution behavior for further analysis. +description: The following analytic detects the use of CertUtil.exe with the 'decode' + argument, which may indicate an attempt to decode a previously encoded file, potentially + containing malicious payloads. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions involving CertUtil.exe. + This activity is significant because attackers often use CertUtil to decode malicious + files downloaded from the internet, which are then executed to compromise the system. + If confirmed malicious, this activity could lead to unauthorized code execution, + further system compromise, and potential data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -94,6 +94,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1140/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1140/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/change_default_file_association.yml b/detections/endpoint/change_default_file_association.yml index 4fb4d4936d..4c9eae831c 100644 --- a/detections/endpoint/change_default_file_association.yml +++ b/detections/endpoint/change_default_file_association.yml @@ -1,15 +1,18 @@ name: Change Default File Association id: 462d17d8-1f71-11ec-ad07-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is developed to detect suspicious registry modification - to change the default file association of windows to malicious payload. This technique - was seen in some APT where it modify the default process to run file association, - like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other - payload that will load malicious commands to the compromised host. +description: The following analytic detects suspicious registry modifications that + change the default file association to execute a malicious payload. It leverages + data from the Endpoint data model, specifically monitoring registry paths under + "*\\shell\\open\\command\\*" and "*HKCR\\*". This activity is significant because + altering default file associations can allow attackers to execute arbitrary scripts + or payloads when a user opens a file, leading to potential code execution. If confirmed + malicious, this technique can enable attackers to persist on the compromised host + and execute further malicious commands, posing a severe threat to the environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.001/txtfile_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.001/txtfile_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/change_to_safe_mode_with_network_config.yml b/detections/endpoint/change_to_safe_mode_with_network_config.yml index be3fe80b75..cd7079ba17 100644 --- a/detections/endpoint/change_to_safe_mode_with_network_config.yml +++ b/detections/endpoint/change_to_safe_mode_with_network_config.yml @@ -1,16 +1,18 @@ name: Change To Safe Mode With Network Config id: 81f1dce0-0f18-11ec-a5d7-acde48001122 -version: 1 -date: '2021-09-06' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious bcdedit commandline to configure - the host to boot in safe mode with network config. This technique was seen in blackMatter - ransomware where it force the compromised host to boot in safe mode to continue - its encryption and bring back to normal boot using bcdedit deletevalue command. - This TTP can be a good alert for host that booted from safe mode forcefully since - it need to modify the boot configuration to bring it back to normal. +description: The following analytic detects the execution of a suspicious `bcdedit` + command that configures a host to boot in safe mode with network support. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions involving `bcdedit.exe` with specific parameters. This activity is significant + because it is a known technique used by BlackMatter ransomware to force a compromised + host into safe mode for continued encryption. If confirmed malicious, this could + allow attackers to bypass certain security controls, persist in the environment, + and continue their malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.002/autoadminlogon/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/chcp_command_execution.yml b/detections/endpoint/chcp_command_execution.yml index 72a67b43f8..f4b3a5c1e9 100644 --- a/detections/endpoint/chcp_command_execution.yml +++ b/detections/endpoint/chcp_command_execution.yml @@ -1,13 +1,18 @@ name: CHCP Command Execution id: 21d236ec-eec1-11eb-b23e-acde48001122 -version: 1 -date: '2021-07-27' +version: 2 +date: '2024-05-09' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect execution of chcp.exe application. this utility - is used to change the active code page of the console. This technique was seen in - icedid malware to know the locale region/language/country of the compromise host. +description: The following analytic detects the execution of the chcp.exe application, + which is used to change the active code page of the console. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process creation + events where chcp.exe is executed by cmd.exe with specific command-line arguments. + This activity is significant because it can indicate the presence of malware, such + as IcedID, which uses this technique to determine the locale region, language, or + country of the compromised host. If confirmed malicious, this could lead to further + system compromise and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/check_elevated_cmd_using_whoami.yml b/detections/endpoint/check_elevated_cmd_using_whoami.yml index 6705e955ac..e2cfedcecb 100644 --- a/detections/endpoint/check_elevated_cmd_using_whoami.yml +++ b/detections/endpoint/check_elevated_cmd_using_whoami.yml @@ -1,17 +1,17 @@ name: Check Elevated CMD using whoami id: a9079b18-1633-11ec-859c-acde48001122 -version: 1 -date: '2021-09-15' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious whoami execution to check if the - cmd or shell instance process is with elevated privileges. This technique was seen - in FIN7 js implant where it execute this as part of its data collection to the infected - machine to check if the running shell cmd process is elevated or not. This TTP is - really a good alert for known attacker that recon on the targetted host. This command - is not so commonly executed by a normal user or even an admin to check if a process - is elevated. +description: The following analytic identifies the execution of the 'whoami' command + with specific parameters to check for elevated privileges. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process and command-line + telemetry. This activity is significant because it is commonly used by attackers, + such as FIN7, to perform reconnaissance on a compromised host. If confirmed malicious, + this behavior could indicate an attacker is assessing their privilege level, potentially + leading to further privilege escalation or persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/child_processes_of_spoolsv_exe.yml b/detections/endpoint/child_processes_of_spoolsv_exe.yml index 43b94e57a4..2403887364 100644 --- a/detections/endpoint/child_processes_of_spoolsv_exe.yml +++ b/detections/endpoint/child_processes_of_spoolsv_exe.yml @@ -20,7 +20,7 @@ search: '| tstats `security_content_summariesonly` count values(Processes.proces as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=spoolsv.exe AND Processes.process_name!=regsvr32.exe by Processes.dest Processes.parent_process Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `child_processes_of_spoolsv_exe_filter` ' + | `security_content_ctime(lastTime)` | `child_processes_of_spoolsv_exe_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/endpoint/clop_common_exec_parameter.yml b/detections/endpoint/clop_common_exec_parameter.yml index 92c20d7d5d..197e374c96 100644 --- a/detections/endpoint/clop_common_exec_parameter.yml +++ b/detections/endpoint/clop_common_exec_parameter.yml @@ -1,17 +1,18 @@ name: Clop Common Exec Parameter id: 5a8a2a72-8322-11eb-9ee9-acde48001122 -version: 2 -date: '2023-03-17' +version: 3 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytics are designed to identifies some CLOP ransomware - variant that using arguments to execute its main code or feature of its code. In - this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files - in network shares and if it is "temp.dat", it will try to read from some stream - pipe or file start encrypting files within the infected local machines. This technique - can be also identified as an anti-sandbox technique to make its code non-responsive - since it is waiting for some parameter to execute properly. +description: The following analytic identifies the execution of CLOP ransomware variants + using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line arguments. Monitoring this activity is + crucial as it indicates potential ransomware behavior, which can lead to file encryption + on network shares or local machines. If confirmed malicious, this activity could + result in significant data loss and operational disruption due to encrypted files, + highlighting the need for immediate investigation and response. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -83,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_b/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_b/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/clop_ransomware_known_service_name.yml b/detections/endpoint/clop_ransomware_known_service_name.yml index 60704940be..29ccc9225f 100644 --- a/detections/endpoint/clop_ransomware_known_service_name.yml +++ b/detections/endpoint/clop_ransomware_known_service_name.yml @@ -1,20 +1,24 @@ name: Clop Ransomware Known Service Name id: 07e08a12-870c-11eb-b5f9-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-21' author: Teoderick Contreras status: production type: TTP -description: This detection is to identify the common service name created by the - CLOP ransomware as part of its persistence and high privilege code execution in - the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API - in creating this service entry. +description: The following analytic identifies the creation of a service with a known + name used by CLOP ransomware for persistence and high-privilege code execution. + It detects this activity by monitoring Windows Event Logs (EventCode 7045) for specific + service names ("SecurityCenterIBM", "WinCheckDRVs"). This activity is significant + because the creation of such services is a common tactic used by ransomware to maintain + control over infected systems. If confirmed malicious, this could allow attackers + to execute code with elevated privileges, maintain persistence, and potentially + disrupt or encrypt critical data. data_source: - Windows Event Log System 7045 search: '`wineventlog_system` EventCode=7045 ServiceName IN ("SecurityCenterIBM", - "WinCheckDRVs") | stats count min(_time) as firstTime max(_time) as lastTime by Computer - EventCode ServiceName StartType ServiceType | rename Computer as dest | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `clop_ransomware_known_service_name_filter`' + "WinCheckDRVs") | stats count min(_time) as firstTime max(_time) as lastTime by + Computer EventCode ServiceName StartType ServiceType | rename Computer as dest | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `clop_ransomware_known_service_name_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. @@ -53,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/cmd_carry_out_string_command_parameter.yml b/detections/endpoint/cmd_carry_out_string_command_parameter.yml index 981ba75530..f0a0066b9c 100644 --- a/detections/endpoint/cmd_carry_out_string_command_parameter.yml +++ b/detections/endpoint/cmd_carry_out_string_command_parameter.yml @@ -1,16 +1,17 @@ name: CMD Carry Out String Command Parameter id: 54a6ed00-3256-11ec-b031-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-20' author: Teoderick Contreras, Bhavin Patel, Splunk status: production type: Hunting -description: The following analytic identifies command-line arguments where `cmd.exe - /c` is used to execute a program. `cmd /c` is used to run commands in MS-DOS and - terminate after command or process completion. This technique is commonly seen in - adversaries and malware to execute batch command using different shell like PowerShell - or different process other than `cmd.exe`. This is a good hunting query for suspicious - command-line made by a script or relative process execute it. +description: The following analytic detects the use of `cmd.exe /c` to execute commands, + a technique often employed by adversaries and malware to run batch commands or invoke + other shells like PowerShell. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions and process metadata. + Monitoring this activity is crucial as it can indicate script-based attacks or unauthorized + command execution. If confirmed malicious, this behavior could lead to unauthorized + code execution, privilege escalation, or persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) @@ -95,6 +96,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/cmd_carry_str_param/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/cmd_carry_str_param/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/cmd_echo_pipe___escalation.yml b/detections/endpoint/cmd_echo_pipe___escalation.yml index 81a0bd910f..7a570dfb50 100644 --- a/detections/endpoint/cmd_echo_pipe___escalation.yml +++ b/detections/endpoint/cmd_echo_pipe___escalation.yml @@ -1,14 +1,18 @@ name: CMD Echo Pipe - Escalation id: eb277ba0-b96b-11eb-b00e-acde48001122 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -description: This analytic identifies a common behavior by Cobalt Strike and other - frameworks where the adversary will escalate privileges, either via `jump` (Cobalt - Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will - look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. +description: The following analytic identifies the use of named-pipe impersonation + for privilege escalation, commonly associated with Cobalt Strike and similar frameworks. + It detects command-line executions where `cmd.exe` uses `echo` to write to a named + pipe, such as `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process and + command-line telemetry. This activity is significant as it indicates potential privilege + escalation attempts. If confirmed malicious, attackers could gain elevated privileges, + enabling further compromise and persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -86,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/cmdline_tool_not_executed_in_cmd_shell.yml b/detections/endpoint/cmdline_tool_not_executed_in_cmd_shell.yml index f52a79653e..de29f57aea 100644 --- a/detections/endpoint/cmdline_tool_not_executed_in_cmd_shell.yml +++ b/detections/endpoint/cmdline_tool_not_executed_in_cmd_shell.yml @@ -1,18 +1,18 @@ name: Cmdline Tool Not Executed In CMD Shell id: 6c3f7dd8-153c-11ec-ac2d-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a non-standard parent process (not - matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. - This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also - typically seen when an adversary is injected into another process performing different - discovery techniques. This event stands out as a TTP since these tools are commonly - executed with a shell application or Explorer parent, and not by another application. - This TTP is a good indicator for an adversary gathering host information, but one - possible false positive might be an automated tool used by a system administator. +description: The following analytic identifies instances where `ipconfig.exe`, `systeminfo.exe`, + or similar tools are executed by a non-standard parent process, excluding CMD, PowerShell, + or Explorer. This detection leverages Endpoint Detection and Response (EDR) telemetry + to monitor process creation events. Such behavior is significant as it may indicate + adversaries using injected processes to perform system discovery, a tactic observed + in FIN7's JSSLoader. If confirmed malicious, this activity could allow attackers + to gather critical host information, aiding in further exploitation or lateral movement + within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -99,6 +99,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/jssloader/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/jssloader/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/cobalt_strike_named_pipes.yml b/detections/endpoint/cobalt_strike_named_pipes.yml index 58eb2b927c..7c5eab3db4 100644 --- a/detections/endpoint/cobalt_strike_named_pipes.yml +++ b/detections/endpoint/cobalt_strike_named_pipes.yml @@ -1,30 +1,26 @@ name: Cobalt Strike Named Pipes id: 5876d429-0240-4709-8b93-ea8330b411b5 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the use of default or publicly known - named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex - pipe for communication between the pipe server and one or more pipe clients. Cobalt - Strike uses named pipes in many ways and has default values used with the Artifact - Kit and Malleable C2 Profiles. The following query assists with identifying these - default named pipes. Each EDR product presents named pipes a little different. Consider - taking the values and generating a query based on the product of choice. - - Upon triage, review the process performing the named pipe. If it is explorer.exe, - It is possible it was injected into by another process. Review recent parallel processes - to identify suspicious patterns or behaviors. A parallel process may have a network - connection, review and follow the connection back to identify any file modifications.' +description: 'The following analytic detects the use of default or publicly known + named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 + to identify specific named pipes commonly used by Cobalt Strike''s Artifact Kit + and Malleable C2 Profiles. This activity is significant because Cobalt Strike is + a popular tool for adversaries to conduct post-exploitation tasks, and identifying + its named pipes can reveal potential malicious activity. If confirmed malicious, + this could indicate an active Cobalt Strike beacon, leading to unauthorized access, + data exfiltration, or further lateral movement within the network.' data_source: - Sysmon EventID 17 - Sysmon EventID 18 search: '`sysmon` EventID=17 OR EventID=18 PipeName IN (\\msagent_*, \\DserNamePipe*, \\srvsvc_*, \\postex_*, \\status_*, \\MSSE-*, \\spoolss_*, \\win_svc*, \\ntsvcs*, \\winsock*, \\UIA_PIPE*) | stats count min(_time) as firstTime max(_time) as lastTime - by dest, process_name, process_id process_path, PipeName | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `cobalt_strike_named_pipes_filter`' + by dest, process_name, process_id process_path, PipeName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `cobalt_strike_named_pipes_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -50,7 +46,8 @@ tags: asset_type: Endpoint confidence: 90 impact: 80 - message: An instance of $process_name$ was identified on endpoint $dest$ accessing known suspicious named pipes related to Cobalt Strike. + message: An instance of $process_name$ was identified on endpoint $dest$ accessing + known suspicious named pipes related to Cobalt Strike. mitre_attack_id: - T1055 observable: @@ -79,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/common_ransomware_extensions.yml b/detections/endpoint/common_ransomware_extensions.yml index 05110c7e55..0aded4d1e3 100644 --- a/detections/endpoint/common_ransomware_extensions.yml +++ b/detections/endpoint/common_ransomware_extensions.yml @@ -1,11 +1,18 @@ name: Common Ransomware Extensions id: a9e5c5db-db11-43ca-86a8-c852d1b2c0ec -version: 5 -date: '2022-11-10' +version: 6 +date: '2024-05-26' author: David Dorsey, Michael Haag, Splunk, Steven Dick status: production type: Hunting -description: "The following analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack." +description: "The following analytic detects modifications to files with extensions + commonly associated with ransomware. It leverages the Endpoint.Filesystem data model + to identify changes in file extensions that match known ransomware patterns. This + activity is significant because it suggests an attacker is attempting to encrypt + or alter files, potentially leading to severe data loss and operational disruption. + If confirmed malicious, this activity could result in the encryption of critical + data, rendering it inaccessible and causing significant damage to the organization's + data integrity and availability." data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) @@ -68,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/ransomware_notes/ransom-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/ransomware_notes/ransom-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/connectwise_screenconnect_path_traversal.yml b/detections/endpoint/connectwise_screenconnect_path_traversal.yml index 1f9d78eba4..e8c22ba833 100644 --- a/detections/endpoint/connectwise_screenconnect_path_traversal.yml +++ b/detections/endpoint/connectwise_screenconnect_path_traversal.yml @@ -1,20 +1,36 @@ name: ConnectWise ScreenConnect Path Traversal id: 56a3ac65-e747-41f7-b014-dff7423c1dda -version: 1 -date: '2024-02-21' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk data_source: - Sysmon EventID 11 type: TTP status: production -description: This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\ScreenConnect\\App_Extensions\\*") Filesystem.file_name IN ("*.aspx","*.ashx") by Filesystem.file_create_time Filesystem.process_id Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.dest - | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects attempts to exploit the ConnectWise ScreenConnect + CVE-2024-1708 vulnerability, which allows path traversal attacks by manipulating + file_path and file_name parameters in the URL. It leverages the Endpoint datamodel + Filesystem node to identify suspicious file system events, specifically targeting + paths and filenames associated with ScreenConnect. This activity is significant + as it can lead to unauthorized access to sensitive files and directories, potentially + resulting in data exfiltration or arbitrary code execution. If confirmed malicious, + attackers could gain unauthorized access and control over the host system, posing + a severe security risk. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\ScreenConnect\\App_Extensions\\*") + Filesystem.file_name IN ("*.aspx","*.ashx") by Filesystem.file_create_time Filesystem.process_id + Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.dest + | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `connectwise_screenconnect_path_traversal_filter`' -how_to_implement: This analytic utilizes the Endpoint datamodel Filesystem node to identify path traversal attempts against ScreenConnect. Note that using SACL auditing or other file system monitoring tools may also be used to detect path traversal attempts. Typically the data for this analytic will come from EDR or other properly CIM mapped data sources. -known_false_positives: False positives are not expected, as the detection is based on the presence of file system events that indicate path traversal attempts. The analytic may be modified to look for any file writes to this path as it is not common for files to write here. +how_to_implement: This analytic utilizes the Endpoint datamodel Filesystem node to + identify path traversal attempts against ScreenConnect. Note that using SACL auditing + or other file system monitoring tools may also be used to detect path traversal + attempts. Typically the data for this analytic will come from EDR or other properly + CIM mapped data sources. +known_false_positives: False positives are not expected, as the detection is based + on the presence of file system events that indicate path traversal attempts. The + analytic may be modified to look for any file writes to this path as it is not common + for files to write here. references: - https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass - https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2 @@ -48,10 +64,11 @@ tags: security_domain: endpoint cve: - CVE-2024-1708 - - CVE-2024-1709 + - CVE-2024-1709 tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/sysmon_app_extensions.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/sysmon_app_extensions.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/connectwise_screenconnect_path_traversal_windows_sacl.yml b/detections/endpoint/connectwise_screenconnect_path_traversal_windows_sacl.yml index ace9237395..8dfdb15d92 100644 --- a/detections/endpoint/connectwise_screenconnect_path_traversal_windows_sacl.yml +++ b/detections/endpoint/connectwise_screenconnect_path_traversal_windows_sacl.yml @@ -1,21 +1,32 @@ name: ConnectWise ScreenConnect Path Traversal Windows SACL id: 4e127857-1fc9-4c95-9d69-ba24c91d52d7 -version: 1 -date: '2024-02-21' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk data_source: - Windows Event Log Security 4663 type: TTP status: production -description: This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. -search: '`wineventlog_security` EventCode=4663 ProcessName=*\\ScreenConnect.Service.exe file_path IN ("*\\ScreenConnect\\App_Extensions\\*") file_name IN ("*.aspx","*.ashx") - | stats count min(_time) as firstTime max(_time) as lastTime by ObjectName ObjectType ProcessName AccessMask process_id EventCode Computer Caller_User_Name - | rename Computer as dest Caller_User_Name as user ProcessName as process_name - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `connectwise_screenconnect_path_traversal_windows_sacl_filter`' -how_to_implement: To implement the following query, enable SACL auditing for the ScreenConnect directory(ies). With this data, the following analytic will work correctly. A GIST is provided in the references to assist with enabling SACL Auditing. -known_false_positives: False positives should be limited as the analytic is specific to ScreenConnect path traversal attempts. Tune as needed, or restrict to specific hosts if false positives are encountered. +description: The following analytic detects attempts to exploit the ConnectWise ScreenConnect + CVE-2024-1708 vulnerability using Windows SACL EventCode 4663. It identifies path + traversal attacks by monitoring file system events related to the ScreenConnect + service. This activity is significant as it allows unauthorized access to sensitive + files and directories, potentially leading to data exfiltration or arbitrary code + execution. If confirmed malicious, attackers could gain unauthorized access to critical + data or execute harmful code, compromising the integrity and security of the affected + system. Immediate remediation by updating to version 23.9.8 or above is recommended. +search: '`wineventlog_security` EventCode=4663 ProcessName=*\\ScreenConnect.Service.exe + file_path IN ("*\\ScreenConnect\\App_Extensions\\*") file_name IN ("*.aspx","*.ashx") + | stats count min(_time) as firstTime max(_time) as lastTime by ObjectName ObjectType + ProcessName AccessMask process_id EventCode Computer Caller_User_Name | rename Computer + as dest Caller_User_Name as user ProcessName as process_name | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `connectwise_screenconnect_path_traversal_windows_sacl_filter`' +how_to_implement: To implement the following query, enable SACL auditing for the ScreenConnect + directory(ies). With this data, the following analytic will work correctly. A GIST + is provided in the references to assist with enabling SACL Auditing. +known_false_positives: False positives should be limited as the analytic is specific + to ScreenConnect path traversal attempts. Tune as needed, or restrict to specific + hosts if false positives are encountered. references: - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4663 - https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass @@ -52,10 +63,11 @@ tags: security_domain: endpoint cve: - CVE-2024-1708 - - CVE-2024-1709 + - CVE-2024-1709 tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/4663_connectwise_aspx_app_extensions.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/4663_connectwise_aspx_app_extensions.log sourcetype: XmlWinEventLog source: XmlWinEventLog:Security diff --git a/detections/endpoint/control_loading_from_world_writable_directory.yml b/detections/endpoint/control_loading_from_world_writable_directory.yml index f40fd54eb2..c5cfb4a44c 100644 --- a/detections/endpoint/control_loading_from_world_writable_directory.yml +++ b/detections/endpoint/control_loading_from_world_writable_directory.yml @@ -1,14 +1,18 @@ name: Control Loading from World Writable Directory id: 10423ac4-10c9-11ec-8dc4-acde48001122 -version: 1 -date: '2021-09-08' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies control.exe loading either a .cpl - or .inf from a writable directory. This is related to CVE-2021-40444. During triage, - review parallel processes, parent and child, for further suspicious behaviors. In - addition, capture file modifications and analyze. +description: The following analytic identifies instances of control.exe loading a + .cpl or .inf file from a writable directory, which is related to CVE-2021-40444. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions mapped to the `Processes` + node of the `Endpoint` data model. This activity is significant as it may indicate + an attempt to exploit a known vulnerability, potentially leading to unauthorized + code execution. If confirmed malicious, this could allow an attacker to gain control + over the affected system, leading to further compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/create_local_admin_accounts_using_net_exe.yml b/detections/endpoint/create_local_admin_accounts_using_net_exe.yml index e238e14e46..bf7a421242 100644 --- a/detections/endpoint/create_local_admin_accounts_using_net_exe.yml +++ b/detections/endpoint/create_local_admin_accounts_using_net_exe.yml @@ -1,12 +1,12 @@ name: Create local admin accounts using net exe id: b89919ed-fe5f-492c-b139-151bb162040e -version: 9 -date: '2024-04-26' +version: 10 +date: '2024-05-11' author: Bhavin Patel, Splunk status: production type: TTP description: |- - The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack. + The following analytic detects the creation of local administrator accounts using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes named net.exe or net1.exe with the "/add" parameter and keywords related to administrator accounts. This activity is significant as it may indicate an attacker attempting to gain persistent access or escalate privileges. If confirmed malicious, this could lead to unauthorized access, data theft, or further system compromise. Review the process details, user context, and related artifacts to determine the legitimacy of the activity. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.user) as @@ -15,9 +15,9 @@ search: '| tstats `security_content_summariesonly` count values(Processes.user) where (Processes.process_name=net.exe OR Processes.process_name=net1.exe) AND Processes.process=*/add* AND (Processes.process=*administrators* OR Processes.process=*administratoren* OR Processes.process=*administrateurs* OR Processes.process=*administrador* OR Processes.process=*amministratori* - OR Processes.process=*administratorer*) by Processes.process Processes.process_name Processes.parent_process_name - Processes.dest Processes.user| `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `create_local_admin_accounts_using_net_exe_filter`' + OR Processes.process=*administratorer*) by Processes.process Processes.process_name + Processes.parent_process_name Processes.dest Processes.user| `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `create_local_admin_accounts_using_net_exe_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -83,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/create_or_delete_windows_shares_using_net_exe.yml b/detections/endpoint/create_or_delete_windows_shares_using_net_exe.yml index 2461a4cc32..73242cd06a 100644 --- a/detections/endpoint/create_or_delete_windows_shares_using_net_exe.yml +++ b/detections/endpoint/create_or_delete_windows_shares_using_net_exe.yml @@ -1,12 +1,12 @@ name: Create or delete windows shares using net exe id: 743a322c-9a68-4a0f-9c17-85d9cce2a27c -version: 6 -date: '2020-09-16' +version: 7 +date: '2024-05-26' author: Bhavin Patel, Splunk status: production type: TTP description: |- - The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. + The following analytic detects the creation or deletion of Windows shares using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes involving net.exe with actions related to share management. This activity is significant because it may indicate an attacker attempting to manipulate network shares for malicious purposes, such as data exfiltration, malware distribution, or establishing persistence. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, service disruption, or malware introduction. Immediate investigation is required to determine the intent and mitigate potential threats. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.user) as @@ -14,7 +14,7 @@ search: '| tstats `security_content_summariesonly` count values(Processes.user) max(_time) as lastTime from datamodel=Endpoint.Processes where `process_net` by Processes.process Processes.process_name Processes.parent_process_name Processes.original_file_name Processes.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | search process=*share* | `create_or_delete_windows_shares_using_net_exe_filter` ' + `security_content_ctime(lastTime)` | search process=*share* | `create_or_delete_windows_shares_using_net_exe_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -82,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/create_remote_thread_in_shell_application.yml b/detections/endpoint/create_remote_thread_in_shell_application.yml index 78ee8f5821..5266ae0b5d 100644 --- a/detections/endpoint/create_remote_thread_in_shell_application.yml +++ b/detections/endpoint/create_remote_thread_in_shell_application.yml @@ -1,20 +1,25 @@ name: Create Remote Thread In Shell Application id: 10399c1e-f51e-11eb-b920-acde48001122 -version: 2 -date: '2024-01-31' +version: 3 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect suspicious process injection in command shell. - This technique was seen in IcedID where it execute cmd.exe process to inject its - shellcode as part of its execution as banking trojan. It is really uncommon to have - a create remote thread execution in the following application. +description: The following analytic detects suspicious process injection in command + shell applications, specifically targeting `cmd.exe` and `powershell.exe`. It leverages + Sysmon EventCode 8 to identify the creation of remote threads within these shell + processes. This activity is significant because it is a common technique used by + malware, such as IcedID, to inject malicious code and execute it within legitimate + processes. If confirmed malicious, this behavior could allow an attacker to execute + arbitrary code, escalate privileges, or maintain persistence within the environment, + posing a severe threat to system security. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 TargetImage IN ("*\\cmd.exe", "*\\powershell*") | stats count min(_time) as firstTime max(_time) as lastTime by TargetImage TargetProcessId - SourceProcessId EventCode StartAddress SourceImage dest |rename SourceImage as process_name| `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `create_remote_thread_in_shell_application_filter`' + SourceProcessId EventCode StartAddress SourceImage dest |rename SourceImage as + process_name| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `create_remote_thread_in_shell_application_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/create_remote_thread_into_lsass.yml b/detections/endpoint/create_remote_thread_into_lsass.yml index e281f5465c..1def414675 100644 --- a/detections/endpoint/create_remote_thread_into_lsass.yml +++ b/detections/endpoint/create_remote_thread_into_lsass.yml @@ -1,16 +1,23 @@ name: Create Remote Thread into LSASS id: 67d4dbef-9564-4699-8da8-03a151529edc -version: 1 -date: '2019-12-06' +version: 2 +date: '2024-05-26' author: Patrick Bareiss, Splunk status: production type: TTP -description: "The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon EventID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats." +description: "The following analytic detects the creation of a remote thread in the + Local Security Authority Subsystem Service (LSASS). This behavior is identified + using Sysmon Event ID 8 logs, focusing on processes that create remote threads in + lsass.exe. This activity is significant because it is commonly associated with credential + dumping, a tactic used by adversaries to steal user authentication credentials. + If confirmed malicious, this could allow attackers to gain unauthorized access to + sensitive information, leading to potential compromise of the entire network. Analysts + should investigate to differentiate between legitimate tools and potential threats." data_source: - Sysmon EventID 8 search: '`sysmon` EventID=8 TargetImage=*lsass.exe | stats count min(_time) as firstTime - max(_time) as lastTime by dest, EventCode, TargetImage, TargetProcessId | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `create_remote_thread_into_lsass_filter`' + max(_time) as lastTime by dest, EventCode, TargetImage, TargetProcessId | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)` | `create_remote_thread_into_lsass_filter`' how_to_implement: This search needs Sysmon Logs with a Sysmon configuration, which includes EventCode 8 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations @@ -59,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/creation_of_lsass_dump_with_taskmgr.yml b/detections/endpoint/creation_of_lsass_dump_with_taskmgr.yml index 1dc9e795cd..28aa70a853 100644 --- a/detections/endpoint/creation_of_lsass_dump_with_taskmgr.yml +++ b/detections/endpoint/creation_of_lsass_dump_with_taskmgr.yml @@ -1,21 +1,23 @@ name: Creation of lsass Dump with Taskmgr id: b2fbe95a-9c62-4c12-8a29-24b97e84c0cd -version: 1 -date: '2020-02-03' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: Detect the hands on keyboard behavior of Windows Task Manager creating - a process dump of lsass.exe. Upon this behavior occurring, a file write/modification - will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, - cannot be renamed, however if the dump occurs more than once, it will be named lsass - (2).dmp. +description: The following analytic detects the creation of an lsass.exe process dump + using Windows Task Manager. It leverages Sysmon EventID 11 to identify file creation + events where the target filename matches *lsass*.dmp. This activity is significant + because creating an lsass dump can be a precursor to credential theft, as the dump + file contains sensitive information such as user passwords. If confirmed malicious, + an attacker could use the lsass dump to extract credentials and escalate privileges, + potentially compromising the entire network. data_source: - Sysmon EventID 1 search: '`sysmon` EventID=11 process_name=taskmgr.exe TargetFilename=*lsass*.dmp | stats count min(_time) as firstTime max(_time) as lastTime by dest, object_category, - process_name, TargetFilename | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `creation_of_lsass_dump_with_taskmgr_filter`' + process_name, TargetFilename | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `creation_of_lsass_dump_with_taskmgr_filter`' how_to_implement: This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 11 for detecting file create of lsass.dmp. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific @@ -61,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/creation_of_shadow_copy_with_wmic_and_powershell.yml b/detections/endpoint/creation_of_shadow_copy_with_wmic_and_powershell.yml index 7bd3ac26eb..95a7ef8d8d 100644 --- a/detections/endpoint/creation_of_shadow_copy_with_wmic_and_powershell.yml +++ b/detections/endpoint/creation_of_shadow_copy_with_wmic_and_powershell.yml @@ -1,12 +1,12 @@ name: Creation of Shadow Copy with wmic and powershell id: 2ed8b538-d284-449a-be1d-82ad1dbd186b -version: 3 -date: '2021-09-16' +version: 4 +date: '2024-05-18' author: Patrick Bareiss, Splunk status: production type: TTP description: |- - The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack. + The following analytic detects the creation of shadow copies using "wmic" or "Powershell" commands. It leverages the Endpoint.Processes data model in Splunk to identify processes where the command includes "shadowcopy" and "create". This activity is significant because it may indicate an attacker attempting to manipulate or access data unauthorizedly, potentially leading to data theft or manipulation. If confirmed malicious, this behavior could allow attackers to backup and exfiltrate sensitive data or hide their tracks by restoring files to a previous state after an attack. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/credential_dumping_via_copy_command_from_shadow_copy.yml b/detections/endpoint/credential_dumping_via_copy_command_from_shadow_copy.yml index f4405ef296..6cf0509fb1 100644 --- a/detections/endpoint/credential_dumping_via_copy_command_from_shadow_copy.yml +++ b/detections/endpoint/credential_dumping_via_copy_command_from_shadow_copy.yml @@ -1,11 +1,18 @@ name: Credential Dumping via Copy Command from Shadow Copy id: d8c406fe-23d2-45f3-a983-1abe7b83ff3b -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-30' author: Patrick Bareiss, Splunk status: production type: TTP -description: "The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as \"sam\", \"security\", \"system\", and \"ntds.dit\", located in system directories like \"system32\" or \"windows\". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack" +description: "The following analytic detects the use of the copy command to dump credentials + from a shadow copy. It leverages Endpoint Detection and Response (EDR) data to identify + processes with command lines referencing critical files like \"sam\", \"security\"\ + , \"system\", and \"ntds.dit\" in system directories. This activity is significant + as it indicates an attempt to extract credentials, a common technique for unauthorized + access and privilege escalation. If confirmed malicious, this could lead to attackers + gaining sensitive login information, escalating privileges, moving laterally within + the network, or accessing sensitive data." data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -15,7 +22,7 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime Processes.process_name Processes.process Processes.parent_process Processes.original_file_name Processes.process_id Processes.parent_process_id Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `credential_dumping_via_copy_command_from_shadow_copy_filter` ' + | `credential_dumping_via_copy_command_from_shadow_copy_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -71,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/credential_dumping_via_symlink_to_shadow_copy.yml b/detections/endpoint/credential_dumping_via_symlink_to_shadow_copy.yml index ba47aaacad..dcc09e8198 100644 --- a/detections/endpoint/credential_dumping_via_symlink_to_shadow_copy.yml +++ b/detections/endpoint/credential_dumping_via_symlink_to_shadow_copy.yml @@ -1,12 +1,12 @@ name: Credential Dumping via Symlink to Shadow Copy id: c5eac648-fae0-4263-91a6-773df1f4c903 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-20' author: Patrick Bareiss, Splunk status: production type: TTP description: |- - The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies. The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model. The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack. + The following analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. It leverages the Endpoint.Processes data model in Splunk to identify processes executing commands containing "mklink" and "HarddiskVolumeShadowCopy". This activity is significant because attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts. If confirmed malicious, this could prevent data restoration, complicate incident response, and lead to data loss or compromise. Analysts should review the process details, user, parent process, and any related artifacts to identify the attack source. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/csc_net_on_the_fly_compilation.yml b/detections/endpoint/csc_net_on_the_fly_compilation.yml index 560ae46297..4468e9810d 100644 --- a/detections/endpoint/csc_net_on_the_fly_compilation.yml +++ b/detections/endpoint/csc_net_on_the_fly_compilation.yml @@ -1,18 +1,18 @@ name: CSC Net On The Fly Compilation id: ea73128a-43ab-11ec-9753-acde48001122 -version: 1 -date: '2021-11-12' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Hunting -description: this analytic is to detect a suspicious compile before delivery approach - of .net compiler csc.exe. This technique was seen in several adversaries, malware - and even in red teams to take advantage the csc.exe .net compiler tool to compile - on the fly a malicious .net code to evade detection from security product. This - is a good hunting query to check further the file or process created after this - event and check the file path that passed to csc.exe which is the .net code. Aside - from that, powershell is capable of using this compiler in executing .net code in - a powershell script so filter on that case is needed. +description: The following analytic detects the use of the .NET compiler csc.exe for + on-the-fly compilation of potentially malicious .NET code. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on specific command-line + patterns associated with csc.exe. This activity is significant because adversaries + and malware often use this technique to evade detection by compiling malicious code + at runtime. If confirmed malicious, this could allow attackers to execute arbitrary + code, potentially leading to system compromise, data exfiltration, or further lateral + movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/curl_download_and_bash_execution.yml b/detections/endpoint/curl_download_and_bash_execution.yml index eaa8a68c28..0109178820 100644 --- a/detections/endpoint/curl_download_and_bash_execution.yml +++ b/detections/endpoint/curl_download_and_bash_execution.yml @@ -1,13 +1,18 @@ name: Curl Download and Bash Execution id: 900bc324-59f3-11ec-9fb4-acde48001122 -version: 1 -date: '2021-12-10' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of curl on Linux or MacOS attempting - to download a file from a remote source and pipe it to bash. This is typically found - with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +description: The following analytic detects the use of curl on Linux or MacOS systems + to download a file from a remote source and pipe it directly to bash for execution. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names, command-line arguments, and parent processes. This activity + is significant as it is commonly associated with malicious actions such as coinminers + and exploitation of vulnerabilities like CVE-2021-44228 in Log4j. If confirmed malicious, + this behavior could lead to unauthorized code execution, system compromise, and + further exploitation within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/delete_shadowcopy_with_powershell.yml b/detections/endpoint/delete_shadowcopy_with_powershell.yml index f10da283ce..4e9538f69c 100644 --- a/detections/endpoint/delete_shadowcopy_with_powershell.yml +++ b/detections/endpoint/delete_shadowcopy_with_powershell.yml @@ -1,21 +1,24 @@ name: Delete ShadowCopy With PowerShell id: 5ee2bcd0-b2ff-11eb-bb34-acde48001122 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: This following analytic detects PowerShell command to delete shadow copy - using the WMIC PowerShell module. This technique was seen used by a recent adversary - to deploy DarkSide Ransomware where it executed a child process of PowerShell to - execute a hex encoded command to delete shadow copy. This hex encoded command was - able to be decrypted by PowerShell log. +description: The following analytic detects the use of PowerShell to delete shadow + copies via the WMIC PowerShell module. It leverages EventCode 4104 and searches + for specific keywords like "ShadowCopy," "Delete," or "Remove" within the ScriptBlockText. + This activity is significant because deleting shadow copies is a common tactic used + by ransomware, such as DarkSide, to prevent data recovery. If confirmed malicious, + this action could lead to irreversible data loss and hinder recovery efforts, significantly + impacting business continuity and data integrity. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText= "*ShadowCopy*" (ScriptBlockText = "*Delete*" OR ScriptBlockText = "*Remove*") | stats count min(_time) as firstTime - max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText |rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `delete_shadowcopy_with_powershell_filter`' + max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText |rename + Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `delete_shadowcopy_with_powershell_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. @@ -61,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/deleting_of_net_users.yml b/detections/endpoint/deleting_of_net_users.yml index 5e51e74924..56b579762c 100644 --- a/detections/endpoint/deleting_of_net_users.yml +++ b/detections/endpoint/deleting_of_net_users.yml @@ -1,16 +1,17 @@ name: Deleting Of Net Users id: 1c8c6f66-acce-11eb-aafb-acde48001122 -version: 2 -date: '2023-06-13' +version: 3 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will detect a suspicious net.exe/net1.exe command-line - to delete a user on a system. This technique may be use by an administrator for - legitimate purposes, however this behavior has been used in the wild to impair some - user or deleting adversaries tracks created during its lateral movement additional - systems. During triage, review parallel processes for additional behavior. Identify - any other user accounts created before or after. +description: The following analytic detects the use of net.exe or net1.exe command-line + to delete a user account on a system. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process and command-line execution logs. + This activity is significant as it may indicate an attempt to impair user accounts + or cover tracks during lateral movement. If confirmed malicious, this could lead + to unauthorized access removal, disruption of legitimate user activities, or concealment + of adversarial actions, complicating incident response and forensic investigations. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -84,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_azurehound_command_line_arguments.yml b/detections/endpoint/detect_azurehound_command_line_arguments.yml index 239c2099c8..878510f5e2 100644 --- a/detections/endpoint/detect_azurehound_command_line_arguments.yml +++ b/detections/endpoint/detect_azurehound_command_line_arguments.yml @@ -1,22 +1,25 @@ name: Detect AzureHound Command-Line Arguments id: 26f02e96-c300-11eb-b611-acde48001122 -version: 2 -date: '2024-03-14' +version: 3 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the common command-line argument used - by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may - be modified, but these changes are dependent upon the operator. In most instances - the defaults are used. This analytic works to identify the common command-line attributes - used. It does not cover the entirety of every argument in order to avoid false positives. +description: The following analytic detects the execution of the `Invoke-AzureHound` + command-line argument, commonly used by the AzureHound tool. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant because AzureHound is often used for reconnaissance + in Azure environments, potentially exposing sensitive information. If confirmed + malicious, this activity could allow an attacker to map out Azure Active Directory + structures, aiding in further attacks and privilege escalation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process IN ("*invoke-azurehound*") - by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.parent_process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_azurehound_command_line_arguments_filter`' + by Processes.dest Processes.user Processes.parent_process Processes.process_name + Processes.parent_process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_azurehound_command_line_arguments_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -87,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_azurehound_file_modifications.yml b/detections/endpoint/detect_azurehound_file_modifications.yml index 35e426a9ec..e65d2bf826 100644 --- a/detections/endpoint/detect_azurehound_file_modifications.yml +++ b/detections/endpoint/detect_azurehound_file_modifications.yml @@ -1,25 +1,26 @@ name: Detect AzureHound File Modifications id: 1c34549e-c31b-11eb-996b-acde48001122 -version: 2 -date: '2024-03-14' +version: 3 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic is similar to SharpHound file modifications, but - this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound - equivilent but for Azure. It's possible this may never be seen in an environment - as most attackers may execute this tool remotely. Once execution is complete, a - zip file with a similar name will drop `20210601090751-azurecollection.zip`. In - addition to the zip, multiple .json files will be written to disk, which are in - the zip. +description: The following analytic detects the creation of specific AzureHound-related + files, such as `*-azurecollection.zip` and various `.json` files, on disk. It leverages + data from the Endpoint.Filesystem datamodel, focusing on file creation events with + specific filenames. This activity is significant because AzureHound is a tool used + to gather information about Azure environments, similar to SharpHound for on-premises + Active Directory. If confirmed malicious, this activity could indicate an attacker + is collecting sensitive Azure environment data, potentially leading to further exploitation + or privilege escalation within the cloud infrastructure. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*-azurecollection.zip", "*-azprivroleadminrights.json", "*-azglobaladminrights.json", "*-azcloudappadmins.json", "*-azapplicationadmins.json") by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name - Filesystem.file_path Filesystem.dest Filesystem.user | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `detect_azurehound_file_modifications_filter`' + Filesystem.file_path Filesystem.dest Filesystem.user | `drop_dm_object_name(Filesystem)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_azurehound_file_modifications_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` @@ -74,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_baron_samedit_cve_2021_3156.yml b/detections/endpoint/detect_baron_samedit_cve_2021_3156.yml index f05e62b8d9..b185a14275 100644 --- a/detections/endpoint/detect_baron_samedit_cve_2021_3156.yml +++ b/detections/endpoint/detect_baron_samedit_cve_2021_3156.yml @@ -1,12 +1,12 @@ name: Detect Baron Samedit CVE-2021-3156 id: 93fbec4e-0375-440c-8db3-4508eca470c4 -version: 1 -date: '2021-01-27' +version: 2 +date: '2024-05-15' author: Shannon Davis, Splunk status: experimental type: TTP description: |- - The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit. + The following analytic detects attempts to exploit the Baron Samedit vulnerability (CVE-2021-3156) by identifying the use of the "sudoedit -s \\" command. This detection leverages logs from Linux systems, specifically searching for instances of the sudoedit command with the "-s" flag followed by a double quote. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows attackers to gain root privileges. If confirmed malicious, this could lead to complete system compromise, unauthorized access to sensitive data, and potential data breaches. data_source: [] search: '`linux_hosts` "sudoedit -s \\" | `detect_baron_samedit_cve_2021_3156_filter`' how_to_implement: Splunk Universal Forwarder running on Linux systems, capturing logs diff --git a/detections/endpoint/detect_baron_samedit_cve_2021_3156_segfault.yml b/detections/endpoint/detect_baron_samedit_cve_2021_3156_segfault.yml index 882b8c8188..4968593a16 100644 --- a/detections/endpoint/detect_baron_samedit_cve_2021_3156_segfault.yml +++ b/detections/endpoint/detect_baron_samedit_cve_2021_3156_segfault.yml @@ -1,12 +1,12 @@ name: Detect Baron Samedit CVE-2021-3156 Segfault id: 10f2bae0-bbe6-4984-808c-37dc1c67980d -version: 1 -date: '2021-01-29' +version: 2 +date: '2024-05-28' author: Shannon Davis, Splunk status: experimental type: TTP description: |- - The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action. + The following analytic identifies a heap-based buffer overflow in sudoedit by detecting Linux logs containing both "sudoedit" and "segfault" terms. This detection leverages Splunk to monitor for more than five occurrences of these terms on a single host within a specified timeframe. This activity is significant because exploiting this vulnerability (CVE-2021-3156) can allow attackers to gain root privileges, leading to potential system compromise, unauthorized access, and data breaches. If confirmed malicious, this could result in elevated privileges and full control over the affected system, posing a severe security risk. data_source: [] search: '`linux_hosts` TERM(sudoedit) TERM(segfault) | stats count min(_time) as firstTime max(_time) as lastTime by host | where count > 5 | `detect_baron_samedit_cve_2021_3156_segfault_filter`' diff --git a/detections/endpoint/detect_baron_samedit_cve_2021_3156_via_osquery.yml b/detections/endpoint/detect_baron_samedit_cve_2021_3156_via_osquery.yml index c6b942e6d7..6a17163717 100644 --- a/detections/endpoint/detect_baron_samedit_cve_2021_3156_via_osquery.yml +++ b/detections/endpoint/detect_baron_samedit_cve_2021_3156_via_osquery.yml @@ -1,11 +1,18 @@ name: Detect Baron Samedit CVE-2021-3156 via OSQuery id: 1de31d5d-8fa6-4ee0-af89-17069134118a -version: 1 -date: '2021-01-28' +version: 2 +date: '2024-05-13' author: Shannon Davis, Splunk status: experimental type: TTP -description: "The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command \"sudoedit -s *\" is run using the osquery_process data source. This indicates that the sudoedit command is used with the \"-s\" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the \"-s\" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment." +description: "The following analytic detects the execution of the \"sudoedit -s *\"\ + \ command, which is associated with the Baron Samedit CVE-2021-3156 heap-based buffer + overflow vulnerability. This detection leverages the `osquery_process` data source + to identify instances where this specific command is run. This activity is significant + because it indicates an attempt to exploit a known vulnerability that allows privilege + escalation. If confirmed malicious, an attacker could gain full control of the system, + execute arbitrary code, or access sensitive data, leading to potential data breaches + and system disruptions." data_source: [] search: '`osquery_process` | search "columns.cmdline"="sudoedit -s \\*" | `detect_baron_samedit_cve_2021_3156_via_osquery_filter`' how_to_implement: OSQuery installed and configured to pick up process events (info diff --git a/detections/endpoint/detect_certify_command_line_arguments.yml b/detections/endpoint/detect_certify_command_line_arguments.yml index b530dc7d8d..52dd482e6e 100644 --- a/detections/endpoint/detect_certify_command_line_arguments.yml +++ b/detections/endpoint/detect_certify_command_line_arguments.yml @@ -1,14 +1,18 @@ name: Detect Certify Command Line Arguments id: e6d2dc61-a8b9-4b03-906c-da0ca75d71b8 -version: 1 -date: '2023-06-25' +version: 2 +date: '2024-05-25' author: Steven Dick status: production type: TTP -description: The following analytic identifies when the attacker tool Certify or Certipy - are used to enumerate Active Directory Certificate Services (AD CS) environments. - The default command line arguments of these tools are similar and perform near identical - enumeration or exploitation functions. +description: The following analytic detects the use of Certify or Certipy tools to + enumerate Active Directory Certificate Services (AD CS) environments. It leverages + Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments + associated with these tools. This activity is significant because it indicates potential + reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized + access or privilege escalation. If confirmed malicious, attackers could gain insights + into the AD CS infrastructure, potentially compromising sensitive certificates and + escalating their privileges within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/detect_certify_with_powershell_script_block_logging.yml b/detections/endpoint/detect_certify_with_powershell_script_block_logging.yml index d05be57045..6255204005 100644 --- a/detections/endpoint/detect_certify_with_powershell_script_block_logging.yml +++ b/detections/endpoint/detect_certify_with_powershell_script_block_logging.yml @@ -1,23 +1,34 @@ name: Detect Certify With PowerShell Script Block Logging id: f533ca6c-9440-4686-80cb-7f294c07812a -version: 1 -date: '2023-06-25' +version: 2 +date: '2024-05-12' author: Steven Dick status: production type: TTP -description: The following analytic identifies when the attacker tool Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions. +description: The following analytic detects the use of the Certify tool via an in-memory + PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. + It leverages PowerShell Script Block Logging (EventCode 4104) to identify specific + command patterns associated with Certify's enumeration and exploitation functions. + This activity is significant as it indicates potential reconnaissance or exploitation + attempts against AD CS, which could lead to unauthorized certificate issuance. If + confirmed malicious, attackers could leverage this to escalate privileges, persist + in the environment, or access sensitive information by abusing AD CS. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 (ScriptBlockText IN ("*find *") AND ScriptBlockText IN ("* /vulnerable*","* -vulnerable*","* /enrolleeSuppliesSubject *","* /json /outfile*")) OR (ScriptBlockText IN (,"*auth *","*req *",) AND ScriptBlockText IN ("* -ca *","* -username *","* -u *")) OR (ScriptBlockText IN ("*request *","*download *") AND ScriptBlockText IN ("* /ca:*")) - | stats count min(_time) as firstTime max(_time) as lastTime list(ScriptBlockText) as command Values(OpCode) as reason values(Path) as file_name values(UserID) as user by _time Computer EventCode - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | eval file_name = case(isnotnull(file_name),file_name,true(),"unknown") - | eval signature = substr(command,0,256) - | rename Computer as dest,EventCode as signature_id - | `detect_certify_with_powershell_script_block_logging_filter`' -how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.. -known_false_positives: Unknown, partial script block matches. +search: '`powershell` EventCode=4104 (ScriptBlockText IN ("*find *") AND ScriptBlockText + IN ("* /vulnerable*","* -vulnerable*","* /enrolleeSuppliesSubject *","* /json /outfile*")) + OR (ScriptBlockText IN (,"*auth *","*req *",) AND ScriptBlockText IN ("* -ca *","* + -username *","* -u *")) OR (ScriptBlockText IN ("*request *","*download *") AND + ScriptBlockText IN ("* /ca:*")) | stats count min(_time) as firstTime max(_time) + as lastTime list(ScriptBlockText) as command Values(OpCode) as reason values(Path) + as file_name values(UserID) as user by _time Computer EventCode | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | eval file_name = case(isnotnull(file_name),file_name,true(),"unknown") + | eval signature = substr(command,0,256) | rename Computer as dest,EventCode as + signature_id | `detect_certify_with_powershell_script_block_logging_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.. +known_false_positives: Unknown, partial script block matches. references: - https://github.com/GhostPack/Certify - https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf @@ -52,14 +63,15 @@ tags: - OpCode - Path - user - - Computer + - Computer - EventCode risk_score: 90 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/detect_certipy_file_modifications.yml b/detections/endpoint/detect_certipy_file_modifications.yml index 4665d10f04..ea93660b54 100644 --- a/detections/endpoint/detect_certipy_file_modifications.yml +++ b/detections/endpoint/detect_certipy_file_modifications.yml @@ -1,25 +1,38 @@ name: Detect Certipy File Modifications id: 7e3df743-b1d8-4631-8fa8-bd5819688876 -version: 1 -date: '2023-06-25' +version: 2 +date: '2024-05-27' author: Steven Dick status: production type: TTP -description: The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process. +description: The following analytic detects the use of the Certipy tool to enumerate + Active Directory Certificate Services (AD CS) environments by identifying unique + file modifications. It leverages endpoint process and filesystem data to spot the + creation of files with specific names or extensions associated with Certipy's information + gathering and exfiltration activities. This activity is significant as it indicates + potential reconnaissance and data exfiltration efforts by an attacker. If confirmed + malicious, this could lead to unauthorized access to sensitive AD CS information, + enabling further attacks or privilege escalation within the network. data_source: - Windows Event Log Security 4663 - Sysmon EventID 11 -search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) AS lastTime values(Processes.process_current_directory) as process_current_directory FROM datamodel=Endpoint.Processes where Processes.action="allowed" BY _time span=1h Processes.user Processes.dest Processes.process_id Processes.process_name Processes.process Processes.process_path Processes.parent_process_name Processes.parent_process Processes.process_guid Processes.action - |`drop_dm_object_name(Processes)` - | join max=0 dest process_guid [| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*_certipy.zip", "*_certipy.txt", "*_certipy.json", "*.ccache") by Filesystem.file_create_time Filesystem.process_id Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.dest - | `drop_dm_object_name(Filesystem)` - ] - | fields firstTime lastTime user dest file_create_time file_name file_path parent_process_name parent_process process_name process_path process_current_directory process process_guid process_id - | where isnotnull(file_name) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `detect_certipy_file_modifications_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints as well as file creation or deletion events. +search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) + AS lastTime values(Processes.process_current_directory) as process_current_directory + FROM datamodel=Endpoint.Processes where Processes.action="allowed" BY _time span=1h + Processes.user Processes.dest Processes.process_id Processes.process_name Processes.process + Processes.process_path Processes.parent_process_name Processes.parent_process Processes.process_guid + Processes.action |`drop_dm_object_name(Processes)` | join max=0 dest process_guid + [| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*_certipy.zip", + "*_certipy.txt", "*_certipy.json", "*.ccache") by Filesystem.file_create_time Filesystem.process_id + Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.dest + | `drop_dm_object_name(Filesystem)` ] | fields firstTime lastTime user dest file_create_time + file_name file_path parent_process_name parent_process process_name process_path + process_current_directory process process_guid process_id | where isnotnull(file_name) + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_certipy_file_modifications_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + logs with the process name, parent process, and command-line executions from your + endpoints as well as file creation or deletion events. known_false_positives: Unknown references: - https://github.com/ly4k/Certipy @@ -58,28 +71,29 @@ tags: - Splunk Cloud required_fields: - _time - - Processes.user - - Processes.dest - - Processes.process_id - - Processes.process_name - - Processes.process - - Processes.process_path - - Processes.parent_process_name - - Processes.parent_process - - Processes.process_guid + - Processes.user + - Processes.dest + - Processes.process_id + - Processes.process_name + - Processes.process + - Processes.process_path + - Processes.parent_process_name + - Processes.parent_process + - Processes.process_guid - Processes.action - - Filesystem.file_create_time - - Filesystem.process_id - - Filesystem.process_guid - - Filesystem.file_name - - Filesystem.file_path + - Filesystem.file_create_time + - Filesystem.process_id + - Filesystem.process_guid + - Filesystem.file_name + - Filesystem.file_path - Filesystem.dest risk_score: 45 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/endpoint/detect_copy_of_shadowcopy_with_script_block_logging.yml b/detections/endpoint/detect_copy_of_shadowcopy_with_script_block_logging.yml index f06e85ddcc..123f62d901 100644 --- a/detections/endpoint/detect_copy_of_shadowcopy_with_script_block_logging.yml +++ b/detections/endpoint/detect_copy_of_shadowcopy_with_script_block_logging.yml @@ -1,30 +1,24 @@ name: Detect Copy of ShadowCopy with Script Block Logging id: 9251299c-ea5b-11eb-a8de-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture - the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the - most basic use cases for credentials being taken for offline cracking. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the use of PowerShell commands to copy + the SAM, SYSTEM, or SECURITY hives, which are critical for credential theft. It + leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze + the full command executed. This activity is significant as it indicates an attempt + to exfiltrate sensitive registry hives for offline password cracking. If confirmed + malicious, this could lead to unauthorized access to credentials, enabling further + compromise of the system and potential lateral movement within the network.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN ("*copy*","*[System.IO.File]::Copy*") - AND ScriptBlockText IN ("*System32\\config\\SAM*", "*System32\\config\\SYSTEM*","*System32\\config\\SECURITY*") + AND ScriptBlockText IN ("*System32\\config\\SAM*", "*System32\\config\\SYSTEM*","*System32\\config\\SECURITY*") | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer - UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `detect_copy_of_shadowcopy_with_script_block_logging_filter`' + UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_copy_of_shadowcopy_with_script_block_logging_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -62,16 +56,17 @@ tags: - Splunk Cloud required_fields: - _time - - Message + - ScriptBlockText - OpCode - - ComputerName - - User + - Computer + - UserID - EventCode risk_score: 80 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/detect_copy_of_shadowcopy_with_script_block_logging/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/detect_copy_of_shadowcopy_with_script_block_logging/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/detect_credential_dumping_through_lsass_access.yml b/detections/endpoint/detect_credential_dumping_through_lsass_access.yml index d93fb9b233..77f0b0e806 100644 --- a/detections/endpoint/detect_credential_dumping_through_lsass_access.yml +++ b/detections/endpoint/detect_credential_dumping_through_lsass_access.yml @@ -1,28 +1,24 @@ name: Detect Credential Dumping through LSASS access id: 2c365e57-4414-4540-8dc0-73ab10729996 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-28' author: Patrick Bareiss, Splunk status: production type: TTP -description: The following analytic detects the reading of lsass memory, which is - consistent with credential dumping. Reading lsass memory is a common technique used - by attackers to steal credentials from the Windows operating system. The detection - is made by monitoring the sysmon events and filtering for specific access permissions - (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances - of credential dumping.The detection is important because it suggests that an attacker - is attempting to extract credentials from the lsass memory, which can lead to unauthorized - access, data breaches, and compromise of sensitive information. Credential dumping - is often a precursor to further attacks, such as lateral movement, privilege escalation, - or data exfiltration. False positives can occur due to legitimate actions that involve - accessing lsass memory. Therefore, extensive triage and investigation are necessary - to differentiate between malicious and benign activities. +description: The following analytic detects attempts to read LSASS memory, indicative + of credential dumping. It leverages Sysmon EventCode 10, filtering for specific + access permissions (0x1010 and 0x1410) on the lsass.exe process. This activity is + significant because it suggests an attacker is trying to extract credentials from + LSASS memory, potentially leading to unauthorized access, data breaches, and compromise + of sensitive information. If confirmed malicious, this could enable attackers to + escalate privileges, move laterally within the network, or exfiltrate data. Extensive + triage is necessary to differentiate between malicious and benign activities. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410) | stats count min(_time) as firstTime max(_time) as lastTime by dest, SourceImage, SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `detect_credential_dumping_through_lsass_access_filter` ' + `security_content_ctime(lastTime)` | `detect_credential_dumping_through_lsass_access_filter`' how_to_implement: This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations @@ -75,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml b/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml index 7b364ec96c..51deda2276 100644 --- a/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml +++ b/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml @@ -1,24 +1,18 @@ name: Detect Empire with PowerShell Script Block Logging id: bc1dc6b8-c954-11eb-bade-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies the common PowerShell stager used by PowerShell-Empire. - Each stager that may use PowerShell all uses the same pattern. The initial HTTP - will be base64 encoded and use `system.net.webclient`. Note that some obfuscation - may evade the analytic. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects suspicious PowerShell execution indicative + of PowerShell-Empire activity. It leverages PowerShell Script Block Logging (EventCode=4104) + to capture and analyze commands sent to PowerShell, specifically looking for patterns + involving `system.net.webclient` and base64 encoding. This behavior is significant + as it often represents initial stagers used by PowerShell-Empire, a known post-exploitation + framework. If confirmed malicious, this activity could allow attackers to download + and execute additional payloads, leading to potential code execution, data exfiltration, + or further compromise of the affected system.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText=*system.net.webclient* AND @@ -76,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/empire.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/empire.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_exchange_web_shell.yml b/detections/endpoint/detect_exchange_web_shell.yml index d993e04357..da8c1f8422 100644 --- a/detections/endpoint/detect_exchange_web_shell.yml +++ b/detections/endpoint/detect_exchange_web_shell.yml @@ -1,44 +1,32 @@ name: Detect Exchange Web Shell id: 8c14eeee-2af1-4a4b-bda8-228da0f4862a -version: 5 -date: '2023-11-07' +version: 6 +date: '2024-05-21' author: Michael Haag, Shannon Davis, David Dorsey, Splunk status: production type: TTP -description: 'The following query identifies suspicious .aspx created in 3 paths identified - by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM - group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths - include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. - Upon triage, the suspicious .aspx file will likely look obvious on the surface. - inspect the contents for script code inside. Identify additional log sources, IIS - included, to review source and other potential exploitation. It is often the case - that a particular threat is only applicable to a specific subset of systems in your - environment. Typically analytics to detect those threats are written without the - benefit of being able to only target those systems as well. Writing analytics against - all systems when those behaviors are limited to identifiable subsets of those systems - is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange - Servers. With asset information, a hunter can limit their analytics to systems that - have been identified as Exchange servers. A hunter may start with the theory that - the exchange server is communicating with new systems that it has not previously. - If this theory is run against all publicly facing systems, the amount of noise it - will generate will likely render this theory untenable. However, using the asset - information to limit this analytic to just the Exchange servers will reduce the - noise allowing the hunter to focus only on the systems where this behavioral change - is relevant.' +description: 'The following analytic identifies the creation of suspicious .aspx files + in known drop locations for Exchange exploitation, specifically targeting paths + associated with HAFNIUM group and vulnerabilities like ProxyShell and ProxyNotShell. + It leverages data from the Endpoint datamodel, focusing on process and filesystem + events. This activity is significant as it may indicate a web shell deployment, + a common method for persistent access and remote code execution. If confirmed malicious, + attackers could gain unauthorized access, execute arbitrary commands, and potentially + escalate privileges within the Exchange environment.' data_source: - Sysmon EventID 1 - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name=System by _time span=1h Processes.process_id Processes.process_name - Processes.dest Processes.user | `drop_dm_object_name(Processes)` | join process_guid, _time [| - tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + Processes.dest Processes.user | `drop_dm_object_name(Processes)` | join process_guid, + _time [| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\HttpProxy\\owa\\auth\\*", "*\\inetpub\\wwwroot\\aspnet_client\\*", "*\\HttpProxy\\OAB\\*") Filesystem.file_name IN( "*.aspx", "*.ashx") by _time span=1h Filesystem.user Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path | `drop_dm_object_name(Filesystem)` | fields _time dest user file_create_time file_name file_path process_name process_path - process] | dedup file_create_time | table dest user file_create_time, file_name, file_path, - process_name | `detect_exchange_web_shell_filter`' + process] | dedup file_create_time | table dest user file_create_time, file_name, + file_path, process_name | `detect_exchange_web_shell_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` @@ -98,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/windows-sysmon_proxylogon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/windows-sysmon_proxylogon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_html_help_renamed.yml b/detections/endpoint/detect_html_help_renamed.yml index 477f276ea8..60171a55be 100644 --- a/detections/endpoint/detect_html_help_renamed.yml +++ b/detections/endpoint/detect_html_help_renamed.yml @@ -1,21 +1,18 @@ name: Detect HTML Help Renamed id: 62fed254-513b-460e-953d-79771493a9f3 -version: 4 -date: '2022-04-07' +version: 5 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies a renamed instance of hh.exe (HTML - Help) executing a Compiled HTML Help (CHM). This particular technique will load - Windows script code from a compiled help file. CHM files may contain nearly any - file type embedded, but only execute html/htm. Upon a successful execution, the - following script engines may be used for execution - JScript, VBScript, VBScript.Encode, - JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll - loading into hh.exe upon execution. The "htm" and "html" file extensions were the - only extensions observed to be supported for the execution of Shortcut commands - or WSH script code. During investigation, identify script content origination. Validate - it is the legitimate version of hh.exe by reviewing the PE metadata. hh.exe is natively - found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects instances where hh.exe (HTML Help) has + been renamed and is executing a Compiled HTML Help (CHM) file. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and original file names. This activity is significant because attackers can use + renamed hh.exe to execute malicious scripts embedded in CHM files, potentially leading + to code execution. If confirmed malicious, this technique could allow attackers + to run arbitrary scripts, escalate privileges, or persist within the environment, + posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -46,7 +43,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 80 - message: The following $process_name$ has been identified as renamed, spawning from $parent_process_name$ on $dest$ executed by $user$ + message: The following $process_name$ has been identified as renamed, spawning from + $parent_process_name$ on $dest$ executed by $user$ mitre_attack_id: - T1218 - T1218.001 @@ -89,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_html_help_spawn_child_process.yml b/detections/endpoint/detect_html_help_spawn_child_process.yml index e282b1e4d2..f0f773852e 100644 --- a/detections/endpoint/detect_html_help_spawn_child_process.yml +++ b/detections/endpoint/detect_html_help_spawn_child_process.yml @@ -1,28 +1,26 @@ name: Detect HTML Help Spawn Child Process id: 723716de-ee55-4cd4-9759-c44e7e55ba4b -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies hh.exe (HTML Help) execution of a Compiled - HTML Help (CHM) that spawns a child process. This particular technique will load - Windows script code from a compiled help file. CHM files may contain nearly any - file type embedded, but only execute html/htm. Upon a successful execution, the - following script engines may be used for execution - JScript, VBScript, VBScript.Encode, - JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll - loading into hh.exe upon execution. The "htm" and "html" file extensions were the - only extensions observed to be supported for the execution of Shortcut commands - or WSH script code. During investigation, identify script content origination. Review - child process events and investigate further. hh.exe is natively found in C:\Windows\system32 - and C:\Windows\syswow64. +description: The following analytic detects the execution of hh.exe (HTML Help) spawning + a child process, indicating the use of a Compiled HTML Help (CHM) file to execute + Windows script code. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process creation events where hh.exe is the parent process. + This activity is significant as it may indicate an attempt to execute malicious + scripts via CHM files, a known technique for bypassing security controls. If confirmed + malicious, this could lead to unauthorized code execution, potentially compromising + the system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=hh.exe - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_html_help_spawn_child_process_filter`' + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_html_help_spawn_child_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -93,6 +91,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_html_help_url_in_command_line.yml b/detections/endpoint/detect_html_help_url_in_command_line.yml index c4048d82f6..4c4b6b1eb6 100644 --- a/detections/endpoint/detect_html_help_url_in_command_line.yml +++ b/detections/endpoint/detect_html_help_url_in_command_line.yml @@ -1,29 +1,25 @@ name: Detect HTML Help URL in Command Line id: 8c5835b9-39d9-438b-817c-95f14c69a31e -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies hh.exe (HTML Help) execution of a Compiled - HTML Help (CHM) file from a remote url. This particular technique will load Windows - script code from a compiled help file. CHM files may contain nearly any file type - embedded, but only execute html/htm. Upon a successful execution, the following - script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, - JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe - upon execution. The "htm" and "html" file extensions were the only extensions observed - to be supported for the execution of Shortcut commands or WSH script code. During - investigation, identify script content origination. Review reputation of remote - IP and domain. Some instances, it is worth decompiling the .chm file to review its - original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects the execution of hh.exe (HTML Help) loading + a Compiled HTML Help (CHM) file from a remote URL. This detection leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line executions + containing URLs. This activity is significant as it can indicate an attempt to execute + malicious scripts via CHM files, potentially leading to unauthorized code execution. + If confirmed malicious, this could allow an attacker to run scripts using engines + like JScript or VBScript, leading to further system compromise or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_hh` Processes.process=*http* - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.original_file_name - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `detect_html_help_url_in_command_line_filter`' + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.original_file_name Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `detect_html_help_url_in_command_line_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -94,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_html_help_using_infotech_storage_handlers.yml b/detections/endpoint/detect_html_help_using_infotech_storage_handlers.yml index 466acb1996..698a35211c 100644 --- a/detections/endpoint/detect_html_help_using_infotech_storage_handlers.yml +++ b/detections/endpoint/detect_html_help_using_infotech_storage_handlers.yml @@ -1,23 +1,18 @@ name: Detect HTML Help Using InfoTech Storage Handlers id: 0b2eefa5-5508-450d-b970-3dd2fb761aec -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies hh.exe (HTML Help) execution of a Compiled - HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique - will load Windows script code from a compiled help file, using InfoTech Storage - Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are - supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm - file from within a CHM file. CHM files may contain nearly any file type embedded. - Upon a successful execution, the following script engines may be used for execution - - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may - identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" - and "html" file extensions were the only extensions observed to be supported for - the execution of Shortcut commands or WSH script code. During investigation, identify - script content origination. hh.exe is natively found in C:\Windows\system32 and - C:\Windows\syswow64. +description: The following analytic detects the execution of hh.exe (HTML Help) using + InfoTech Storage Handlers to load Windows script code from a Compiled HTML Help + (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line executions. This activity is + significant because it can be used to execute malicious scripts embedded within + CHM files, potentially leading to code execution. If confirmed malicious, this technique + could allow an attacker to execute arbitrary code, escalate privileges, or persist + within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml b/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml index 4ad517f7e1..5e546a2561 100644 --- a/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml +++ b/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml @@ -1,23 +1,18 @@ name: Detect Mimikatz With PowerShell Script Block Logging id: 8148c29c-c952-11eb-9255-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable no critical endpoints or all. - - - This analytic identifies common Mimikatz functions that may be identified in the - script block, including `mimikatz`. This will catch the most basic use cases for - Pass the Ticket, Pass the Hash and `-DumprCreds`. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of Mimikatz commands via + PowerShell by leveraging PowerShell Script Block Logging (EventCode=4104). This + method captures and logs the full command sent to PowerShell, allowing for the identification + of suspicious activities such as Pass the Ticket, Pass the Hash, and credential + dumping. This activity is significant as Mimikatz is a well-known tool used for + credential theft and lateral movement. If confirmed malicious, this could lead to + unauthorized access, privilege escalation, and potential compromise of sensitive + information within the environment.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN (*mimikatz*, *-dumpcr*, *sekurlsa::pth*, @@ -77,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/credaccess-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/credaccess-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_mshta_inline_hta_execution.yml b/detections/endpoint/detect_mshta_inline_hta_execution.yml index 6bc5622ccb..af7f3f9e8b 100644 --- a/detections/endpoint/detect_mshta_inline_hta_execution.yml +++ b/detections/endpoint/detect_mshta_inline_hta_execution.yml @@ -1,15 +1,18 @@ name: Detect mshta inline hta execution id: a0873b32-5b68-11eb-ae93-0242ac130002 -version: 6 -date: '2021-09-16' +version: 7 +date: '2024-05-21' author: Bhavin Patel, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies "mshta.exe" execution with inline protocol - handlers. "JavaScript", "VBScript", and "About" are the only supported options when - invoking HTA content directly on the command-line. The search will return the first - time and last time these command-line arguments were used for these executions, - as well as the target system, the user, process "mshta.exe" and its parent process. +description: The following analytic detects the execution of "mshta.exe" with inline + protocol handlers such as "JavaScript", "VBScript", and "About". It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments + and process details. This activity is significant because mshta.exe can be exploited + to execute malicious scripts, potentially leading to unauthorized code execution. + If confirmed malicious, this could allow an attacker to execute arbitrary code, + escalate privileges, or establish persistence within the environment, posing a severe + security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -86,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_mshta_renamed.yml b/detections/endpoint/detect_mshta_renamed.yml index 5ea00ace24..b158d5c8be 100644 --- a/detections/endpoint/detect_mshta_renamed.yml +++ b/detections/endpoint/detect_mshta_renamed.yml @@ -1,15 +1,17 @@ name: Detect mshta renamed id: 8f45fcf0-5b68-11eb-ae93-0242ac130002 -version: 3 -date: '2022-04-07' +version: 4 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies renamed instances of mshta.exe executing. - Mshta.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. This - analytic utilizes the internal name of the PE to identify if is the legitimate mshta - binary. Further analysis should be performed to review the executed content and - validation it is the real mshta. +description: The following analytic identifies instances where mshta.exe has been + renamed and executed. It leverages Endpoint Detection and Response (EDR) data, specifically + focusing on the original file name field to detect discrepancies. This activity + is significant because renaming mshta.exe is a common tactic used by attackers to + evade detection and execute malicious scripts. If confirmed malicious, this could + allow an attacker to execute arbitrary code, potentially leading to system compromise, + data exfiltration, or further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -39,7 +41,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 80 - message: The following $process_name$ has been identified as renamed, spawning from $parent_process_name$ on $dest$ executed by user $user$ + message: The following $process_name$ has been identified as renamed, spawning from + $parent_process_name$ on $dest$ executed by user $user$ mitre_attack_id: - T1218 - T1218.005 @@ -82,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_mshta_url_in_command_line.yml b/detections/endpoint/detect_mshta_url_in_command_line.yml index d1ed710267..185cb9a885 100644 --- a/detections/endpoint/detect_mshta_url_in_command_line.yml +++ b/detections/endpoint/detect_mshta_url_in_command_line.yml @@ -1,17 +1,17 @@ name: Detect MSHTA Url in Command Line id: 9b3af1e6-5b68-11eb-ae93-0242ac130002 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: This analytic identifies when Microsoft HTML Application Host (mshta.exe) - utility is used to make remote http connections. Adversaries may use mshta.exe to - proxy the download and execution of remote .hta files. The analytic identifies command - line arguments of http and https being used. This technique is commonly used by - malicious software to bypass preventative controls. The search will return the first - time and last time these command-line arguments were used for these executions, - as well as the target system, the user, process "rundll32.exe" and its parent process. +description: The following analytic detects the use of Microsoft HTML Application + Host (mshta.exe) to make remote HTTP or HTTPS connections. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on command-line arguments + containing URLs. This activity is significant because adversaries often use mshta.exe + to download and execute remote .hta files, bypassing security controls. If confirmed + malicious, this behavior could allow attackers to execute arbitrary code, potentially + leading to system compromise, data exfiltration, or further network infiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -87,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_new_local_admin_account.yml b/detections/endpoint/detect_new_local_admin_account.yml index 89ebf1b519..f85f0831f8 100644 --- a/detections/endpoint/detect_new_local_admin_account.yml +++ b/detections/endpoint/detect_new_local_admin_account.yml @@ -1,20 +1,18 @@ name: Detect New Local Admin account id: b25f6f62-0712-43c1-b203-083231ffd97d -version: 3 -date: '2024-02-14' +version: 4 +date: '2024-05-15' author: David Dorsey, Splunk status: production type: TTP description: |- - The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack. + The following analytic detects the creation of new accounts elevated to local administrators. It uses Windows event logs, specifically EventCode 4720 (user account creation) and EventCode 4732 (user added to Administrators group). This activity is significant as it indicates potential unauthorized privilege escalation, which is critical for SOC monitoring. If confirmed malicious, this could allow attackers to gain administrative access, leading to unauthorized data access, system modifications, and disruption of services. Immediate investigation is required to mitigate risks and prevent further unauthorized actions. data_source: - Windows Event Log Security 4732 - Windows Event Log Security 4720 -search: '`wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) - | transaction src_user connected=false maxspan=180m - | rename src_user as user - | stats count min(_time) as firstTime max(_time) as lastTime by user dest - | `security_content_ctime(firstTime)` +search: '`wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) + | transaction src_user connected=false maxspan=180m | rename src_user as user | + stats count min(_time) as firstTime max(_time) as lastTime by user dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_new_local_admin_account_filter`' how_to_implement: You must be ingesting Windows event logs using the Splunk Windows TA and collecting event code 4720 and 4732 @@ -61,12 +59,15 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-system.log source: WinEventLog:System sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_outlook_exe_writing_a_zip_file.yml b/detections/endpoint/detect_outlook_exe_writing_a_zip_file.yml index 426953581a..dc47120c0d 100644 --- a/detections/endpoint/detect_outlook_exe_writing_a_zip_file.yml +++ b/detections/endpoint/detect_outlook_exe_writing_a_zip_file.yml @@ -29,7 +29,7 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max( | `security_content_ctime(lastTime)` | rename process_id as malicious_id| fields malicious_id outlook_id dest file_path file_name file_hash count file_id] | table firstTime lastTime user malicious_id outlook_id process_name parent_process_name - file_name file_path | where file_name != "" | `detect_outlook_exe_writing_a_zip_file_filter` ' + file_name file_path | where file_name != "" | `detect_outlook_exe_writing_a_zip_file_filter`' how_to_implement: You must be ingesting data that records filesystem and process activity from your hosts to populate the Endpoint data model. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or endpoint data diff --git a/detections/endpoint/detect_psexec_with_accepteula_flag.yml b/detections/endpoint/detect_psexec_with_accepteula_flag.yml index b7a2d0b946..3eeaf9e622 100644 --- a/detections/endpoint/detect_psexec_with_accepteula_flag.yml +++ b/detections/endpoint/detect_psexec_with_accepteula_flag.yml @@ -1,18 +1,18 @@ name: Detect PsExec With accepteula Flag id: 27c3a83d-cada-47c6-9042-67baf19d2574 -version: 4 -date: '2021-09-16' +version: 5 +date: '2024-05-23' author: Bhavin Patel, Splunk status: production type: TTP -description: This search looks for events where `PsExec.exe` is run with the `accepteula` - flag in the command line. PsExec is a built-in Windows utility that enables you - to execute processes on other systems. It is fully interactive for console applications. - This tool is widely used for launching interactive command prompts on remote systems. - Threat actors leverage this extensively for executing code on compromised systems. - If an attacker is running PsExec for the first time, they will be prompted to accept - the end-user license agreement (EULA), which can be passed as the argument `accepteula` - within the command line. +description: The following analytic identifies the execution of `PsExec.exe` with + the `accepteula` flag in the command line. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs and command-line arguments. + This activity is significant because PsExec is commonly used by threat actors to + execute code on remote systems, and the `accepteula` flag indicates first-time usage, + which could signify initial compromise. If confirmed malicious, this activity could + allow attackers to gain remote code execution capabilities, potentially leading + to further system compromise and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -97,6 +97,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rare_executables.yml b/detections/endpoint/detect_rare_executables.yml index af55c38e2b..ea623d3505 100644 --- a/detections/endpoint/detect_rare_executables.yml +++ b/detections/endpoint/detect_rare_executables.yml @@ -1,23 +1,24 @@ name: Detect Rare Executables id: 44fddcb2-8d3b-454c-874e-7c6de5a4f7ac -version: 4 -date: '2024-03-12' +version: 5 +date: '2024-05-21' author: Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic detects the occurrence of rare processes that appear only once across the network within a specified timeframe. - It operates by compiling a list of process executions. This detection is crucial for a Security Operations Center (SOC) as it helps in identifying - potentially malicious activities or unauthorized software that could indicate a security breach or an ongoing attack. Identifying such rare processes - allows for early detection of threats, minimizing the potential impact of an attack which could range from data theft to complete system compromise. +description: The following analytic detects the execution of rare processes that appear + only once across the network within a specified timeframe. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process execution logs. + This activity is significant for a SOC as it helps identify potentially malicious + activities or unauthorized software, which could indicate a security breach or ongoing + attack. If confirmed malicious, such rare processes could lead to data theft, privilege + escalation, or complete system compromise, making early detection crucial for minimizing + impact. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` dc(Processes.dest) as dc_dest values(Processes.dest) as - dest values(Processes.user) as user min(_time) as firstTime max(_time) as lastTime - from datamodel=Endpoint.Processes by Processes.process_name - | `drop_dm_object_name(Processes)` - | search dc_dest < 10 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '| tstats `security_content_summariesonly` dc(Processes.dest) as dc_dest values(Processes.dest) + as dest values(Processes.user) as user min(_time) as firstTime max(_time) as lastTime + from datamodel=Endpoint.Processes by Processes.process_name | `drop_dm_object_name(Processes)` + | search dc_dest < 10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_rare_executables_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -29,7 +30,7 @@ how_to_implement: The detection is based on data that originates from Endpoint D data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. known_false_positives: Some legitimate processes may be only rarely executed in your - environment. + environment. references: [] tags: analytic_story: @@ -38,7 +39,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A rare process - [$process_name$] has been detected on less than 10 hosts in your environment. + message: A rare process - [$process_name$] has been detected on less than 10 hosts + in your environment. mitre_attack_id: - T1204 observable: @@ -60,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/rare_executables/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204/rare_executables/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rclone_command_line_usage.yml b/detections/endpoint/detect_rclone_command_line_usage.yml index 592da7417e..29882711c6 100644 --- a/detections/endpoint/detect_rclone_command_line_usage.yml +++ b/detections/endpoint/detect_rclone_command_line_usage.yml @@ -1,26 +1,28 @@ name: Detect RClone Command-Line Usage id: 32e0baea-b3f1-11eb-a2ce-acde48001122 -version: 2 -date: '2021-11-29' +version: 3 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: This analytic identifies commonly used command-line arguments used by - `rclone.exe` to initiate a file transfer. Some arguments were negated as they are - specific to the configuration used by adversaries. In particular, an adversary may - list the files or directories of the remote file share using `ls` or `lsd`, which - is not indicative of malicious behavior. During triage, at this stage of a ransomware - event, exfiltration is about to occur or has already. Isolate the endpoint and continue - investigating by review file modifications and parallel processes. +description: The following analytic detects the usage of `rclone.exe` with specific + command-line arguments indicative of file transfer activities. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line executions + and process details. This activity is significant as `rclone.exe` is often used + by adversaries for data exfiltration, especially during ransomware attacks. If confirmed + malicious, this behavior could lead to unauthorized data transfer, resulting in + data breaches and potential loss of sensitive information. Immediate isolation of + the affected endpoint and further investigation are recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_rclone` Processes.process IN ("*copy*", "*mega*", "*pcloud*", "*ftp*", "*--config*", "*--progress*", "*--no-check-certificate*", "*--ignore-existing*", "*--auto-confirm*", "*--transfers*", "*--multi-thread-streams*") by - Processes.dest Processes.user Processes.parent_process Processes.parent_process_name Processes.process_name Processes.process - Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_rclone_command_line_usage_filter`' + Processes.dest Processes.user Processes.parent_process Processes.parent_process_name + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_rclone_command_line_usage_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -85,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1020/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1020/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regasm_spawning_a_process.yml b/detections/endpoint/detect_regasm_spawning_a_process.yml index 824ac81bc9..1bdfb85536 100644 --- a/detections/endpoint/detect_regasm_spawning_a_process.yml +++ b/detections/endpoint/detect_regasm_spawning_a_process.yml @@ -1,24 +1,26 @@ name: Detect Regasm Spawning a Process id: 72170ec5-f7d2-42f5-aefb-2b8be6aad15f -version: 3 -date: '2024-04-29' +version: 4 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies regasm.exe spawning a process. This - particular technique has been used in the wild to bypass application control products. - Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process - is rare from either process and should be investigated further. During investigation, - identify and retrieve the content being loaded. Review parallel processes for additional - suspicious behavior. Gather any other file modifications and review accordingly. - regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe - and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description: The following analytic detects regasm.exe spawning a child process. This + behavior is identified using data from Endpoint Detection and Response (EDR) agents, + focusing on process creation events where regasm.exe is the parent process. This + activity is significant because regasm.exe spawning a process is rare and can indicate + an attempt to bypass application control mechanisms. If confirmed malicious, this + could allow an attacker to execute arbitrary code, potentially leading to privilege + escalation or persistent access within the environment. Immediate investigation + is recommended to determine the legitimacy of the spawned process and any associated + activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=regasm.exe NOT (Processes.process_name IN ("conhost.exe")) - by Processes.dest Processes.user Processes.parent_process Processes.parent_process_name Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=regasm.exe + NOT (Processes.process_name IN ("conhost.exe")) by Processes.dest Processes.user + Processes.parent_process Processes.parent_process_name Processes.process_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_regasm_spawning_a_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -87,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regasm_with_network_connection.yml b/detections/endpoint/detect_regasm_with_network_connection.yml index cbf3fd3a9b..75b4df73f2 100644 --- a/detections/endpoint/detect_regasm_with_network_connection.yml +++ b/detections/endpoint/detect_regasm_with_network_connection.yml @@ -1,25 +1,22 @@ name: Detect Regasm with Network Connection id: 07921114-6db4-4e2e-ae58-3ea8a52ae93f -version: 3 -date: '2024-01-30' +version: 4 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies regasm.exe with a network connection - to a public IP address, exluding private IP space. This particular technique has - been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe - are signed by Microsoft. By contacting a remote Command And Control server, the - adversary will have the ability to escalate privileges and complete the objectives. - During investigation, identify and retrieve the content being loaded. Review parallel - processes for additional suspicious behavior. Gather any other file modifications - and review accordingly. Review the reputation of the remote IP or domain and block - as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe - and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description: The following analytic detects the execution of regasm.exe establishing + a network connection to a public IP address, excluding private IP ranges. This detection + leverages Sysmon EventID 3 logs to identify such behavior. This activity is significant + as regasm.exe is a legitimate Microsoft-signed binary that can be exploited to bypass + application control mechanisms. If confirmed malicious, this behavior could indicate + an adversary's attempt to establish a remote Command and Control (C2) channel, potentially + leading to privilege escalation and further malicious actions within the environment. data_source: - Sysmon EventID 3 search: '`sysmon` EventID=3 dest_ip!=10.0.0.0/8 dest_ip!=172.16.0.0/12 dest_ip!=192.168.0.0/16 - process_name=regasm.exe | stats count min(_time) as firstTime - max(_time) as lastTime by dest, user, process_name, src_ip, dest_ip | `security_content_ctime(firstTime)` + process_name=regasm.exe | stats count min(_time) as firstTime max(_time) as lastTime + by dest, user, process_name, src_ip, dest_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_regasm_with_network_connection_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -76,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regasm_with_no_command_line_arguments.yml b/detections/endpoint/detect_regasm_with_no_command_line_arguments.yml index 45f826c853..7efb79d1c9 100644 --- a/detections/endpoint/detect_regasm_with_no_command_line_arguments.yml +++ b/detections/endpoint/detect_regasm_with_no_command_line_arguments.yml @@ -1,19 +1,25 @@ name: Detect Regasm with no Command Line Arguments id: c3bc1430-04e7-4178-835f-047d8e6e97df -version: 3 -date: '2022-03-15' +version: 4 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies regasm.exe with no command line arguments. - This particular behavior occurs when another process injects into regasm.exe, no - command line arguments will be present. During investigation, identify any network - connections and parallel processes. Identify any suspicious module loads related - to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` - and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`. +description: The following analytic detects instances of regasm.exe running without + command line arguments. This behavior typically indicates process injection, where + another process manipulates regasm.exe. The detection leverages Endpoint Detection + and Response (EDR) data, focusing on process names and command-line executions. + This activity is significant as it may signal an attempt to evade detection or execute + malicious code. If confirmed malicious, attackers could achieve code execution, + potentially leading to privilege escalation, persistence, or access to sensitive + information. Investigate network connections, parallel processes, and suspicious + module loads for further context. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where `process_regasm` by _time span=1h Processes.process_id Processes.process_name Processes.dest Processes.user Processes.process_path Processes.process Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes + where `process_regasm` by _time span=1h Processes.process_id Processes.process_name + Processes.dest Processes.user Processes.process_path Processes.process Processes.parent_process_name + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | regex process="(?i)(regasm\.exe.{0,4}$)" | `detect_regasm_with_no_command_line_arguments_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -82,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regsvcs_spawning_a_process.yml b/detections/endpoint/detect_regsvcs_spawning_a_process.yml index adec8b27e8..91fb7c7e28 100644 --- a/detections/endpoint/detect_regsvcs_spawning_a_process.yml +++ b/detections/endpoint/detect_regsvcs_spawning_a_process.yml @@ -1,25 +1,27 @@ name: Detect Regsvcs Spawning a Process id: bc477b57-5c21-4ab6-9c33-668772e7f114 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies regsvcs.exe spawning a process. This - particular technique has been used in the wild to bypass application control products. - Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process - is rare from either process and should be investigated further. During investigation, - identify and retrieve the content being loaded. Review parallel processes for additional - suspicious behavior. Gather any other file modifications and review accordingly. - regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe - and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description: The following analytic identifies regsvcs.exe spawning a child process. + This behavior is detected using Endpoint Detection and Response (EDR) telemetry, + focusing on process creation events where the parent process is regsvcs.exe. This + activity is significant because regsvcs.exe rarely spawns child processes, and such + behavior can indicate an attempt to bypass application control mechanisms. If confirmed + malicious, this could allow an attacker to execute arbitrary code, potentially leading + to privilege escalation or persistent access within the environment. Immediate investigation + is recommended to determine the legitimacy of the spawned process and any associated + suspicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=regsvcs.exe - by Processes.parent_process_name Processes.dest Processes.user Processes.parent_process Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_regsvcs_spawning_a_process_filter`' + by Processes.parent_process_name Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_regsvcs_spawning_a_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -84,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regsvcs_with_network_connection.yml b/detections/endpoint/detect_regsvcs_with_network_connection.yml index df490c9832..10b6cd44f8 100644 --- a/detections/endpoint/detect_regsvcs_with_network_connection.yml +++ b/detections/endpoint/detect_regsvcs_with_network_connection.yml @@ -1,25 +1,23 @@ name: Detect Regsvcs with Network Connection id: e3e7a1c0-f2b9-445c-8493-f30a63522d1a -version: 3 -date: '2024-01-30' +version: 4 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies Regsvcs.exe with a network connection - to a public IP address, exluding private IP space. This particular technique has - been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe - are signed by Microsoft. By contacting a remote Command And Control server, the - adversary will have the ability to escalate privileges and complete the objectives. - During investigation, identify and retrieve the content being loaded. Review parallel - processes for additional suspicious behavior. Gather any other file modifications - and review accordingly. Review the reputation of the remote IP or domain and block - as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe - and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description: The following analytic identifies instances of Regsvcs.exe establishing + a network connection to a public IP address, excluding private IP ranges. This detection + leverages Sysmon Event ID 3 logs to monitor network connections initiated by Regsvcs.exe. + This activity is significant as Regsvcs.exe, a legitimate Microsoft-signed binary, + can be exploited to bypass application control mechanisms and establish remote Command + and Control (C2) channels. If confirmed malicious, this behavior could allow an + attacker to escalate privileges, persist in the environment, and exfiltrate sensitive + data. Immediate investigation and remediation are recommended. data_source: - Sysmon EventID 3 search: '`sysmon` EventID=3 dest_ip!=10.0.0.0/8 dest_ip!=172.16.0.0/12 dest_ip!=192.168.0.0/16 - process_name=regsvcs.exe | stats count min(_time) as firstTime - max(_time) as lastTime by dest, user, process_name, src_ip, dest_ip | `security_content_ctime(firstTime)` + process_name=regsvcs.exe | stats count min(_time) as firstTime max(_time) as lastTime + by dest, user, process_name, src_ip, dest_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_regsvcs_with_network_connection_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -75,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regsvcs_with_no_command_line_arguments.yml b/detections/endpoint/detect_regsvcs_with_no_command_line_arguments.yml index ea6938dd77..47800ef07f 100644 --- a/detections/endpoint/detect_regsvcs_with_no_command_line_arguments.yml +++ b/detections/endpoint/detect_regsvcs_with_no_command_line_arguments.yml @@ -1,16 +1,18 @@ name: Detect Regsvcs with No Command Line Arguments id: 6b74d578-a02e-4e94-a0d1-39440d0bf254 -version: 3 -date: '2022-03-15' +version: 4 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies regsvcs.exe with no command line arguments. - This particular behavior occurs when another process injects into regsvcs.exe, no - command line arguments will be present. During investigation, identify any network - connections and parallel processes. Identify any suspicious module loads related - to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe - and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description: The following analytic detects instances of regsvcs.exe running without + command line arguments. This behavior typically indicates process injection, where + another process manipulates regsvcs.exe. The detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, IDs, and command-line + executions. This activity is significant as it may signal an attempt to evade detection + and execute malicious code. If confirmed malicious, the attacker could achieve code + execution, potentially leading to privilege escalation, persistence, or access to + sensitive information. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -85,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.009/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_regsvr32_application_control_bypass.yml b/detections/endpoint/detect_regsvr32_application_control_bypass.yml index b4218e5f53..a93cf963e5 100644 --- a/detections/endpoint/detect_regsvr32_application_control_bypass.yml +++ b/detections/endpoint/detect_regsvr32_application_control_bypass.yml @@ -1,28 +1,26 @@ name: Detect Regsvr32 Application Control Bypass id: 070e9b80-6252-11eb-ae93-0242ac130002 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: 'Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. - Regsvr32.exe is a command-line program used to register and unregister object linking - and embedding controls, including dynamic link libraries (DLLs), on Windows systems. - Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is - often referred to as a "Squiblydoo" attack. - - Upon investigating, look for network connections to remote destinations (internal - or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" - is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon - execution. ' +description: 'The following analytic identifies the abuse of Regsvr32.exe to proxy + execution of malicious code, specifically detecting the loading of "scrobj.dll" + by Regsvr32.exe. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process creation events and command-line executions. This + activity is significant because Regsvr32.exe is a trusted, signed Microsoft binary, + often used in "Squiblydoo" attacks to bypass application control mechanisms. If + confirmed malicious, this technique could allow an attacker to execute arbitrary + code, potentially leading to system compromise and persistent access.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_regsvr32` Processes.process=*scrobj* - by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.parent_process_name - Processes.process Processes.original_file_name Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `detect_regsvr32_application_control_bypass_filter`' + by Processes.dest Processes.user Processes.parent_process Processes.process_name + Processes.parent_process_name Processes.process Processes.original_file_name Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)` | `detect_regsvr32_application_control_bypass_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -94,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.010/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.010/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_remote_access_software_usage_file.yml b/detections/endpoint/detect_remote_access_software_usage_file.yml index 77b504036c..bed6c42094 100644 --- a/detections/endpoint/detect_remote_access_software_usage_file.yml +++ b/detections/endpoint/detect_remote_access_software_usage_file.yml @@ -1,22 +1,36 @@ name: Detect Remote Access Software Usage File id: 3bf5541a-6a45-4fdc-b01d-59b899fff961 -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-13' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when a file from a known remote access software is written to disk within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description: The following analytic detects the writing of files from known remote + access software to disk within the environment. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on file path, file name, and user + information. This activity is significant as adversaries often use remote access + tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. + If confirmed malicious, this could allow attackers to persist in the environment, + potentially leading to data exfiltration, further compromise, or complete control + over affected systems. data_source: - Sysmon EventID 11 -search: '| tstats `security_content_summariesonly` count, min(_time) as firstTime, max(_time) as lastTime, values(Filesystem.file_path) as file_path from datamodel=Endpoint.Filesystem by Filesystem.dest, Filesystem.user, Filesystem.file_name - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `drop_dm_object_name(Filesystem)` - | lookup remote_access_software remote_utility AS file_name OUTPUT isutility, description as signature, comment_reference as desc, category - | search isutility = TRUE - | `detect_remote_access_software_usage_file_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the file path, file name, and the user that created the file. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: Known or approved applications used by the organization or usage of built-in functions. +search: '| tstats `security_content_summariesonly` count, min(_time) as firstTime, + max(_time) as lastTime, values(Filesystem.file_path) as file_path from datamodel=Endpoint.Filesystem + by Filesystem.dest, Filesystem.user, Filesystem.file_name | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `drop_dm_object_name(Filesystem)` | lookup + remote_access_software remote_utility AS file_name OUTPUT isutility, description + as signature, comment_reference as desc, category | search isutility = TRUE | `detect_remote_access_software_usage_file_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the file path, file name, and the user that created + the file. These logs must be processed using the appropriate Splunk Technology Add-ons + that are specific to the EDR product. The logs must also be mapped to the `Filesystem` + node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) + to normalize the field names and speed up the data modeling process. +known_false_positives: Known or approved applications used by the organization or + usage of built-in functions. references: - https://attack.mitre.org/techniques/T1219/ - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/ @@ -29,7 +43,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A file for known a remote access software [$file_name$] was created on $dest$ by $user$. + message: A file for known a remote access software [$file_name$] was created on + $dest$ by $user$. mitre_attack_id: - T1219 observable: @@ -51,7 +66,7 @@ tags: - Splunk Cloud required_fields: - _time - - Filesystem.dest + - Filesystem.dest - Filesystem.user - Filesystem.file_name risk_score: 25 @@ -59,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/detect_remote_access_software_usage_fileinfo.yml b/detections/endpoint/detect_remote_access_software_usage_fileinfo.yml index cb26b7140a..6bda13e076 100644 --- a/detections/endpoint/detect_remote_access_software_usage_fileinfo.yml +++ b/detections/endpoint/detect_remote_access_software_usage_fileinfo.yml @@ -1,20 +1,29 @@ name: Detect Remote Access Software Usage FileInfo id: ccad96d7-a48c-4f13-8b9c-9f6a31cba454 -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-29' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when process with file or code signing attributes from a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description: The following analytic detects the execution of processes with file or + code signing attributes from known remote access software within the environment. + It leverages Sysmon EventCode 1 data and cross-references a lookup table of remote + access utilities such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity + is significant as adversaries often use these tools to maintain unauthorized remote + access. If confirmed malicious, this could allow attackers to persist in the environment, + potentially leading to data exfiltration or further compromise of the network. data_source: - Sysmon EventID 1 -search: '`sysmon` EventCode=1 - | stats count min(_time) as firstTime max(_time) as lastTime, values(Company) as Company values(Product) as Product by dest, user, parent_process_name, process_name, process - | lookup remote_access_software remote_utility_fileinfo AS Product OUTPUT isutility, description as signature, comment_reference as desc, category - | search isutility = True - | `detect_remote_access_software_usage_fileinfo_filter`' -how_to_implement: This analytic relies on Sysmon to be properly installed and utilized in the environment. Ensure that proper logging is setup for Sysmon and data is being ingested into Splunk. -known_false_positives: Known or approved applications used by the organization or usage of built-in functions. +search: '`sysmon` EventCode=1 | stats count min(_time) as firstTime max(_time) as + lastTime, values(Company) as Company values(Product) as Product by dest, user, parent_process_name, + process_name, process | lookup remote_access_software remote_utility_fileinfo AS + Product OUTPUT isutility, description as signature, comment_reference as desc, category + | search isutility = True | `detect_remote_access_software_usage_fileinfo_filter`' +how_to_implement: This analytic relies on Sysmon to be properly installed and utilized + in the environment. Ensure that proper logging is setup for Sysmon and data is being + ingested into Splunk. +known_false_positives: Known or approved applications used by the organization or + usage of built-in functions. references: - https://attack.mitre.org/techniques/T1219/ - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/ @@ -27,7 +36,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A file attributes for known a remote access software [$process_name$] was detected on $dest$ + message: A file attributes for known a remote access software [$process_name$] was + detected on $dest$ mitre_attack_id: - T1219 observable: @@ -52,12 +62,13 @@ tags: - user - parent_process_name - process_name - - process + - process risk_score: 25 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/detect_remote_access_software_usage_process.yml b/detections/endpoint/detect_remote_access_software_usage_process.yml index aaf62a6fdd..af552ade69 100644 --- a/detections/endpoint/detect_remote_access_software_usage_process.yml +++ b/detections/endpoint/detect_remote_access_software_usage_process.yml @@ -1,20 +1,27 @@ name: Detect Remote Access Software Usage Process id: ffd5e001-2e34-48f4-97a2-26dc4bb08178 -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-23' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when a known remote access software is executed within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description: The following analytic detects the execution of known remote access software + within the environment. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and parent processes mapped to the Endpoint data + model. This activity is significant as adversaries often use remote access tools + like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. + If confirmed malicious, this could allow attackers to control systems remotely, + exfiltrate data, or deploy additional malware, posing a severe threat to the organization's + security. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Processes.parent_process) as parent_process from datamodel=Endpoint.Processes where Processes.dest!=unknown Processes.process!=unknown by Processes.dest Processes.user Processes.process_name Processes.process - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `drop_dm_object_name(Processes)` - | lookup remote_access_software remote_utility AS process_name OUTPUT isutility, description as signature, comment_reference as desc, category - | search isutility = True - | `detect_remote_access_software_usage_process_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(Processes.parent_process) as parent_process from datamodel=Endpoint.Processes + where Processes.dest!=unknown Processes.process!=unknown by Processes.dest Processes.user + Processes.process_name Processes.process | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | lookup remote_access_software + remote_utility AS process_name OUTPUT isutility, description as signature, comment_reference + as desc, category | search isutility = True | `detect_remote_access_software_usage_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -39,7 +46,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A process for a known remote access software $process_name$ was identified on $dest$. + message: A process for a known remote access software $process_name$ was identified + on $dest$. mitre_attack_id: - T1219 observable: @@ -61,9 +69,9 @@ tags: - Splunk Cloud required_fields: - _time - - Processes.dest + - Processes.dest - Processes.user - - Processes.process_name + - Processes.process_name - Processes.process - Processes.process_id - Processes.parent_process_name @@ -72,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/detect_renamed_7_zip.yml b/detections/endpoint/detect_renamed_7_zip.yml index c35cd9d2ae..abfe571860 100644 --- a/detections/endpoint/detect_renamed_7_zip.yml +++ b/detections/endpoint/detect_renamed_7_zip.yml @@ -1,16 +1,19 @@ name: Detect Renamed 7-Zip id: 4057291a-b8cf-11eb-95fe-acde48001122 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies renamed 7-Zip usage using Sysmon. At - this stage of an attack, review parallel processes and file modifications for data - that is staged or potentially have been exfiltrated. This analytic utilizes the - OriginalFileName to capture the renamed process. During triage, validate this is - the legitimate version of `7zip` by reviewing the PE metadata. In addition, review - parallel processes for further suspicious behavior. +description: The following analytic detects the usage of a renamed 7-Zip executable + using Sysmon data. It leverages the OriginalFileName field to identify instances + where the 7-Zip process has been renamed. This activity is significant as attackers + often rename legitimate tools to evade detection while staging or exfiltrating data. + If confirmed malicious, this behavior could indicate data exfiltration attempts + or other unauthorized data manipulation, potentially leading to significant data + breaches or loss of sensitive information. Analysts should validate the legitimacy + of the 7-Zip executable and investigate parallel processes for further suspicious + activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_renamed_psexec.yml b/detections/endpoint/detect_renamed_psexec.yml index 41e251c172..5eb632163f 100644 --- a/detections/endpoint/detect_renamed_psexec.yml +++ b/detections/endpoint/detect_renamed_psexec.yml @@ -1,15 +1,17 @@ name: Detect Renamed PSExec id: 683e6196-b8e8-11eb-9a79-acde48001122 -version: 4 -date: '2022-04-07' +version: 5 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies renamed instances of `PsExec.exe` being - utilized on an endpoint. Most instances, it is highly probable to capture `Psexec.exe` - or other SysInternal utility usage with the command-line argument of `-accepteula`. - During triage, validate this is the legitimate version of `PsExec` by reviewing - the PE metadata. In addition, review parallel processes for further suspicious behavior. +description: The following analytic identifies instances where `PsExec.exe` has been + renamed and executed on an endpoint. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process names and original file names. This activity + is significant because renaming `PsExec.exe` is a common tactic to evade detection. + If confirmed malicious, this could allow an attacker to execute commands remotely, + potentially leading to unauthorized access, lateral movement, or further compromise + of the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -92,6 +94,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_renamed_rclone.yml b/detections/endpoint/detect_renamed_rclone.yml index ed2dbff0a5..163caf9566 100644 --- a/detections/endpoint/detect_renamed_rclone.yml +++ b/detections/endpoint/detect_renamed_rclone.yml @@ -1,16 +1,17 @@ name: Detect Renamed RClone id: 6dca1124-b3ec-11eb-9328-acde48001122 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies the usage of `rclone.exe`, renamed, - being used to exfiltrate data to a remote destination. RClone has been used by multiple - ransomware groups to exfiltrate data. In many instances, it will be downloaded from - the legitimate site and executed accordingly. During triage, isolate the endpoint - and begin to review parallel processes for additional behavior. At this stage, the - adversary may have staged data to be exfiltrated. +description: The following analytic detects the execution of a renamed `rclone.exe` + process, which is commonly used for data exfiltration to remote destinations. This + detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on + process names and original file names that do not match. This activity is significant + because ransomware groups often use RClone to exfiltrate sensitive data. If confirmed + malicious, this behavior could indicate an ongoing data exfiltration attempt, potentially + leading to significant data loss and further compromise of the affected systems. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1020/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1020/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_renamed_winrar.yml b/detections/endpoint/detect_renamed_winrar.yml index 0276a70cde..7a62f9c579 100644 --- a/detections/endpoint/detect_renamed_winrar.yml +++ b/detections/endpoint/detect_renamed_winrar.yml @@ -1,15 +1,17 @@ name: Detect Renamed WinRAR id: 1b7bfb2c-b8e6-11eb-99ac-acde48001122 -version: 3 -date: '2021-09-16' +version: 4 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: Hunting -description: The following analtyic identifies renamed instances of `WinRAR.exe`. - In most cases, it is not common for WinRAR to be used renamed, however it is common - to be installed by a third party application and executed from a non-standard path. - During triage, validate additional metadata from the binary that this is `WinRAR`. - Review parallel processes and file modifications. +description: The following analytic identifies instances where `WinRAR.exe` has been + renamed and executed. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and original file names within the Endpoint data + model. This activity is significant because renaming executables is a common tactic + used by attackers to evade detection. If confirmed malicious, this could indicate + an attempt to bypass security controls, potentially leading to unauthorized data + extraction or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -83,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rtlo_in_file_name.yml b/detections/endpoint/detect_rtlo_in_file_name.yml index 7d4f7debdb..0f65d1d91a 100644 --- a/detections/endpoint/detect_rtlo_in_file_name.yml +++ b/detections/endpoint/detect_rtlo_in_file_name.yml @@ -1,32 +1,34 @@ name: Detect RTLO In File Name id: 468b7e11-d362-43b8-b6ec-7a2d3b246678 -version: 2 -date: '2023-04-26' +version: 3 +date: '2024-05-24' author: Steven Dick status: production type: TTP -description: This search is used to detect the abuse of the right-to-left override (RTLO or RLO) - character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or - file name to make it appear benign. The RTLO character is a non-printing Unicode - character that causes the text that follows it to be displayed in reverse. +description: The following analytic identifies the use of the right-to-left override + (RTLO) character in file names. It leverages data from the Endpoint.Filesystem datamodel, + specifically focusing on file creation events and file names containing the RTLO + character (U+202E). This activity is significant because adversaries use RTLO to + disguise malicious files as benign by reversing the text that follows the character. + If confirmed malicious, this technique can deceive users and security tools, leading + to the execution of harmful files and potential system compromise. data_source: - Sysmon EventID 11 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Filesystem.file_create_time) as file_create_time from datamodel=Endpoint.Filesystem where Filesystem.file_name!=unknown by Filesystem.dest Filesystem.user Filesystem.process_id Filesystem.file_name Filesystem.file_path - | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | regex file_name = "\\x{202E}" - | rex field=file_name "(?.+)(?\\x{202E})(?.+)" - | eval file_name_with_RTLO=file_name - | eval file_name=RTLO_file_1.RTLO_file_2 - | fields - RTLO* - | `detect_rtlo_in_file_name_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(Filesystem.file_create_time) as file_create_time from datamodel=Endpoint.Filesystem + where Filesystem.file_name!=unknown by Filesystem.dest Filesystem.user Filesystem.process_id + Filesystem.file_name Filesystem.file_path | `drop_dm_object_name(Filesystem)` | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | regex + file_name = "\\x{202E}" | rex field=file_name "(?.+)(?\\x{202E})(?.+)" + | eval file_name_with_RTLO=file_name | eval file_name=RTLO_file_1.RTLO_file_2 | + fields - RTLO* | `detect_rtlo_in_file_name_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that includes the full command line of the process being launched on your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: Implementation in regions that use right to left in native language. +known_false_positives: Implementation in regions that use right to left in native + language. references: - https://attack.mitre.org/techniques/T1036/002/ - https://resources.infosecinstitute.com/topic/spoof-using-right-to-left-override-rtlo-technique-2/ @@ -36,7 +38,7 @@ tags: - Spearphishing Attachments asset_type: Endpoint confidence: 80 - impact: 50 + impact: 50 message: Suspicious RTLO detected in $file_name$ on endpoint $dest$ by user $user$. mitre_attack_id: - T1036.002 @@ -60,16 +62,17 @@ tags: - Splunk Cloud required_fields: - _time - - Filesystem.dest - - Filesystem.user - - Filesystem.file_name + - Filesystem.dest + - Filesystem.user + - Filesystem.file_name - Filesystem.file_path - - Filesystem.process_id + - Filesystem.process_id risk_score: 40 security_domain: endpoint tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.002/outlook_attachment/rtlo_events.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.002/outlook_attachment/rtlo_events.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rtlo_in_process.yml b/detections/endpoint/detect_rtlo_in_process.yml index 444f8855ca..3d7c3ca93b 100644 --- a/detections/endpoint/detect_rtlo_in_process.yml +++ b/detections/endpoint/detect_rtlo_in_process.yml @@ -1,15 +1,17 @@ name: Detect RTLO In Process id: 22ac27b4-7189-4a4f-9375-b9017c9620d7 -version: 2 -date: '2023-04-26' +version: 3 +date: '2024-05-29' author: Steven Dick status: production type: TTP -description: This search is used to detect the abuse of the right-to-left override - (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to - disguise a string and/or file name to make it appear benign. The RTLO character - is a non-printing Unicode character that causes the text that follows it to be displayed - in reverse. +description: The following analytic identifies the abuse of the right-to-left override + (RTLO) character (U+202E) in process names. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs and command-line data. + This activity is significant because adversaries use the RTLO character to disguise + malicious files or commands, making them appear benign. If confirmed malicious, + this technique can allow attackers to execute harmful code undetected, potentially + leading to unauthorized access, data exfiltration, or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.002/outlook_attachment/rtlo_events.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.002/outlook_attachment/rtlo_events.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rundll32_application_control_bypass___advpack.yml b/detections/endpoint/detect_rundll32_application_control_bypass___advpack.yml index b1ff9bc6e5..12fda2f275 100644 --- a/detections/endpoint/detect_rundll32_application_control_bypass___advpack.yml +++ b/detections/endpoint/detect_rundll32_application_control_bypass___advpack.yml @@ -1,19 +1,18 @@ name: Detect Rundll32 Application Control Bypass - advpack id: 4aefadfe-9abd-4bf8-b3fd-867e9ef95bf8 -version: 2 -date: '2021-02-04' +version: 3 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe loading advpack.dll and - ieadvpack.dll by calling the LaunchINFSection function on the command line. This - particular technique will load script code from a file. Upon a successful execution, - the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During - investigation, identify script content origination. Generally, a child process will - spawn from rundll32.exe, but that may be bypassed based on script code contents. - Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During - investigation, review any network connections and obtain the script content executed. - It's possible other files are on disk. +description: The following analytic detects the execution of rundll32.exe loading + advpack.dll or ieadvpack.dll via the LaunchINFSection function. This method is identified + using Endpoint Detection and Response (EDR) telemetry, focusing on command-line + executions and process details. This activity is significant as it indicates a potential + application control bypass, allowing script code execution from a file. If confirmed + malicious, an attacker could execute arbitrary code, potentially leading to privilege + escalation, persistence, or further network compromise. Investigate script content, + network connections, and any spawned child processes for further context. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rundll32_application_control_bypass___setupapi.yml b/detections/endpoint/detect_rundll32_application_control_bypass___setupapi.yml index df11991ae6..9a81bf670c 100644 --- a/detections/endpoint/detect_rundll32_application_control_bypass___setupapi.yml +++ b/detections/endpoint/detect_rundll32_application_control_bypass___setupapi.yml @@ -1,19 +1,18 @@ name: Detect Rundll32 Application Control Bypass - setupapi id: 61e7b44a-6088-4f26-b788-9a96ba13b37a -version: 2 -date: '2021-02-04' +version: 3 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe loading setupapi.dll and - iesetupapi.dll by calling the LaunchINFSection function on the command line. This - particular technique will load script code from a file. Upon a successful execution, - the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During - investigation, identify script content origination. Generally, a child process will - spawn from rundll32.exe, but that may be bypassed based on script code contents. - Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During - investigation, review any network connections and obtain the script content executed. - It's possible other files are on disk. +description: The following analytic detects the execution of rundll32.exe loading + setupapi.dll and iesetupapi.dll via the LaunchINFSection function. This behavior + is identified using Endpoint Detection and Response (EDR) telemetry, focusing on + process creation events and command-line arguments. This activity is significant + as it indicates a potential application control bypass, allowing an attacker to + execute arbitrary script code. If confirmed malicious, this technique could enable + code execution, privilege escalation, or persistence within the environment, posing + a severe threat to system integrity and security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rundll32_application_control_bypass___syssetup.yml b/detections/endpoint/detect_rundll32_application_control_bypass___syssetup.yml index 9b1aa84401..a0897c5b3b 100644 --- a/detections/endpoint/detect_rundll32_application_control_bypass___syssetup.yml +++ b/detections/endpoint/detect_rundll32_application_control_bypass___syssetup.yml @@ -1,19 +1,18 @@ name: Detect Rundll32 Application Control Bypass - syssetup id: 71b9bf37-cde1-45fb-b899-1b0aa6fa1183 -version: 2 -date: '2021-02-04' +version: 3 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe loading syssetup.dll by - calling the LaunchINFSection function on the command line. This particular technique - will load script code from a file. Upon a successful execution, the following module - loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify - script content origination. Generally, a child process will spawn from rundll32.exe, - but that may be bypassed based on script code contents. Rundll32.exe is natively - found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review - any network connections and obtain the script content executed. It's possible other - files are on disk. +description: The following analytic detects the execution of rundll32.exe loading + syssetup.dll via the LaunchINFSection function. This method is identified through + Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions + and process details. This activity is significant as it indicates a potential application + control bypass, allowing script code execution from a file. If confirmed malicious, + an attacker could execute arbitrary code, potentially leading to privilege escalation, + persistence, or further network compromise. Investigate the script content, network + connections, and any spawned child processes for further context. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_rundll32_inline_hta_execution.yml b/detections/endpoint/detect_rundll32_inline_hta_execution.yml index 43cf85143d..8c8e1260ab 100644 --- a/detections/endpoint/detect_rundll32_inline_hta_execution.yml +++ b/detections/endpoint/detect_rundll32_inline_hta_execution.yml @@ -1,17 +1,17 @@ name: Detect Rundll32 Inline HTA Execution id: 91c79f14-5b41-11eb-ae93-0242ac130002 -version: 2 -date: '2021-01-20' +version: 3 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies "rundll32.exe" execution with inline - protocol handlers. "JavaScript", "VBScript", and "About" are the only supported - options when invoking HTA content directly on the command-line. This type of behavior - is commonly observed with fileless malware or application whitelisting bypass techniques. - The search will return the first time and last time these command-line arguments - were used for these executions, as well as the target system, the user, process - "rundll32.exe" and its parent process. +description: The following analytic detects the execution of "rundll32.exe" with inline + protocol handlers such as "JavaScript", "VBScript", and "About". This behavior is + identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line + arguments. This activity is significant as it is often associated with fileless + malware or application whitelisting bypass techniques. If confirmed malicious, this + could allow an attacker to execute arbitrary code, bypass security controls, and + maintain persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -75,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_sharphound_command_line_arguments.yml b/detections/endpoint/detect_sharphound_command_line_arguments.yml index 6dd874e2ab..008f499514 100644 --- a/detections/endpoint/detect_sharphound_command_line_arguments.yml +++ b/detections/endpoint/detect_sharphound_command_line_arguments.yml @@ -1,16 +1,18 @@ name: Detect SharpHound Command-Line Arguments id: a0bdd2f6-c2ff-11eb-b918-acde48001122 -version: 2 -date: '2024-03-14' +version: 3 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies common command-line arguments used - by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, - function names may be modified, but these changes are dependent upon the operator. - In most instances the defaults are used. This analytic works to identify the common - command-line attributes used. It does not cover the entirety of every argument in - order to avoid false positives. +description: The following analytic detects the execution of SharpHound command-line + arguments, specifically `-collectionMethod` and `invoke-bloodhound`. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant as SharpHound is commonly + used for Active Directory enumeration, which can be a precursor to lateral movement + or privilege escalation. If confirmed malicious, this activity could allow an attacker + to map out the network, identify high-value targets, and plan further attacks, potentially + compromising sensitive information and critical systems. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_sharphound_file_modifications.yml b/detections/endpoint/detect_sharphound_file_modifications.yml index afcee2bcd9..718559e461 100644 --- a/detections/endpoint/detect_sharphound_file_modifications.yml +++ b/detections/endpoint/detect_sharphound_file_modifications.yml @@ -1,32 +1,26 @@ name: Detect SharpHound File Modifications id: 42b4b438-beed-11eb-ba1d-acde48001122 -version: 3 -date: '2024-03-14' +version: 4 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. - SharpHound will query the domain controller and begin gathering all the data related - to the domain and trusts. For output, it will drop a .zip file upon completion following - a typical pattern that is often not changed. This analytic focuses on the default - file name scheme. Note that this may be evaded with different parameters within - SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` - are two examples. In addition, executing SharpHound via .exe or .ps1 without any - command-line arguments will still perform activity and dump output to the default - filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates - multiple temp files following the same pattern `20210601182121_computers.json`, - `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, - or remove these json's entirely if it is too noisy. During traige, review parallel - processes for further suspicious behavior. Typically, the process executing the - `.ps1` ingestor will be PowerShell. +description: The following analytic detects the creation of files typically associated + with SharpHound, a reconnaissance tool used for gathering domain and trust data. + It leverages file modification events from the Endpoint.Filesystem data model, focusing + on default file naming patterns like `*_BloodHound.zip` and various JSON files. + This activity is significant as it indicates potential domain enumeration, which + is a precursor to more targeted attacks. If confirmed malicious, an attacker could + gain detailed insights into the domain structure, facilitating lateral movement + and privilege escalation. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*bloodhound.zip", "*_computers.json", "*_gpos.json", "*_domains.json", "*_users.json", "*_groups.json", "*_ous.json", "*_containers.json") by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name - Filesystem.file_path Filesystem.dest Filesystem.user| `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `detect_sharphound_file_modifications_filter`' + Filesystem.file_path Filesystem.dest Filesystem.user| `drop_dm_object_name(Filesystem)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_sharphound_file_modifications_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` @@ -80,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_sharphound_usage.yml b/detections/endpoint/detect_sharphound_usage.yml index 8c8844e798..86389105f7 100644 --- a/detections/endpoint/detect_sharphound_usage.yml +++ b/detections/endpoint/detect_sharphound_usage.yml @@ -1,18 +1,18 @@ name: Detect SharpHound Usage id: dd04b29a-beed-11eb-87bc-acde48001122 -version: 3 -date: '2024-03-14' +version: 4 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies SharpHound binary usage by using the - original filena,e. In addition to renaming the PE, other coverage is available to - detect command-line arguments. This particular analytic looks for the original_file_name - of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe - have different original filenames. Dependent upon the operator, the code may be - re-compiled and the attributes removed or changed to anything else. During triage, - review the metadata of the binary in question. Review parallel processes for suspicious - behavior. Identify the source of this binary. +description: The following analytic detects the usage of the SharpHound binary by + identifying its original filename, `SharpHound.exe`, and the process name. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process metadata and command-line executions. SharpHound is a tool used for Active + Directory enumeration, often by attackers during the reconnaissance phase. If confirmed + malicious, this activity could allow an attacker to map out the network, identify + high-value targets, and plan further attacks, potentially leading to privilege escalation + and lateral movement within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/sharphound/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_suspicious_processnames_using_pretrained_model_in_dsdl.yml b/detections/endpoint/detect_suspicious_processnames_using_pretrained_model_in_dsdl.yml index f1b3489d41..806d34c814 100644 --- a/detections/endpoint/detect_suspicious_processnames_using_pretrained_model_in_dsdl.yml +++ b/detections/endpoint/detect_suspicious_processnames_using_pretrained_model_in_dsdl.yml @@ -1,25 +1,21 @@ name: Detect suspicious processnames using pretrained model in DSDL id: a15f8977-ad7d-4669-92ef-b59b97219bf5 -version: 1 -date: '2023-01-23' +version: 2 +date: '2024-05-27' author: Abhinav Mishra, Kumar Sharad and Namratha Sreekanta, Splunk type: Anomaly status: experimental data_source: - Sysmon Event Code 1 -description: The following analytic uses a pre-trained Deep Learning model to predict - whether a processname is suspicious or not. Malwares and malicious programs such - as ransomware often use tactics, techniques, and procedures (TTPs) such as copying - malicious files to the local machine to propagate themselves across the network. - A key indicator of compromise is that after a successful execution of the malware, - it copies itself as an executable file with a randomly generated filename and places - this file in one of the directories. Such techniques are seen in several malwares - such as TrickBot. We develop machine learning model that uses a Recurrent Neural - Network (RNN) to distinguish between malicious and benign processnames. The model - is trained independently and is then made available for download. We use a character - level RNN to classify malicious vs. benign processnames. The higher is_malicious_prob, - the more likely is the processname to be suspicious (between [0,1]). The threshold - for flagging a processname as suspicious is set as 0.5. +description: The following analytic identifies suspicious process names using a pre-trained + Deep Learning model. It leverages Endpoint Detection and Response (EDR) telemetry + to analyze process names and predict their likelihood of being malicious. The model, + a character-level Recurrent Neural Network (RNN), classifies process names as benign + or suspicious based on a threshold score of 0.5. This detection is significant as + it helps identify malware, such as TrickBot, which often uses randomly generated + filenames to evade detection. If confirmed malicious, this activity could indicate + the presence of malware capable of propagating across the network and executing + harmful actions. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.process_name Processes.parent_process_name Processes.process Processes.user Processes.dest | `drop_dm_object_name(Processes)` diff --git a/detections/endpoint/detect_use_of_cmd_exe_to_launch_script_interpreters.yml b/detections/endpoint/detect_use_of_cmd_exe_to_launch_script_interpreters.yml index b0d8c4ea33..bc0e873704 100644 --- a/detections/endpoint/detect_use_of_cmd_exe_to_launch_script_interpreters.yml +++ b/detections/endpoint/detect_use_of_cmd_exe_to_launch_script_interpreters.yml @@ -1,22 +1,24 @@ name: Detect Use of cmd exe to Launch Script Interpreters id: b89919ed-fe5f-492c-b139-95dbb162039e -version: 5 -date: '2023-12-07' +version: 6 +date: '2024-05-20' author: Bhavin Patel, Mauricio Velazco, Splunk status: production type: TTP -description: This search looks for the execution of the cscript.exe or wscript.exe - processes, with a parent of cmd.exe. The search will return the count, the first - and last time this execution was seen on a machine, the user, and the destination - of the machine +description: The following analytic detects the execution of cscript.exe or wscript.exe + processes initiated by cmd.exe. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and parent processes within the Endpoint + data model. This activity is significant as it may indicate script-based attacks + or administrative actions that could be leveraged for malicious purposes. If confirmed + malicious, this behavior could allow attackers to execute scripts, potentially leading + to code execution, privilege escalation, or persistence within the environment. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count - min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.parent_process_name="cmd.exe" (Processes.process_name=cscript.exe - OR Processes.process_name =wscript.exe) by Processes.parent_process Processes.process_name Processes.process - Processes.user Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` - | `detect_use_of_cmd_exe_to_launch_script_interpreters_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name="cmd.exe" + (Processes.process_name=cscript.exe OR Processes.process_name =wscript.exe) by Processes.parent_process + Processes.process_name Processes.process Processes.user Processes.dest | `drop_dm_object_name("Processes")` + | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` | `detect_use_of_cmd_exe_to_launch_script_interpreters_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -26,10 +28,13 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: This detection may also be triggered by legitimate applications and numerous service accounts, which often end with a $ sign. To manage this, it's advised to check the service account's activities and, if they are valid, modify the filter macro to exclude them. +known_false_positives: This detection may also be triggered by legitimate applications + and numerous service accounts, which often end with a $ sign. To manage this, it's + advised to check the service account's activities and, if they are valid, modify + the filter macro to exclude them. references: - - https://attack.mitre.org/techniques/T1059/ - - https://redcanary.com/threat-detection-report/techniques/windows-command-shell/ +- https://attack.mitre.org/techniques/T1059/ +- https://redcanary.com/threat-detection-report/techniques/windows-command-shell/ tags: analytic_story: - Emotet Malware DHS Report TA18-201A @@ -64,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.003/cmd_spawns_cscript/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.003/cmd_spawns_cscript/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_webshell_exploit_behavior.yml b/detections/endpoint/detect_webshell_exploit_behavior.yml index 4616cd5914..aa6f4ffd68 100644 --- a/detections/endpoint/detect_webshell_exploit_behavior.yml +++ b/detections/endpoint/detect_webshell_exploit_behavior.yml @@ -1,15 +1,19 @@ name: Detect Webshell Exploit Behavior id: 22597426-6dbd-49bd-bcdc-4ec19857192f -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-20' author: Steven Dick status: production type: TTP -description: This search is used to detect the abuse of web applications by adversaries. - Adversaries may install a backdoor or script onto web servers by exploiting known - vulnerabilities or misconfigruations. Web shells are used to establish persistent - access to systems and provide a set of executable functions or a command-line interface - on the system hosting the Web server. +description: The following analytic identifies the execution of suspicious processes + typically associated with webshell activity on web servers. It detects when processes + like `cmd.exe`, `powershell.exe`, or `bash.exe` are spawned by web server processes + such as `w3wp.exe` or `nginx.exe`. This behavior is significant as it may indicate + an adversary exploiting a web application vulnerability to install a webshell, providing + persistent access and command execution capabilities. If confirmed malicious, this + activity could allow attackers to maintain control over the compromised server, + execute arbitrary commands, and potentially escalate privileges or exfiltrate sensitive + data. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) @@ -91,6 +95,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/generic_webshell_exploit/generic_webshell_exploit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/generic_webshell_exploit/generic_webshell_exploit.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/detect_wmi_event_subscription_persistence.yml b/detections/endpoint/detect_wmi_event_subscription_persistence.yml index 32d5ad5042..ffc30d9f99 100644 --- a/detections/endpoint/detect_wmi_event_subscription_persistence.yml +++ b/detections/endpoint/detect_wmi_event_subscription_persistence.yml @@ -1,35 +1,23 @@ name: Detect WMI Event Subscription Persistence id: 01d9a0c2-cece-11eb-ab46-acde48001122 -version: 1 -date: '2021-06-16' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the use of WMI Event Subscription - to establish persistence or perform privilege escalation. WMI can be used to install - event filters, providers, consumers, and bindings that execute code when a defined - event occurs. WMI subscription execution is proxied by the WMI Provider Host process - (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic - is restricted by commonly added process execution and a path. If the volume is low - enough, remove the values and flag on any new subscriptions. - - All event subscriptions have three components - - 1. Filter - WQL Query for the events we want. EventID equals 19 - - 1. Consumer - An action to take upon triggering the filter. EventID equals 20 - - 1. Binding - Registers a filter to a consumer. EventID equals 21 - - Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. - It may be pertinent to review all 3 to identify the flow of execution. In addition, - EventCode 4104 may assist with any other PowerShell script usage that registered - the subscription.' +description: 'The following analytic identifies the creation of WMI Event Subscriptions, + which can be used to establish persistence or perform privilege escalation. It detects + EventID 19 (EventFilter creation), EventID 20 (EventConsumer creation), and EventID + 21 (FilterToConsumerBinding creation) from Sysmon logs. This activity is significant + because WMI Event Subscriptions can execute code with elevated SYSTEM privileges, + making it a powerful persistence mechanism. If confirmed malicious, an attacker + could maintain long-term access, escalate privileges, and execute arbitrary code, + posing a severe threat to the environment.' data_source: - Sysmon EventID 20 search: '`sysmon` EventID=20 | stats count min(_time) as firstTime max(_time) as lastTime - by Computer User Destination | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `detect_wmi_event_subscription_persistence_filter`' + by Computer User Destination | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `detect_wmi_event_subscription_persistence_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with that provide WMI Event Subscription from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA and have enabled EventID @@ -71,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_amsi_through_registry.yml b/detections/endpoint/disable_amsi_through_registry.yml index 50ddb4106f..ee4ffdd399 100644 --- a/detections/endpoint/disable_amsi_through_registry.yml +++ b/detections/endpoint/disable_amsi_through_registry.yml @@ -1,14 +1,19 @@ name: Disable AMSI Through Registry id: 9c27ec42-d338-11eb-9044-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-29' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: this search is to identify modification in registry to disable AMSI windows - feature to evade detections. This technique was seen in several ransomware, RAT - and even APT to impaire defenses of the compromise machine and to be able to execute - payload with minimal alert as much as possible. +description: The following analytic detects modifications to the Windows registry + that disable the Antimalware Scan Interface (AMSI) by setting the "AmsiEnable" value + to "0x00000000". This detection leverages data from the Endpoint.Registry data model, + specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows + Script\\Settings\\AmsiEnable". Disabling AMSI is significant as it is a common technique + used by ransomware, Remote Access Trojans (RATs), and Advanced Persistent Threats + (APTs) to evade detection and impair defenses. If confirmed malicious, this activity + could allow attackers to execute payloads with minimal alerts, leading to potential + system compromise and data exfiltration. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -62,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_defender_antivirus_registry.yml b/detections/endpoint/disable_defender_antivirus_registry.yml index 3d15b851f0..d84a2d4a21 100644 --- a/detections/endpoint/disable_defender_antivirus_registry.yml +++ b/detections/endpoint/disable_defender_antivirus_registry.yml @@ -1,24 +1,29 @@ name: Disable Defender AntiVirus Registry id: aa4f695a-3024-11ec-9987-acde48001122 -version: 4 -date: '2023-04-11' +version: 5 +date: '2024-05-28' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This particular behavior is typically executed when an adversary or malware - gains access to an endpoint and begins to perform execution and to evade detections. - Usually, a batch (.bat) file will be executed and multiple registry and scheduled - task modifications will occur. During triage, review parallel processes and identify - any further file modifications. Endpoint should be isolated. +description: The following analytic detects the modification of Windows Defender registry + settings to disable antivirus and antispyware protections. It leverages data from + the Endpoint.Registry data model, specifically monitoring changes to registry paths + associated with Windows Defender policies. This activity is significant because + disabling antivirus protections is a common tactic used by adversaries to evade + detection and maintain persistence on compromised systems. If confirmed malicious, + this action could allow attackers to execute further malicious activities undetected, + leading to potential data breaches, system compromise, and further propagation of + malware within the network. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\Policies\\Microsoft\\Windows Defender*" Registry.registry_value_name IN ("DisableAntiSpyware","DisableAntiVirus") Registry.registry_value_data = 0x00000001) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `disable_defender_antivirus_registry_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path = "*\\Policies\\Microsoft\\Windows Defender*" Registry.registry_value_name + IN ("DisableAntiSpyware","DisableAntiVirus") Registry.registry_value_data = 0x00000001) + BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.process_guid Registry.user Registry.dest | + `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `disable_defender_antivirus_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -63,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_defender_blockatfirstseen_feature.yml b/detections/endpoint/disable_defender_blockatfirstseen_feature.yml index 8d5f0a2a4d..349cb889c8 100644 --- a/detections/endpoint/disable_defender_blockatfirstseen_feature.yml +++ b/detections/endpoint/disable_defender_blockatfirstseen_feature.yml @@ -1,17 +1,21 @@ name: Disable Defender BlockAtFirstSeen Feature id: 2dd719ac-3021-11ec-97b4-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-22' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: This analytic is intended to detect a suspicious modification of the - Windows registry to disable a Windows Defender feature. This technique is intended - to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen - feature where it blocks suspicious files the first time seen on the host. +description: The following analytic detects the modification of the Windows registry + to disable the Windows Defender BlockAtFirstSeen feature. It leverages data from + the Endpoint.Registry data model, specifically monitoring changes to the registry + path associated with Windows Defender SpyNet and the DisableBlockAtFirstSeen value. + This activity is significant because disabling this feature can allow malicious + files to bypass initial detection by Windows Defender, increasing the risk of malware + infection. If confirmed malicious, this action could enable attackers to execute + malicious code undetected, leading to potential system compromise and data breaches. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\Microsoft\\Windows Defender\\SpyNet*" Registry.registry_value_name = DisableBlockAtFirstSeen Registry.registry_value_data = 0x00000001) BY _time span=1h @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_defender_enhanced_notification.yml b/detections/endpoint/disable_defender_enhanced_notification.yml index 1b08acb6b9..697be6ac02 100644 --- a/detections/endpoint/disable_defender_enhanced_notification.yml +++ b/detections/endpoint/disable_defender_enhanced_notification.yml @@ -1,14 +1,19 @@ name: Disable Defender Enhanced Notification id: dc65678c-301f-11ec-8e30-acde48001122 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-24' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is intended to detect a suspicious modification of registry - to disable windows defender features. This technique attempts to bypass or evade - detection from Windows Defender AV, specifically the Enhanced Notification feature - where a user or admin would receive alerts. +description: The following analytic detects the modification of the registry to disable + Windows Defender's Enhanced Notification feature. It leverages data from Endpoint + Detection and Response (EDR) agents, specifically monitoring changes to the registry + path associated with Windows Defender reporting. This activity is significant because + disabling Enhanced Notifications can prevent users and administrators from receiving + critical security alerts, potentially allowing malicious activities to go unnoticed. + If confirmed malicious, this action could enable an attacker to bypass detection + mechanisms, maintain persistence, and escalate their activities without triggering + alerts. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -25,7 +30,7 @@ search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime | fields firstTime lastTime dest user parent_process_name parent_process process_name process_path process registry_key_name registry_path registry_value_name registry_value_data process_guid | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `disable_defender_antivirus_registry_filter`' + | `security_content_ctime(lastTime)` | `disable_defender_enhanced_notification_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -86,6 +91,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_defender_mpengine_registry.yml b/detections/endpoint/disable_defender_mpengine_registry.yml index 51084eb689..4f3093af81 100644 --- a/detections/endpoint/disable_defender_mpengine_registry.yml +++ b/detections/endpoint/disable_defender_mpengine_registry.yml @@ -1,24 +1,28 @@ name: Disable Defender MpEngine Registry id: cc391750-3024-11ec-955a-acde48001122 -version: 4 -date: '2023-04-11' +version: 5 +date: '2024-05-21' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This particular behavior is typically executed when an adversary or malware - gains access to an endpoint and begins to perform execution and to evade detections. - Usually, a batch (.bat) file will be executed and multiple registry and scheduled - task modifications will occur. During triage, review parallel processes and identify - any further file modifications. Endpoint should be isolated. +description: The following analytic detects the modification of the Windows Defender + MpEngine registry value, specifically setting MpEnablePus to 0x00000000. This detection + leverages endpoint registry logs, focusing on changes within the path "*\\Policies\\Microsoft\\Windows + Defender\\MpEngine*". This activity is significant as it indicates an attempt to + disable key Windows Defender features, potentially allowing malware to evade detection. + If confirmed malicious, this could lead to undetected malware execution, persistence, + and further system compromise. Immediate investigation and endpoint isolation are + recommended. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*" Registry.registry_value_name = MpEnablePus Registry.registry_value_data = 0x00000000) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `disable_defender_mpengine_registry_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path = "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*" + Registry.registry_value_name = MpEnablePus Registry.registry_value_data = 0x00000000) + BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.process_guid Registry.user Registry.dest | + `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `disable_defender_mpengine_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -63,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_defender_submit_samples_consent_feature.yml b/detections/endpoint/disable_defender_submit_samples_consent_feature.yml index d4addee595..d1114bc616 100644 --- a/detections/endpoint/disable_defender_submit_samples_consent_feature.yml +++ b/detections/endpoint/disable_defender_submit_samples_consent_feature.yml @@ -1,14 +1,18 @@ name: Disable Defender Submit Samples Consent Feature id: 73922ff8-3022-11ec-bf5e-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-14' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is intended to detect a suspicious modification of the - Windows registry to disable a Windows Defender feature. This technique is intended - to bypass or evade detection from Windows Defender AV, specifically the feature - that submits samples for further analysis. +description: The following analytic detects the modification of the Windows registry + to disable the Windows Defender Submit Samples Consent feature. It leverages data + from the Endpoint.Registry data model, specifically monitoring changes to the registry + path associated with Windows Defender SpyNet and the SubmitSamplesConsent value + set to 0x00000000. This activity is significant as it indicates an attempt to bypass + or evade detection by preventing Windows Defender from submitting samples for further + analysis. If confirmed malicious, this could allow an attacker to execute malicious + code without being detected by Windows Defender, leading to potential system compromise. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_etw_through_registry.yml b/detections/endpoint/disable_etw_through_registry.yml index 7244646f34..dc8513536c 100644 --- a/detections/endpoint/disable_etw_through_registry.yml +++ b/detections/endpoint/disable_etw_through_registry.yml @@ -1,14 +1,18 @@ name: Disable ETW Through Registry id: f0eacfa4-d33f-11eb-8f9d-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-24' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to identify modification in registry to disable ETW windows - feature to evade detections. This technique was seen in several ransomware, RAT - and even APT to impaire defenses of the compromise machine and to be able to execute - payload with minimal alert as much as possible. +description: The following analytic detects modifications to the registry that disable + the Event Tracing for Windows (ETW) feature. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\.NETFramework\\ETWEnabled" + with a value set to "0x00000000". This activity is significant because disabling + ETW can allow attackers to evade detection mechanisms, making it harder for security + tools to monitor malicious activities. If confirmed malicious, this could enable + attackers to execute payloads with minimal alerts, impairing defenses and potentially + leading to further compromise of the system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -60,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_registry_tool.yml b/detections/endpoint/disable_registry_tool.yml index 5b720983c2..728f09b798 100644 --- a/detections/endpoint/disable_registry_tool.yml +++ b/detections/endpoint/disable_registry_tool.yml @@ -1,22 +1,26 @@ name: Disable Registry Tool id: cd2cf33c-9201-11eb-a10a-acde48001122 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-14' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search identifies modification of registry to disable the regedit - or registry tools of the windows operating system. Since registry tool is a swiss - knife in analyzing registry, malware such as RAT or trojan Spy disable this application - to prevent the removal of their registry entry such as persistence, file less components - and defense evasion. +description: The following analytic detects modifications to the Windows registry + aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" + with a value of "0x00000001". This activity is significant because malware, such + as RATs or trojans, often disable registry tools to prevent the removal of their + entries, aiding in persistence and defense evasion. If confirmed malicious, this + could hinder incident response efforts and allow the attacker to maintain control + over the compromised system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.user Registry.dest Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.user Registry.dest + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_registry_tool_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_schedule_task.yml b/detections/endpoint/disable_schedule_task.yml index 5e03e78d2e..a486a8376b 100644 --- a/detections/endpoint/disable_schedule_task.yml +++ b/detections/endpoint/disable_schedule_task.yml @@ -1,16 +1,18 @@ name: Disable Schedule Task id: db596056-3019-11ec-a9ff-acde48001122 -version: 1 -date: '2021-10-18' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious commandline to disable existing - schedule task. This technique is used by adversaries or commodity malware like IcedID - to disable security application (AV products) in the targetted host to evade detections. - This TTP is a good pivot to check further why and what other process run before - and after this detection. check which process execute the commandline and what task - is disabled. parent child process is quite valuable in this scenario too. +description: The following analytic detects the execution of a command to disable + an existing scheduled task using 'schtasks.exe' with the '/change' and '/disable' + parameters. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line arguments. Disabling scheduled + tasks is significant as it is a common tactic used by adversaries, including malware + like IcedID, to disable security applications and evade detection. If confirmed + malicious, this activity could allow attackers to persist undetected, disable critical + security defenses, and further compromise the targeted host. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime @@ -63,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_schtask/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_schtask/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_security_logs_using_minint_registry.yml b/detections/endpoint/disable_security_logs_using_minint_registry.yml index 509ba3f4eb..c7ef979383 100644 --- a/detections/endpoint/disable_security_logs_using_minint_registry.yml +++ b/detections/endpoint/disable_security_logs_using_minint_registry.yml @@ -1,14 +1,18 @@ name: Disable Security Logs Using MiniNt Registry id: 39ebdc68-25b9-11ec-aec7-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-29' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious registry modification to disable - security audit logs. This technique was shared by a researcher to disable Security - logs of windows by adding this registry. The Windows will think it is WinPE and - will not log any event to the Security Log +description: The following analytic detects a suspicious registry modification aimed + at disabling security audit logs by adding a specific registry entry. It leverages + data from the Endpoint.Registry data model, focusing on changes to the "Control\\MiniNt" + registry path. This activity is significant because it can prevent Windows from + logging any events to the Security Log, effectively blinding security monitoring + efforts. If confirmed malicious, this technique could allow an attacker to operate + undetected, making it difficult to trace their actions and compromising the integrity + of security audits. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -62,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/minint_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/minint_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_show_hidden_files.yml b/detections/endpoint/disable_show_hidden_files.yml index ac410fbf3a..11aa7dfb24 100644 --- a/detections/endpoint/disable_show_hidden_files.yml +++ b/detections/endpoint/disable_show_hidden_files.yml @@ -1,22 +1,28 @@ name: Disable Show Hidden Files id: 6f3ccfa2-91fe-11eb-8f9b-acde48001122 -version: 5 -date: '2024-02-14' +version: 6 +date: '2024-05-27' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows registry - to prevent users from seeing all the files with hidden attributes. This event or - techniques are known on some worm and trojan spy malware that will drop hidden files - on the infected machine. +description: The following analytic detects modifications to the Windows registry + that disable the display of hidden files. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to registry paths associated with hidden + file settings. This activity is significant because malware, such as worms and trojan + spyware, often use hidden files to evade detection. If confirmed malicious, this + behavior could allow an attacker to conceal malicious files on the system, making + it harder for security tools and analysts to identify and remove the threat. data_source: - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\Hidden" OR (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\HideFileExt" Registry.registry_value_data = "0x00000001") OR (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\ShowSuperHidden" Registry.registry_value_data = "0x00000000" )) BY _time span=1h Registry.user Registry.dest Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `disable_show_hidden_files_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\Hidden" + OR (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\HideFileExt" + Registry.registry_value_data = "0x00000001") OR (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\ShowSuperHidden" + Registry.registry_value_data = "0x00000000" )) BY _time span=1h Registry.user Registry.dest + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_show_hidden_files_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -61,12 +67,15 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-system.log source: WinEventLog:System sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_uac_remote_restriction.yml b/detections/endpoint/disable_uac_remote_restriction.yml index ce59d73360..8473e91fcd 100644 --- a/detections/endpoint/disable_uac_remote_restriction.yml +++ b/detections/endpoint/disable_uac_remote_restriction.yml @@ -1,15 +1,18 @@ name: Disable UAC Remote Restriction id: 9928b732-210e-11ec-b65e-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-24' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious modification of registry to disable - UAC remote restriction. This technique was well documented in Microsoft page where - attacker may modify this registry value to bypassed UAC feature of windows host. - This is a good indicator that some tries to bypassed UAC to suspicious process or - gain privilege escalation. +description: The following analytic detects the modification of the registry to disable + UAC remote restriction by setting the "LocalAccountTokenFilterPolicy" value to "0x00000001". + It leverages data from the Endpoint.Registry data model, specifically monitoring + changes to the registry path "*\\CurrentVersion\\Policies\\System*". This activity + is significant because disabling UAC remote restriction can allow an attacker to + bypass User Account Control (UAC) protections, potentially leading to privilege + escalation. If confirmed malicious, this could enable an attacker to execute unauthorized + actions with elevated privileges, compromising the security of the affected system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/LocalAccountTokenFilterPolicy/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/LocalAccountTokenFilterPolicy/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_windows_app_hotkeys.yml b/detections/endpoint/disable_windows_app_hotkeys.yml index 3372280e3d..1550c2f7dd 100644 --- a/detections/endpoint/disable_windows_app_hotkeys.yml +++ b/detections/endpoint/disable_windows_app_hotkeys.yml @@ -1,24 +1,26 @@ name: Disable Windows App Hotkeys id: 1490f224-ad8b-11eb-8c4f-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-11' author: Steven Dick, Teoderick Contreras, Splunkk status: production type: TTP -description: The following analytic detects a suspicious registry modification to disable Windows - hotkey (shortcut keys) for native Windows applications. This technique is commonly - used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. - This technique is used to impair the analyst in analyzing and removing the attacker - implant in compromised systems. +description: The following analytic detects a suspicious registry modification aimed + at disabling Windows hotkeys for native applications. It leverages data from the + Endpoint.Registry data model, focusing on specific registry paths and values indicative + of this behavior. This activity is significant as it can impair an analyst's ability + to use essential tools like Task Manager and Command Prompt, hindering incident + response efforts. If confirmed malicious, this technique can allow an attacker to + maintain persistence and evade detection, complicating the remediation process. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*\\Windows NT\\CurrentVersion\\Image File Execution Options\\*" AND Registry.registry_value_data= "HotKey Disabled" AND Registry.registry_value_name - = "Debugger") BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name - Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + = "Debugger") BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_windows_app_hotkeys_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -61,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/hotkey_disabled_hidden_user/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/hotkey_disabled_hidden_user/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disable_windows_smartscreen_protection.yml b/detections/endpoint/disable_windows_smartscreen_protection.yml index d7db650147..e56a8075bd 100644 --- a/detections/endpoint/disable_windows_smartscreen_protection.yml +++ b/detections/endpoint/disable_windows_smartscreen_protection.yml @@ -1,26 +1,29 @@ name: Disable Windows SmartScreen Protection id: 664f0fd0-91ff-11eb-a56f-acde48001122 -version: 5 -date: '2024-02-14' +version: 6 +date: '2024-05-26' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: The following search identifies a modification of registry to disable - the smartscreen protection of windows machine. This is windows feature provide an - early warning system against website that might engage in phishing attack or malware - distribution. This modification are seen in RAT malware to cover their tracks upon - downloading other of its component or other payload. +description: The following analytic detects modifications to the Windows registry + that disable SmartScreen protection. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to registry paths associated with SmartScreen + settings. This activity is significant because SmartScreen provides an early warning + system against phishing and malware. Disabling it can indicate malicious intent, + often seen in Remote Access Trojans (RATs) to evade detection while downloading + additional payloads. If confirmed malicious, this action could allow attackers to + bypass security measures, increasing the risk of successful phishing attacks and + malware infections. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE Registry.registry_path IN ("*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\SmartScreenEnabled", "*\\Microsoft\\Windows\\System\\EnableSmartScreen") - Registry.registry_value_data IN ("Off", "0") - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `disable_windows_smartscreen_protection_filter`' + WHERE Registry.registry_path IN ("*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\SmartScreenEnabled", + "*\\Microsoft\\Windows\\System\\EnableSmartScreen") Registry.registry_value_data IN + ("Off", "0") BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `disable_windows_smartscreen_protection_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml b/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml index f749d913ae..fc69094941 100644 --- a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml +++ b/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml @@ -1,18 +1,18 @@ name: Disabled Kerberos Pre-Authentication Discovery With Get-ADUser id: 114c6bfe-9406-11ec-bcce-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-ADUser` commandlet with specific parameters. - `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows - Active Directory networks. As the name suggests, `Get-ADUser` is used to query for - domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover - domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries - alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack - their passwords offline. +description: The following analytic detects the execution of the `Get-ADUser` PowerShell + cmdlet with parameters indicating a search for domain accounts with Kerberos Pre-Authentication + disabled. It leverages PowerShell Script Block Logging (EventCode=4104) to identify + this specific activity. This behavior is significant because discovering accounts + with Kerberos Pre-Authentication disabled can allow adversaries to perform offline + password cracking. If confirmed malicious, this activity could lead to unauthorized + access to user accounts, potentially compromising sensitive information and escalating + privileges within the network. data_source: - Powershell Script Block Logging 4104 search: ' `powershell` EventCode=4104 (ScriptBlockText = "*Get-ADUser*" AND ScriptBlockText="*4194304*") @@ -60,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/getaduser/get-aduser-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/getaduser/get-aduser-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_powerview.yml b/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_powerview.yml index e566d382e0..ffc44e5bce 100644 --- a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_powerview.yml +++ b/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_powerview.yml @@ -1,24 +1,24 @@ name: Disabled Kerberos Pre-Authentication Discovery With PowerView id: b0b34e2c-90de-11ec-baeb-acde48001122 -version: 2 -date: '2022-05-03' +version: 3 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainUser` commandlet with specific parameters. - `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration - on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is - used to identify domain users and combining it with `-PreauthNotRequired` allows - adversaries to discover domain accounts with Kerberos Pre Authentication disabled. - - Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts - and attempt to crack their passwords offline. +description: The following analytic detects the execution of the `Get-DomainUser` + commandlet with the `-PreauthNotRequired` parameter using PowerShell Script Block + Logging (EventCode=4104). This command is part of PowerView, a tool used for enumerating + Windows Active Directory networks. Identifying domain accounts with Kerberos Pre-Authentication + disabled is significant because adversaries can leverage this information to attempt + offline password cracking. If confirmed malicious, this activity could lead to unauthorized + access to domain accounts, potentially compromising sensitive information and escalating + privileges within the network. data_source: - Powershell Script Block Logging 4104 search: ' `powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainUser*" AND ScriptBlockText="*PreauthNotRequired*") | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer - UserID EventCode ScriptBlockText | rename Computer as dest | `security_content_ctime(firstTime)` | `disabled_kerberos_pre_authentication_discovery_with_powerview_filter`' + UserID EventCode ScriptBlockText | rename Computer as dest | `security_content_ctime(firstTime)` + | `disabled_kerberos_pre_authentication_discovery_with_powerview_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -58,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getdomainuser.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getdomainuser.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_cmd_application.yml b/detections/endpoint/disabling_cmd_application.yml index 37162d7d44..b230da25d7 100644 --- a/detections/endpoint/disabling_cmd_application.yml +++ b/detections/endpoint/disabling_cmd_application.yml @@ -1,21 +1,25 @@ name: Disabling CMD Application id: ff86077c-9212-11eb-a1e6-acde48001122 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-16' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to identify modification in registry to disable cmd prompt - application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging - or deleting there samples through cmd application which is one of the tool of analyst - to traverse on directory and files. +description: The following analytic detects modifications to the registry that disable + the CMD prompt application. It leverages data from the Endpoint.Registry data model, + specifically looking for changes to the "DisableCMD" registry value. This activity + is significant because disabling CMD can hinder an analyst's ability to investigate + and remediate threats, a tactic often used by malware such as RATs, Trojans, or + Worms. If confirmed malicious, this could prevent security teams from using CMD + for directory and file traversal, complicating incident response and allowing the + attacker to maintain persistence. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\DisableCMD" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_cmd_application_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_defender_services.yml b/detections/endpoint/disabling_defender_services.yml index 5ffed2d1f3..7b116079f4 100644 --- a/detections/endpoint/disabling_defender_services.yml +++ b/detections/endpoint/disabling_defender_services.yml @@ -1,15 +1,18 @@ name: Disabling Defender Services id: 911eacdc-317f-11ec-ad30-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-19' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This particular behavior is typically executed when an adversaries or - malware gains access to an endpoint and beings to perform execution and to evade - detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled - task modifications will occur. During triage, review parallel processes and identify - any further file modifications. Endpoint should be isolated. +description: The following analytic detects the disabling of Windows Defender services + by monitoring registry modifications. It leverages registry event data to identify + changes to specific registry paths associated with Defender services, where the + 'Start' value is set to '0x00000004'. This activity is significant because disabling + Defender services can indicate an attempt by an adversary to evade detection and + maintain persistence on the endpoint. If confirmed malicious, this action could + allow attackers to execute further malicious activities undetected, leading to potential + data breaches or system compromise. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -17,9 +20,9 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint WHERE (Registry.registry_path = "*\\System\\CurrentControlSet\\Services\\*" AND (Registry.registry_path IN("*WdBoot*", "*WdFilter*", "*WdNisDrv*", "*WdNisSvc*","*WinDefend*", "*SecurityHealthService*")) AND Registry.registry_value_name = Start Registry.registry_value_data - = 0x00000004) BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name - Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data) + = 0x00000004) BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_defender_services_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_folderoptions_windows_feature.yml b/detections/endpoint/disabling_folderoptions_windows_feature.yml index b9c7f6cf5a..f02279df0b 100644 --- a/detections/endpoint/disabling_folderoptions_windows_feature.yml +++ b/detections/endpoint/disabling_folderoptions_windows_feature.yml @@ -1,15 +1,19 @@ name: Disabling FolderOptions Windows Feature id: 83776de4-921a-11eb-868a-acde48001122 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-11' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to identify registry modification to disable folder options - feature of windows to show hidden files, file extension and etc. This technique - used by malware in combination if disabling show hidden files feature to hide their - files and also to hide the file extension to lure the user base on file icons or - fake file extensions. +description: The following analytic detects the modification of the Windows registry + to disable the Folder Options feature, which prevents users from showing hidden + files and file extensions. It leverages data from the Endpoint.Registry data model, + specifically monitoring changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions" + with a value of "0x00000001". This activity is significant as it is commonly used + by malware to conceal malicious files and deceive users with fake file extensions. + If confirmed malicious, this could allow an attacker to hide their presence and + malicious files, making detection and remediation more difficult. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_norun_windows_app.yml b/detections/endpoint/disabling_norun_windows_app.yml index 2d9943c116..921201e39f 100644 --- a/detections/endpoint/disabling_norun_windows_app.yml +++ b/detections/endpoint/disabling_norun_windows_app.yml @@ -1,22 +1,24 @@ name: Disabling NoRun Windows App id: de81bc46-9213-11eb-adc9-acde48001122 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-13' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to identify modification of registry to disable run application - in window start menu. this application is known to be a helpful shortcut to windows - OS user to run known application and also to execute some reg or batch script. This - technique is used malware to make cleaning of its infection more harder by preventing - known application run easily through run shortcut. +description: The following analytic detects the modification of the Windows registry + to disable the Run application in the Start menu. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" + with a value of "0x00000001". This activity is significant because the Run application + is a useful shortcut for executing known applications and scripts. If confirmed + malicious, this action could hinder system cleaning efforts and make it more difficult + to run essential tools, thereby aiding malware persistence. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_norun_windows_app_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_systemrestore_in_registry.yml b/detections/endpoint/disabling_systemrestore_in_registry.yml index 7ede895e84..432a5d661b 100644 --- a/detections/endpoint/disabling_systemrestore_in_registry.yml +++ b/detections/endpoint/disabling_systemrestore_in_registry.yml @@ -1,14 +1,18 @@ name: Disabling SystemRestore In Registry id: f4f837e2-91fb-11eb-8bf6-acde48001122 -version: 5 -date: '2024-02-14' +version: 6 +date: '2024-05-22' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: The following search identifies the modification of registry related - in disabling the system restore of a machine. This event or behavior are seen in - some RAT malware to make the restore of the infected machine difficult and keep - their infection on the box. +description: The following analytic detects the modification of registry keys to disable + System Restore on a machine. It leverages data from the Endpoint.Registry data model, + specifically monitoring changes to registry paths associated with System Restore + settings. This activity is significant because disabling System Restore can hinder + recovery efforts and is a tactic often used by Remote Access Trojans (RATs) to maintain + persistence on an infected system. If confirmed malicious, this action could prevent + system recovery, allowing the attacker to sustain their foothold and potentially + cause further damage or data loss. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -17,8 +21,8 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint OR Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SystemRestore\\DisableConfig" OR Registry.registry_path= "*\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\SystemRestore\\DisableSR" OR Registry.registry_path= "*\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\SystemRestore\\DisableConfig" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_systemrestore_in_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -66,15 +70,19 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-system.log source: WinEventLog:System sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/disabling_task_manager.yml b/detections/endpoint/disabling_task_manager.yml index d151a34763..a6493c253f 100644 --- a/detections/endpoint/disabling_task_manager.yml +++ b/detections/endpoint/disabling_task_manager.yml @@ -1,21 +1,25 @@ name: Disabling Task Manager id: dac279bc-9202-11eb-b7fb-acde48001122 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-15' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to identifies modification of registry to disable the - task manager of windows operating system. this event or technique are commonly seen - in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate - their process. +description: The following analytic identifies modifications to the Windows registry + that disable Task Manager. It leverages data from the Endpoint.Registry data model, + specifically looking for changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" + with a value of "0x00000001". This activity is significant as it is commonly associated + with malware such as RATs, Trojans, and worms, which disable Task Manager to prevent + users from terminating malicious processes. If confirmed malicious, this could allow + attackers to maintain persistence and control over the infected system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_task_manager_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -63,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/win_app_defender_disabling/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/dllhost_with_no_command_line_arguments_with_network.yml b/detections/endpoint/dllhost_with_no_command_line_arguments_with_network.yml index f243c25516..6b96a1dd98 100644 --- a/detections/endpoint/dllhost_with_no_command_line_arguments_with_network.yml +++ b/detections/endpoint/dllhost_with_no_command_line_arguments_with_network.yml @@ -1,16 +1,18 @@ name: DLLHost with no Command Line Arguments with Network id: f1c07594-a141-11eb-8407-acde48001122 -version: 4 -date: '2023-07-10' +version: 5 +date: '2024-05-26' author: Steven Dick, Michael Haag, Splunk status: experimental type: TTP -description: The following analytic identifies DLLHost.exe with no command line arguments - with a network connection. It is unusual for DLLHost.exe to execute with no command - line arguments present. This particular behavior is common with malicious software, - including Cobalt Strike. During investigation, triage any network connections and - parallel processes. Identify any suspicious module loads related to credential dumping - or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects instances of DLLHost.exe running without + command line arguments while establishing a network connection. This behavior is + identified using Endpoint Detection and Response (EDR) telemetry, focusing on process + execution and network activity data. It is significant because DLLHost.exe typically + runs with specific arguments, and its absence can indicate malicious activity, such + as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers + to execute code, move laterally, or exfiltrate data, posing a severe threat to the + network's security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -83,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon_dllhost.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon_dllhost.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/dns_exfiltration_using_nslookup_app.yml b/detections/endpoint/dns_exfiltration_using_nslookup_app.yml index 996aef2d47..8fa692ce80 100644 --- a/detections/endpoint/dns_exfiltration_using_nslookup_app.yml +++ b/detections/endpoint/dns_exfiltration_using_nslookup_app.yml @@ -1,16 +1,18 @@ name: DNS Exfiltration Using Nslookup App id: 2452e632-9e0d-11eb-bacd-acde48001122 -version: 1 -date: '2021-04-15' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: TTP -description: this search is to detect potential DNS exfiltration using nslookup application. - This technique are seen in couple of malware and APT group to exfiltrated collected - data in a infected machine or infected network. This detection is looking for unique - use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are - commonly used by attacker and also the retry parameter which is designed to query - C2 DNS multiple tries. +description: The following analytic identifies potential DNS exfiltration using the + nslookup application. It detects specific command-line parameters such as query + type (TXT, A, AAAA) and retry options, which are commonly used by attackers to exfiltrate + data. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing + on process execution logs. This activity is significant as it may indicate an attempt + to communicate with a Command and Control (C2) server or exfiltrate sensitive data. + If confirmed malicious, this could lead to data breaches and unauthorized access + to critical information. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -18,9 +20,9 @@ search: '| tstats `security_content_summariesonly` values(Processes.process) as count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = "nslookup.exe" Processes.process = "*-querytype=*" OR Processes.process="*-qt=*" OR Processes.process="*-q=*" OR Processes.process="-type=*" - OR Processes.process="*-retry=*" by Processes.dest Processes.user Processes.process_name Processes.process Processes.parent_process_name | - `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `dns_exfiltration_using_nslookup_app_filter`' + OR Processes.process="*-retry=*" by Processes.dest Processes.user Processes.process_name + Processes.process Processes.parent_process_name | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `dns_exfiltration_using_nslookup_app_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -87,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/nslookup_exfil/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/nslookup_exfil/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_account_discovery_with_dsquery.yml b/detections/endpoint/domain_account_discovery_with_dsquery.yml index 5d73a10016..77893e8ccf 100644 --- a/detections/endpoint/domain_account_discovery_with_dsquery.yml +++ b/detections/endpoint/domain_account_discovery_with_dsquery.yml @@ -1,14 +1,18 @@ name: Domain Account Discovery with Dsquery id: b1a8ce04-04c2-11ec-bea7-acde48001122 -version: 1 -date: '2021-08-24' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `dsquery.exe` with command-line - arguments utilized to discover domain users. The `user` argument returns a list - of all users registered in the domain. Red Teams and adversaries alike engage in - remote system discovery for situational awareness and Active Directory Discovery. +description: The following analytic identifies the execution of `dsquery.exe` with + command-line arguments used to discover domain users. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as it indicates potential reconnaissance + efforts by adversaries to map out domain users, which is a common precursor to further + attacks. If confirmed malicious, this behavior could allow attackers to gain insights + into user accounts, facilitating subsequent actions like privilege escalation or + lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_account_discovery_with_net_app.yml b/detections/endpoint/domain_account_discovery_with_net_app.yml index eee2ac9b93..3fa0097ee5 100644 --- a/detections/endpoint/domain_account_discovery_with_net_app.yml +++ b/detections/endpoint/domain_account_discovery_with_net_app.yml @@ -1,14 +1,17 @@ name: Domain Account Discovery With Net App id: 98f6a534-04c2-11ec-96b2-acde48001122 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `net.exe` or `net1.exe` with - command-line arguments utilized to query for domain users. Red Teams and adversaries - alike may use net.exe to enumerate domain users for situational awareness and Active - Directory Discovery. +description: The following analytic detects the execution of `net.exe` or `net1.exe` + with command-line arguments used to query domain users. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as it may indicate an attempt by adversaries + to enumerate domain users for situational awareness and Active Directory discovery. + If confirmed malicious, this behavior could allow attackers to map out user accounts, + potentially leading to further exploitation or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_controller_discovery_with_nltest.yml b/detections/endpoint/domain_controller_discovery_with_nltest.yml index 82c3b1367d..d93ad4be9e 100644 --- a/detections/endpoint/domain_controller_discovery_with_nltest.yml +++ b/detections/endpoint/domain_controller_discovery_with_nltest.yml @@ -1,15 +1,17 @@ name: Domain Controller Discovery with Nltest id: 41243735-89a7-4c83-bcdd-570aa78f00a1 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `nltest.exe` with command-line - arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', - can be used to return a list of all domain controllers. Red Teams and adversaries - alike may use nltest.exe to identify domain controllers in a Windows Domain for - situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `nltest.exe` with command-line + arguments `/dclist:` or `/dsgetdc:` to discover domain controllers. It leverages + Endpoint Detection and Response (EDR) data, focusing on process names and command-line + arguments. This activity is significant because both Red Teams and adversaries use + `nltest.exe` for situational awareness and Active Directory discovery. If confirmed + malicious, this behavior could allow attackers to map out domain controllers, facilitating + further attacks such as privilege escalation or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_controller_discovery_with_wmic.yml b/detections/endpoint/domain_controller_discovery_with_wmic.yml index 4ee268234a..9fad87c1ad 100644 --- a/detections/endpoint/domain_controller_discovery_with_wmic.yml +++ b/detections/endpoint/domain_controller_discovery_with_wmic.yml @@ -1,15 +1,18 @@ name: Domain Controller Discovery with Wmic id: 64c7adaa-48ee-483c-b0d6-7175bc65e6cc -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `wmic.exe` with command-line - arguments utilized to discover remote systems. The arguments utilized in this command - line return a list of all domain controllers in a Windows domain. Red Teams and - adversaries alike use *.exe to identify remote systems for situational awareness - and Active Directory Discovery. +description: The following analytic identifies the execution of `wmic.exe` with command-line + arguments used to discover domain controllers in a Windows domain. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line arguments. This activity is significant because it is commonly + used by adversaries and Red Teams for situational awareness and Active Directory + discovery. If confirmed malicious, this behavior could allow attackers to map out + the network, identify key systems, and plan further attacks, potentially leading + to unauthorized access and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_group_discovery_with_adsisearcher.yml b/detections/endpoint/domain_group_discovery_with_adsisearcher.yml index 1b3925c424..9627870eb9 100644 --- a/detections/endpoint/domain_group_discovery_with_adsisearcher.yml +++ b/detections/endpoint/domain_group_discovery_with_adsisearcher.yml @@ -1,19 +1,24 @@ name: Domain Group Discovery with Adsisearcher id: 089c862f-5f83-49b5-b1c8-7e4ff66560c7 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the `[Adsisearcher]` type accelerator being used to query Active Directory - for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate - domain groups for situational awareness and Active Directory Discovery. +description: The following analytic detects the use of the `[Adsisearcher]` type accelerator + in PowerShell to query Active Directory for domain groups. It leverages PowerShell + Script Block Logging (EventCode=4104) to identify specific script blocks containing + `[adsisearcher]` and group-related queries. This activity is significant as it may + indicate an attempt by adversaries or Red Teams to enumerate domain groups for situational + awareness and Active Directory discovery. If confirmed malicious, this behavior + could lead to further reconnaissance, privilege escalation, or lateral movement + within the network. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` (ScriptBlockText = "*[adsisearcher]*" AND ScriptBlockText = "*(objectcategory=group)*" - AND ScriptBlockText = "*findAll()*") | stats count min(_time) as firstTime max(_time) as - lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` +search: '`powershell` (ScriptBlockText = "*[adsisearcher]*" AND ScriptBlockText = + "*(objectcategory=group)*" AND ScriptBlockText = "*findAll()*") | stats count min(_time) + as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID + | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` | `domain_group_discovery_with_adsisearcher_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here @@ -44,14 +49,15 @@ tags: required_fields: - _time - EventCode - - Message - - ComputerName - - User + - ScriptBlockText + - Computer + - UserID risk_score: 18 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/domain_group_discovery_with_adsisearcher/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/domain_group_discovery_with_adsisearcher/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/domain_group_discovery_with_dsquery.yml b/detections/endpoint/domain_group_discovery_with_dsquery.yml index 9b869e342c..f30afa419a 100644 --- a/detections/endpoint/domain_group_discovery_with_dsquery.yml +++ b/detections/endpoint/domain_group_discovery_with_dsquery.yml @@ -1,14 +1,18 @@ name: Domain Group Discovery With Dsquery id: f0c9d62f-a232-4edd-b17e-bc409fb133d4 -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `dsquery.exe` with command-line - arguments utilized to query for domain groups. The argument `group`, returns a list - of all domain groups. Red Teams and adversaries alike use may leverage dsquery.exe - to enumerate domain groups for situational awareness and Active Directory Discovery. +description: The following analytic identifies the execution of `dsquery.exe` with + command-line arguments used to query for domain groups. It leverages Endpoint Detection + and Response (EDR) data, focusing on process names and command-line arguments. This + activity is significant because both Red Teams and adversaries use `dsquery.exe` + to enumerate domain groups, gaining situational awareness and facilitating further + Active Directory discovery. If confirmed malicious, this behavior could allow attackers + to map out the domain structure, identify high-value targets, and plan subsequent + attacks, potentially leading to privilege escalation or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_group_discovery_with_net.yml b/detections/endpoint/domain_group_discovery_with_net.yml index 03f5ca9c7c..4707b6fecc 100644 --- a/detections/endpoint/domain_group_discovery_with_net.yml +++ b/detections/endpoint/domain_group_discovery_with_net.yml @@ -1,14 +1,18 @@ name: Domain Group Discovery With Net id: f2f14ac7-fa81-471a-80d5-7eb65c3c7349 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `net.exe` with command-line - arguments utilized to query for domain groups. The argument `group /domain`, returns - a list of all domain groups. Red Teams and adversaries alike use net.exe to enumerate - domain groups for situational awareness and Active Directory Discovery. +description: The following analytic identifies the execution of `net.exe` with command-line + arguments used to query domain groups, specifically `group /domain`. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line arguments. This activity is significant as it indicates potential + reconnaissance efforts by adversaries to enumerate domain groups, which is a common + step in Active Directory Discovery. If confirmed malicious, this behavior could + allow attackers to gain insights into the domain structure, aiding in further attacks + such as privilege escalation or lateral movement. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/domain_group_discovery_with_wmic.yml b/detections/endpoint/domain_group_discovery_with_wmic.yml index 3ee3016a51..5ee7680ba9 100644 --- a/detections/endpoint/domain_group_discovery_with_wmic.yml +++ b/detections/endpoint/domain_group_discovery_with_wmic.yml @@ -1,14 +1,18 @@ name: Domain Group Discovery With Wmic id: a87736a6-95cd-4728-8689-3c64d5026b3e -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `wmic.exe` with command-line - arguments utilized to query for domain groups. The arguments utilized in this command - return a list of all domain groups. Red Teams and adversaries alike use wmic.exe - to enumerate domain groups for situational awareness and Active Directory Discovery. +description: The following analytic identifies the execution of `wmic.exe` with command-line + arguments used to query for domain groups. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line executions. + This activity is significant as it indicates potential reconnaissance efforts by + adversaries to gain situational awareness and map out Active Directory structures. + If confirmed malicious, this behavior could allow attackers to identify and target + specific domain groups, potentially leading to privilege escalation or lateral movement + within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/download_files_using_telegram.yml b/detections/endpoint/download_files_using_telegram.yml index a3877fb104..b8ebf9ba8b 100644 --- a/detections/endpoint/download_files_using_telegram.yml +++ b/detections/endpoint/download_files_using_telegram.yml @@ -1,20 +1,22 @@ name: Download Files Using Telegram id: 58194e28-ae5e-11eb-8912-acde48001122 -version: 1 -date: '2021-05-06' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic will identify a suspicious download by the Telegram - application on a Windows system. This behavior was identified on a honeypot where - the adversary gained access, installed Telegram and followed through with downloading - different network scanners (port, bruteforcer, masscan) to the system and later - used to mapped the whole network and further move laterally. +description: The following analytic detects suspicious file downloads by the Telegram + application on a Windows system. It leverages Sysmon EventCode 15 to identify instances + where Telegram.exe creates files with a Zone.Identifier, indicating a download. + This activity is significant as it may indicate an adversary using Telegram to download + malicious tools, such as network scanners, for further exploitation. If confirmed + malicious, this behavior could lead to network mapping, lateral movement, and potential + compromise of additional systems within the network. data_source: - Sysmon EventID 15 search: '`sysmon` EventCode= 15 process_name = "telegram.exe" TargetFilename = "*:Zone.Identifier" - |stats count min(_time) as firstTime max(_time) as lastTime by dest EventCode - process_name process_id TargetFilename Hash | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + |stats count min(_time) as firstTime max(_time) as lastTime by dest EventCode process_name + process_id TargetFilename Hash | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `download_files_using_telegram_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and TargetFilename from your endpoints or Events that @@ -58,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/minergate/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/minergate/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/drop_icedid_license_dat.yml b/detections/endpoint/drop_icedid_license_dat.yml index c3314fda54..67eed26a0a 100644 --- a/detections/endpoint/drop_icedid_license_dat.yml +++ b/detections/endpoint/drop_icedid_license_dat.yml @@ -1,13 +1,18 @@ name: Drop IcedID License dat id: b7a045fc-f14a-11eb-8e79-acde48001122 -version: 1 -date: '2021-07-30' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This search is to detect dropping a suspicious file named as "license.dat" - in %appdata%. This behavior seen in latest IcedID malware that contain the actual - core bot that will be injected in other process to do banking stealing. +description: The following analytic detects the dropping of a suspicious file named + "license.dat" in %appdata% or %programdata%. This behavior is associated with the + IcedID malware, which uses this file to inject its core bot into other processes + for banking credential theft. The detection leverages Sysmon EventCode 11 to monitor + file creation events in these directories. This activity is significant as it indicates + a potential malware infection aiming to steal sensitive banking information. If + confirmed malicious, the attacker could gain unauthorized access to financial data, + leading to significant financial loss and data breaches. data_source: - Sysmon EventID 1 search: '`sysmon` EventCode= 11 TargetFilename = "*\\license.dat" AND (TargetFilename="*\\appdata\\*" @@ -51,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/dsquery_domain_discovery.yml b/detections/endpoint/dsquery_domain_discovery.yml index c8cc2386d4..89ab1635e5 100644 --- a/detections/endpoint/dsquery_domain_discovery.yml +++ b/detections/endpoint/dsquery_domain_discovery.yml @@ -1,39 +1,26 @@ name: DSQuery Domain Discovery id: cc316032-924a-11eb-91a2-acde48001122 -version: 1 -date: '2021-03-31' +version: 2 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies "dsquery.exe" execution with arguments - looking for `TrustedDomain` query directly on the command-line. This is typically - indicative of an Administrator or adversary perform domain trust discovery. Note - that this query does not identify any other variations of "Dsquery.exe" usage. - - Within this detection, it is assumed `dsquery.exe` is not moved or renamed. - - The search will return the first time and last time these command-line arguments - were used for these executions, as well as the target system, the user, process - "dsquery.exe" and its parent process. - - DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` - and only on Server operating system. - - The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found - loaded by another process, it is possible dsquery is running within that process - context in memory. - - In addition to trust discovery, review parallel processes for additional behaviors - performed. Identify the parent process and capture any files (batch files, for example) - being used.' +description: 'The following analytic detects the execution of "dsquery.exe" with arguments + targeting `TrustedDomain` queries directly from the command line. This behavior + is identified using Endpoint Detection and Response (EDR) telemetry, focusing on + process names and command-line arguments. This activity is significant as it often + indicates domain trust discovery, a common step in lateral movement or privilege + escalation by adversaries. If confirmed malicious, this could allow attackers to + map domain trusts, potentially leading to further exploitation and unauthorized + access to trusted domains.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=dsquery.exe - Processes.process=*trustedDomain* by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `dsquery_domain_discovery_filter`' + Processes.process=*trustedDomain* by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `dsquery_domain_discovery_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -96,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/dump_lsass_via_comsvcs_dll.yml b/detections/endpoint/dump_lsass_via_comsvcs_dll.yml index f766fc2cd9..99767ac7bb 100644 --- a/detections/endpoint/dump_lsass_via_comsvcs_dll.yml +++ b/detections/endpoint/dump_lsass_via_comsvcs_dll.yml @@ -1,12 +1,12 @@ name: Dump LSASS via comsvcs DLL id: 8943b567-f14d-4ee8-a0bb-2121d4ce3184 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-25' author: Patrick Bareiss, Splunk status: production type: TTP description: |- - The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source. + The following analytic detects the behavior of dumping credentials from memory by exploiting the Local Security Authority Subsystem Service (LSASS) using the comsvcs.dll and MiniDump via rundll32. This detection leverages process information from Endpoint Detection and Response (EDR) logs, focusing on specific command-line executions. This activity is significant because it indicates potential credential theft, which can lead to broader system compromise, persistence, lateral movement, and privilege escalation. If confirmed malicious, attackers could gain unauthorized access to sensitive information, leading to data theft, ransomware attacks, or other damaging outcomes. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/dump_lsass_via_procdump.yml b/detections/endpoint/dump_lsass_via_procdump.yml index e1736481ad..f01ad02d9d 100644 --- a/detections/endpoint/dump_lsass_via_procdump.yml +++ b/detections/endpoint/dump_lsass_via_procdump.yml @@ -1,27 +1,26 @@ name: Dump LSASS via procdump id: 3742ebfe-64c2-11eb-ae93-0242ac130002 -version: 3 -date: '2022-08-31' +version: 4 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: 'Detect procdump.exe dumping the lsass process. This query looks for - both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump - file with all process memory. Both are highly suspect and should be reviewed. This - query does not monitor for the internal name (original_file_name=procdump) of the - PE or look for procdump64.exe. Modify the query as needed. - - During triage, confirm this is procdump.exe executing. If it is the first time a - Sysinternals utility has been ran, it is possible there will be a -accepteula on - the command line. Review other endpoint data sources for cross process (injection) - into lsass.exe.' +description: 'The following analytic detects the use of procdump.exe to dump the LSASS + process, specifically looking for the -mm and -ma command-line arguments. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names, + command-line executions, and parent processes. This activity is significant because + dumping LSASS can expose sensitive credentials, posing a severe security risk. If + confirmed malicious, an attacker could obtain credentials, escalate privileges, + and move laterally within the network, leading to potential data breaches and further + compromise of the environment.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_procdump` (Processes.process=*-ma* - OR Processes.process=*-mm*) Processes.process=*lsass* by Processes.user Processes.parent_process_name Processes.process_name - Processes.process Processes.original_file_name Processes.dest | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `dump_lsass_via_procdump_filter`' + OR Processes.process=*-mm*) Processes.process=*lsass* by Processes.user Processes.parent_process_name + Processes.process_name Processes.process Processes.original_file_name Processes.dest + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `dump_lsass_via_procdump_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -85,11 +84,13 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/crowdstrike_falcon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/crowdstrike_falcon.log source: crowdstrike sourcetype: crowdstrike:events:sensor diff --git a/detections/endpoint/elevated_group_discovery_with_net.yml b/detections/endpoint/elevated_group_discovery_with_net.yml index 9ad1b4a8d6..87c932dc05 100644 --- a/detections/endpoint/elevated_group_discovery_with_net.yml +++ b/detections/endpoint/elevated_group_discovery_with_net.yml @@ -1,15 +1,18 @@ name: Elevated Group Discovery With Net id: a23a0e20-0b1b-4a07-82e5-ec5f70811e7a -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `net.exe` or `net1.exe` with - command-line arguments utilized to query for specific elevated domain groups. Red - Teams and adversaries alike use net.exe to enumerate elevated domain groups for - situational awareness and Active Directory Discovery to identify high privileged - users. +description: The following analytic detects the execution of `net.exe` or `net1.exe` + with command-line arguments used to query elevated domain groups. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + command-line executions. This activity is significant as it indicates potential + reconnaissance efforts by adversaries to identify high-privileged users within Active + Directory. If confirmed malicious, this behavior could lead to further attacks aimed + at compromising privileged accounts, escalating privileges, or gaining unauthorized + access to sensitive systems and data. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/elevated_group_discovery_with_powerview.yml b/detections/endpoint/elevated_group_discovery_with_powerview.yml index 39ba6e09ce..8d4663dd5b 100644 --- a/detections/endpoint/elevated_group_discovery_with_powerview.yml +++ b/detections/endpoint/elevated_group_discovery_with_powerview.yml @@ -1,23 +1,24 @@ name: Elevated Group Discovery with PowerView id: 10d62950-0de5-4199-a710-cff9ea79b413 -version: 2 -date: '2024-02-14' +version: 3 +date: '2024-06-10' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainGroupMember` commandlet. `Get-DomainGroupMember` - is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. - As the name suggests, `Get-DomainGroupMember` is used to list the members of an - specific domain group. Red Teams and adversaries alike use PowerView to enumerate - elevated domain groups for situational awareness and Active Directory Discovery - to identify high privileged users. +description: The following analytic detects the execution of the `Get-DomainGroupMember` + cmdlet from PowerView, identified through PowerShell Script Block Logging (EventCode=4104). + This cmdlet is used to enumerate members of elevated domain groups such as Domain + Admins and Enterprise Admins. Monitoring this activity is crucial as it indicates + potential reconnaissance efforts by adversaries to identify high-privileged users + within the domain. If confirmed malicious, this activity could lead to targeted + attacks on privileged accounts, facilitating further compromise and lateral movement + within the network. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 (Message = "*Get-DomainGroupMember*") AND Message +search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainGroupMember*") AND ScriptBlockText IN ("*Domain Admins*","*Enterprise Admins*", "*Schema Admins*", "*Account Operators*" , "*Server Operators*", "*Protected Users*", "*Dns Admins*") | stats count min(_time) - as firstTime max(_time) as lastTime by EventCode Message ComputerName User | rename ComputerName as dest, User as user | `security_content_ctime(firstTime)` + as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` | `elevated_group_discovery_with_powerview_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here @@ -50,17 +51,17 @@ tags: required_fields: - _time - EventCode - - Message - - ComputerName - - User + - ScriptBlockText + - Computer + - UserID risk_score: 21 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-powershell.log - source: WinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: wineventlog + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-powershell-xml-powerview.log + source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: xmlwineventlog - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/elevated_group_discovery_with_wmic.yml b/detections/endpoint/elevated_group_discovery_with_wmic.yml index 97946a582a..a55c1d2588 100644 --- a/detections/endpoint/elevated_group_discovery_with_wmic.yml +++ b/detections/endpoint/elevated_group_discovery_with_wmic.yml @@ -1,14 +1,18 @@ name: Elevated Group Discovery With Wmic id: 3f6bbf22-093e-4cb4-9641-83f47b8444b6 -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `wmic.exe` with command-line - arguments utilized to query for specific domain groups. Red Teams and adversaries - alike use net.exe to enumerate elevated domain groups for situational awareness - and Active Directory Discovery to identify high privileged users. +description: The following analytic detects the execution of `wmic.exe` with command-line + arguments querying specific elevated domain groups. It leverages Endpoint Detection + and Response (EDR) telemetry to identify processes that access the LDAP namespace + and search for groups like "Domain Admins" or "Enterprise Admins." This activity + is significant as it indicates potential reconnaissance efforts by adversaries to + identify high-privilege accounts within Active Directory. If confirmed malicious, + this behavior could lead to privilege escalation, allowing attackers to gain elevated + access and control over critical network resources. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/enable_rdp_in_other_port_number.yml b/detections/endpoint/enable_rdp_in_other_port_number.yml index 41d879b622..ba5dc70525 100644 --- a/detections/endpoint/enable_rdp_in_other_port_number.yml +++ b/detections/endpoint/enable_rdp_in_other_port_number.yml @@ -1,22 +1,27 @@ name: Enable RDP In Other Port Number id: 99495452-b899-11eb-96dc-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-29' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a modification to registry to enable rdp to - a machine with different port number. This technique was seen in some atttacker - tries to do lateral movement and remote access to a compromised machine to gain - control of it. +description: The following analytic detects modifications to the registry that enable + RDP on a machine using a non-default port number. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path "HKLM\SYSTEM\CurrentControlSet\Control\Terminal + Server\WinStations\RDP-Tcp" and the "PortNumber" value. This activity is significant + as attackers often modify RDP settings to facilitate lateral movement and maintain + remote access to compromised systems. If confirmed malicious, this could allow attackers + to bypass network defenses, gain persistent access, and potentially control the + compromised machine. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*HKLM\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp*" Registry.registry_value_name = "PortNumber") BY _time - span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `enable_rdp_in_other_port_number_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/enable_wdigest_uselogoncredential_registry.yml b/detections/endpoint/enable_wdigest_uselogoncredential_registry.yml index 0428eef571..0243c5f583 100644 --- a/detections/endpoint/enable_wdigest_uselogoncredential_registry.yml +++ b/detections/endpoint/enable_wdigest_uselogoncredential_registry.yml @@ -1,24 +1,28 @@ name: Enable WDigest UseLogonCredential Registry id: 0c7d8ffe-25b1-11ec-9f39-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-12' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious registry modification to enable - plain text credential feature of windows. This technique was used by several malware - and also by mimikatz to be able to dumpe the a plain text credential to the compromised - or target host. This TTP is really a good indicator that someone wants to dump the - crendential of the host so it must be a good pivot for credential dumping techniques. +description: The following analytic detects a suspicious registry modification that + enables the plain text credential feature in Windows by setting the "UseLogonCredential" + value to 1 in the WDigest registry path. This detection leverages data from the + Endpoint.Registry data model, focusing on specific registry paths and values. This + activity is significant because it is commonly used by malware and tools like Mimikatz + to dump plain text credentials, indicating a potential credential dumping attempt. + If confirmed malicious, this could allow an attacker to obtain sensitive credentials, + leading to further compromise and lateral movement within the network. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*\\System\\CurrentControlSet\\Control\\SecurityProviders\\WDigest\\*" - Registry.registry_value_name = "UseLogonCredential" Registry.registry_value_data=0x00000001) BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name = "UseLogonCredential" Registry.registry_value_data=0x00000001) + BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `enable_wdigest_uselogoncredential_registry_filter`' + | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `enable_wdigest_uselogoncredential_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/atomic_red_team/wdigest_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/atomic_red_team/wdigest_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/enumerate_users_local_group_using_telegram.yml b/detections/endpoint/enumerate_users_local_group_using_telegram.yml index e08bdfe4e6..ae1cf9dc5c 100644 --- a/detections/endpoint/enumerate_users_local_group_using_telegram.yml +++ b/detections/endpoint/enumerate_users_local_group_using_telegram.yml @@ -1,20 +1,24 @@ name: Enumerate Users Local Group Using Telegram id: fcd74532-ae54-11eb-a5ab-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will detect a suspicious Telegram process enumerating all - network users in a local group. This technique was seen in a Monero infected honeypot - to mapped all the users on the compromised system. EventCode 4798 is generated when - a process enumerates a user's security-enabled local groups on a computer or device. +description: The following analytic detects a Telegram process enumerating all network + users in a local group. It leverages EventCode 4798, which is generated when a process + enumerates a user's security-enabled local groups on a computer or device. This + activity is significant as it may indicate an attempt to gather information on user + accounts, a common precursor to further malicious actions. If confirmed malicious, + this behavior could allow an attacker to map out user accounts, potentially leading + to privilege escalation or lateral movement within the network. data_source: - Windows Event Log Security 4798 -search: '`wineventlog_security` EventCode=4798 CallerProcessName = "*\\telegram.exe" | - stats count min(_time) as firstTime max(_time) as lastTime by user Computer EventCode - CallerProcessName ProcessID SubjectUserSid SubjectDomainName SubjectLogonId - | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `enumerate_users_local_group_using_telegram_filter`' +search: '`wineventlog_security` EventCode=4798 CallerProcessName = "*\\telegram.exe" + | stats count min(_time) as firstTime max(_time) as lastTime by user Computer EventCode + CallerProcessName ProcessID SubjectUserSid SubjectDomainName SubjectLogonId | + rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `enumerate_users_local_group_using_telegram_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Task Schedule (Exa. Security Log EventCode 4798) endpoints. Tune and filter known instances of process like logonUI used in your environment. @@ -28,7 +32,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 80 - message: The Telegram application has been identified enumerating local groups on $dest$ by $user$. + message: The Telegram application has been identified enumerating local groups on + $dest$ by $user$. mitre_attack_id: - T1087 observable: @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/enumerate_users_local_group_using_telegram/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/enumerate_users_local_group_using_telegram/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/esentutl_sam_copy.yml b/detections/endpoint/esentutl_sam_copy.yml index ea811d2170..4153e98ff3 100644 --- a/detections/endpoint/esentutl_sam_copy.yml +++ b/detections/endpoint/esentutl_sam_copy.yml @@ -1,14 +1,18 @@ name: Esentutl SAM Copy id: d372f928-ce4f-11eb-a762-acde48001122 -version: 1 -date: '2021-08-18' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies the process - `esentutl.exe` - being - used to capture credentials stored in ntds.dit or the SAM file on disk. During triage, - review parallel processes and determine if legitimate activity. Upon determination - of illegitimate activity, take further action to isolate and contain the threat. +description: The following analytic detects the use of `esentutl.exe` to access credentials + stored in the ntds.dit or SAM file. This detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process execution logs that include + command-line details. This activity is significant because it may indicate an attempt + to extract sensitive credential information, which is a common tactic in lateral + movement and privilege escalation. If confirmed malicious, this could allow an attacker + to gain unauthorized access to user credentials, potentially compromising the entire + network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/eventvwr_uac_bypass.yml b/detections/endpoint/eventvwr_uac_bypass.yml index c4be842dda..76f5b40457 100644 --- a/detections/endpoint/eventvwr_uac_bypass.yml +++ b/detections/endpoint/eventvwr_uac_bypass.yml @@ -1,16 +1,18 @@ name: Eventvwr UAC Bypass id: 9cf8fe08-7ad8-11eb-9819-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-26' author: Steven Dick, Michael Haag, Splunk status: production type: TTP -description: The following search identifies Eventvwr bypass by identifying the registry - modification into a specific path that eventvwr.msc looks to (but is not valid) - upon execution. A successful attack will include a suspicious command to be executed - upon eventvwr.msc loading. Upon triage, review the parallel processes that have - executed. Identify any additional registry modifications on the endpoint that may - look suspicious. Remediate as necessary. +description: The following analytic detects an Eventvwr UAC bypass by identifying + suspicious registry modifications in the path that Eventvwr.msc references upon + execution. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on registry changes and process execution details. This activity + is significant because it indicates a potential privilege escalation attempt, allowing + an attacker to execute arbitrary commands with elevated privileges. If confirmed + malicious, this could lead to unauthorized code execution, persistence, and further + compromise of the affected system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) @@ -88,6 +90,7 @@ tags: 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 + - 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 diff --git a/detections/endpoint/excel_spawning_powershell.yml b/detections/endpoint/excel_spawning_powershell.yml index a6ba0c2846..a0b87e1141 100644 --- a/detections/endpoint/excel_spawning_powershell.yml +++ b/detections/endpoint/excel_spawning_powershell.yml @@ -1,24 +1,25 @@ name: Excel Spawning PowerShell id: 42d40a22-9be3-11eb-8f08-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies Microsoft Excel spawning PowerShell. - Typically, this is not common behavior and not default with Excel.exe. Excel.exe - will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` - (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing - attachment and is actively used. Albeit, the command executed will most likely be - encoded and captured via another detection. During triage, review parallel processes - and identify any files that may have been written. +description: The following analytic detects Microsoft Excel spawning PowerShell, an + uncommon and suspicious behavior. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where the parent + process is "excel.exe" and the child process is PowerShell. This activity is significant + because it is often associated with spearphishing attacks, where malicious attachments + execute encoded PowerShell commands. If confirmed malicious, this behavior could + allow an attacker to execute arbitrary code, potentially leading to data exfiltration, + privilege escalation, or persistent access within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.parent_process_name="excel.exe" `process_powershell` by Processes.parent_process Processes.parent_process_name - Processes.process_name Processes.user Processes.dest Processes.original_file_name - | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` + where Processes.parent_process_name="excel.exe" `process_powershell` by Processes.parent_process + Processes.parent_process_name Processes.process_name Processes.user Processes.dest + Processes.original_file_name | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` | `excel_spawning_powershell_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -83,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excel_spawning_windows_script_host.yml b/detections/endpoint/excel_spawning_windows_script_host.yml index 4425070655..b0a85217a8 100644 --- a/detections/endpoint/excel_spawning_windows_script_host.yml +++ b/detections/endpoint/excel_spawning_windows_script_host.yml @@ -1,27 +1,25 @@ name: Excel Spawning Windows Script Host id: 57fe880a-9be3-11eb-9bf3-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies Microsoft Excel spawning Windows Script - Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and - not default with Excel.exe. Excel.exe will generally be found in the following path - `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` - or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. - `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing - attachment and is actively used. Albeit, the command-line executed will most likely - be obfuscated and captured via another detection. During triage, review parallel - processes and identify any files that may have been written. Review the reputation - of the remote destination and block accordingly. +description: The following analytic identifies instances where Microsoft Excel spawns + Windows Script Host processes (`cscript.exe` or `wscript.exe`). This behavior is + detected using Endpoint Detection and Response (EDR) telemetry, focusing on process + creation events where the parent process is `excel.exe`. This activity is significant + because it is uncommon and often associated with malicious actions, such as spearphishing + attacks. If confirmed malicious, this could allow an attacker to execute scripts, + potentially leading to code execution, data exfiltration, or further system compromise. + Immediate investigation and mitigation are recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name="excel.exe" Processes.process_name IN ("cscript.exe", - "wscript.exe") by Processes.parent_process Processes.parent_process_name Processes.process_name Processes.user - Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` + "wscript.exe") by Processes.parent_process Processes.parent_process_name Processes.process_name + Processes.user Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` | `excel_spawning_windows_script_host_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -83,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_distinct_processes_from_windows_temp.yml b/detections/endpoint/excessive_distinct_processes_from_windows_temp.yml index 465e383a5c..317b1d34b7 100644 --- a/detections/endpoint/excessive_distinct_processes_from_windows_temp.yml +++ b/detections/endpoint/excessive_distinct_processes_from_windows_temp.yml @@ -1,15 +1,18 @@ name: Excessive distinct processes from Windows Temp id: 23587b6a-c479-11eb-b671-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-29' author: Michael Hart, Mauricio Velazco, Splunk status: production type: Anomaly -description: This analytic will identify suspicious series of process executions. We - have observed that post exploit framework tools like Koadic and Meterpreter will - launch an excessive number of processes with distinct file paths from Windows\Temp - to execute actions on objective. This behavior is extremely anomalous compared - to typical application behaviors that use Windows\Temp. +description: The following analytic identifies an excessive number of distinct processes + executing from the Windows\Temp directory. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process paths and counts within a 20-minute + window. This behavior is significant as it often indicates the presence of post-exploit + frameworks like Koadic and Meterpreter, which use this technique to execute malicious + actions. If confirmed malicious, this activity could allow attackers to execute + arbitrary code, escalate privileges, and maintain persistence within the environment, + posing a severe threat to system integrity and security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/excessive_distinct_processes_from_windows_temp/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/excessive_distinct_processes_from_windows_temp/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/excessive_file_deletion_in_windefender_folder.yml b/detections/endpoint/excessive_file_deletion_in_windefender_folder.yml index e9ea26d810..14c3da5d5b 100644 --- a/detections/endpoint/excessive_file_deletion_in_windefender_folder.yml +++ b/detections/endpoint/excessive_file_deletion_in_windefender_folder.yml @@ -1,28 +1,30 @@ name: Excessive File Deletion In WinDefender Folder id: b5baa09a-7a05-11ec-8da4-acde48001122 -version: 2 -date: '2024-03-05' +version: 3 +date: '2024-05-12' author: Teoderick Contreras, Splunk, Steven Dick status: production type: TTP -description: This analytic identifies excessive file deletion events in the Windows - Defender folder. This technique was observed in the WhisperGate malware campaign, - where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges - and then executed PowerShell commands to delete files within the Windows Defender - application folder. Such behavior is a strong indicator that the offending process - is attempting to corrupt a Windows Defender installation. +description: The following analytic detects excessive file deletion events in the + Windows Defender folder. It leverages Sysmon EventCodes 23 and 26 to identify processes + deleting multiple files within this directory. This behavior is significant as it + may indicate an attempt to corrupt or disable Windows Defender, a key security component. + If confirmed malicious, this activity could allow an attacker to disable endpoint + protection, facilitating further malicious actions without detection. data_source: - Sysmon EventID 23 - Sysmon EventID 26 -search: '`sysmon` EventCode IN ("23","26") TargetFilename = "*\\ProgramData\\Microsoft\\Windows Defender\\*" - | stats count, values(TargetFilename) as deleted_files, min(_time) as firstTime, max(_time) as lastTime by user, dest, signature, signature_id, Image, process_name, process_guid - | rename Image as process - | where count >=50 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `excessive_file_deletion_in_windefender_folder_filter`' -how_to_implement: To successfully implement this search, you must ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are utilizing Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. -known_false_positives: Windows Defender AV updates may trigger this alert. Please adjust the filter macros to mitigate false positives. +search: '`sysmon` EventCode IN ("23","26") TargetFilename = "*\\ProgramData\\Microsoft\\Windows + Defender\\*" | stats count, values(TargetFilename) as deleted_files, min(_time) + as firstTime, max(_time) as lastTime by user, dest, signature, signature_id, Image, + process_name, process_guid | rename Image as process | where count >=50 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `excessive_file_deletion_in_windefender_folder_filter`' +how_to_implement: To successfully implement this search, you must ingest logs that + include the process name, TargetFilename, and ProcessID executions from your endpoints. + If you are utilizing Sysmon, ensure you have at least version 2.0 of the Sysmon + TA installed. +known_false_positives: Windows Defender AV updates may trigger this alert. Please + adjust the filter macros to mitigate false positives. references: - https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/ tags: @@ -57,7 +59,7 @@ tags: required_fields: - _time - TargetFilename - - user + - user - dest - signature - signature_id @@ -70,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/excessive_file_del_in_windefender_dir/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/excessive_file_del_in_windefender_dir/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_number_of_service_control_start_as_disabled.yml b/detections/endpoint/excessive_number_of_service_control_start_as_disabled.yml index 3f54e8af8e..08d62164b5 100644 --- a/detections/endpoint/excessive_number_of_service_control_start_as_disabled.yml +++ b/detections/endpoint/excessive_number_of_service_control_start_as_disabled.yml @@ -1,16 +1,18 @@ name: Excessive number of service control start as disabled id: 77592bec-d5cc-11eb-9e60-acde48001122 -version: 1 -date: '2021-06-25' +version: 2 +date: '2024-05-19' author: Michael Hart, Splunk status: production type: Anomaly -description: This detection targets behaviors observed when threat actors have used - sc.exe to modify services. We observed malware in a honey pot spawning numerous - sc.exe processes in a short period of time, presumably to impair defenses, possibly - to block others from compromising the same machine. This detection will alert when - we see both an excessive number of sc.exe processes launched with specific commandline - arguments to disable the start of certain services. +description: The following analytic detects an excessive number of `sc.exe` processes + launched with the command line argument `start= disabled` within a short period. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process names, command-line executions, and process GUIDs. This activity is significant + as it may indicate an attempt to disable critical services, potentially impairing + system defenses. If confirmed malicious, this behavior could allow an attacker to + disrupt security mechanisms, hinder incident response, and maintain control over + the compromised system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` distinct_count(Processes.process) @@ -74,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/sc_service_start_disabled/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/sc_service_start_disabled/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/excessive_number_of_taskhost_processes.yml b/detections/endpoint/excessive_number_of_taskhost_processes.yml index fd0391b24d..f8a3260d94 100644 --- a/detections/endpoint/excessive_number_of_taskhost_processes.yml +++ b/detections/endpoint/excessive_number_of_taskhost_processes.yml @@ -1,16 +1,18 @@ name: Excessive number of taskhost processes id: f443dac2-c7cf-11eb-ab51-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-20' author: Michael Hart status: production type: Anomaly -description: This detection targets behaviors observed in post exploit kits like Meterpreter - and Koadic that are run in memory. We have observed that these tools must invoke - an excessive number of taskhost.exe and taskhostex.exe processes to complete various - actions (discovery, lateral movement, etc.). It is extremely uncommon in the course - of normal operations to see so many distinct taskhost and taskhostex processes running - concurrently in a short time frame. +description: The following analytic identifies an excessive number of taskhost.exe + and taskhostex.exe processes running within a short time frame. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + their counts. This behavior is significant as it is commonly associated with post-exploitation + tools like Meterpreter and Koadic, which use multiple instances of these processes + for actions such as discovery and lateral movement. If confirmed malicious, this + activity could indicate an ongoing attack, allowing attackers to execute code, escalate + privileges, or move laterally within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process_id) as @@ -42,7 +44,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 80 - message: An excessive amount of taskhost.exe and taskhostex.exe was executed on $dest$ indicative of suspicious behavior. + message: An excessive amount of taskhost.exe and taskhostex.exe was executed on + $dest$ indicative of suspicious behavior. mitre_attack_id: - T1059 observable: @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/excessive_distinct_processes_from_windows_temp/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/excessive_distinct_processes_from_windows_temp/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/excessive_service_stop_attempt.yml b/detections/endpoint/excessive_service_stop_attempt.yml index 0fe4f63f7a..1319bf5119 100644 --- a/detections/endpoint/excessive_service_stop_attempt.yml +++ b/detections/endpoint/excessive_service_stop_attempt.yml @@ -1,14 +1,18 @@ name: Excessive Service Stop Attempt id: ae8d3f4a-acd7-11eb-8846-acde48001122 -version: 2 -date: '2021-05-04' +version: 3 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic identifies suspicious series of attempt to kill multiple - services on a system using either `net.exe` or `sc.exe`. This technique is use by - adversaries to terminate security services or other related services to continue - there objective and evade detections. +description: The following analytic detects multiple attempts to stop or delete services + on a system using `net.exe`, `sc.exe`, or `net1.exe`. It leverages Endpoint Detection + and Response (EDR) telemetry, focusing on process names and command-line executions + within a one-minute window. This activity is significant as it may indicate an adversary + attempting to disable security or critical services to evade detection and further + their objectives. If confirmed malicious, this could lead to the attacker gaining + persistence, escalating privileges, or disrupting essential services, thereby compromising + the system's security posture. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -74,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_usage_of_cacls_app.yml b/detections/endpoint/excessive_usage_of_cacls_app.yml index 0743e4ad80..343c5eb6a4 100644 --- a/detections/endpoint/excessive_usage_of_cacls_app.yml +++ b/detections/endpoint/excessive_usage_of_cacls_app.yml @@ -1,14 +1,17 @@ name: Excessive Usage Of Cacls App id: 0bdf6092-af17-11eb-939a-acde48001122 -version: 1 -date: '2021-05-07' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe` - or `icacls.exe` application to change file or folder permission. This behavior is - commonly seen where the adversary attempts to impair some users from deleting or - accessing its malware components or artifact from the compromised system. +description: The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe`, + or `icacls.exe` to change file or folder permissions. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as it may indicate an adversary attempting + to restrict access to malware components or artifacts on a compromised system. If + confirmed malicious, this behavior could prevent users from deleting or accessing + critical files, aiding in the persistence and concealment of malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -70,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_usage_of_net_app.yml b/detections/endpoint/excessive_usage_of_net_app.yml index 349f8bede3..b9557e2e91 100644 --- a/detections/endpoint/excessive_usage_of_net_app.yml +++ b/detections/endpoint/excessive_usage_of_net_app.yml @@ -1,14 +1,18 @@ name: Excessive Usage Of Net App id: 45e52536-ae42-11eb-b5c6-acde48001122 -version: 2 -date: '2023-06-13' +version: 3 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic identifies excessive usage of `net.exe` or `net1.exe` within - a bucket of time (1 minute). This behavior was seen in a Monero incident where the - adversary attempts to create many users, delete and disable users as part of its - malicious behavior. +description: The following analytic detects excessive usage of `net.exe` or `net1.exe` + within a one-minute interval. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names, parent processes, and command-line executions. + This behavior is significant as it may indicate an adversary attempting to create, + delete, or disable multiple user accounts rapidly, a tactic observed in Monero mining + incidents. If confirmed malicious, this activity could lead to unauthorized user + account manipulation, potentially compromising system integrity and enabling further + malicious actions. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -80,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_usage_of_nslookup_app.yml b/detections/endpoint/excessive_usage_of_nslookup_app.yml index a72d43fb50..9d61ab590e 100644 --- a/detections/endpoint/excessive_usage_of_nslookup_app.yml +++ b/detections/endpoint/excessive_usage_of_nslookup_app.yml @@ -1,24 +1,26 @@ name: Excessive Usage of NSLOOKUP App id: 0a69fdaa-a2b8-11eb-b16d-acde48001122 -version: 2 -date: '2022-06-03' +version: 3 +date: '2024-05-15' author: Teoderick Contreras, Stanislav Miskovic, Splunk status: production type: Anomaly -description: This search is to detect potential DNS exfiltration using nslookup application. - This technique are seen in couple of malware and APT group to exfiltrated collected - data in a infected machine or infected network. This detection is looking for unique - use of nslookup where it tries to use specific record type (TXT, A, AAAA) that are - commonly used by attacker and also the retry parameter which is designed to query - C2 DNS multiple tries. +description: The following analytic detects excessive usage of the nslookup application, + which may indicate potential DNS exfiltration attempts. It leverages Sysmon EventCode + 1 to monitor process executions, specifically focusing on nslookup.exe. The detection + identifies outliers by comparing the frequency of nslookup executions against a + calculated threshold. This activity is significant as it can reveal attempts by + malware or APT groups to exfiltrate data via DNS queries. If confirmed malicious, + this behavior could allow attackers to stealthily transfer sensitive information + out of the network, bypassing traditional data exfiltration defenses. data_source: - Sysmon EventID 1 search: '`sysmon` EventCode = 1 process_name = "nslookup.exe" | bucket _time span=1m - | stats count as numNsLookup by dest, _time | eventstats avg(numNsLookup) as - avgNsLookup, stdev(numNsLookup) as stdNsLookup, count as numSlots by dest | - eval upperThreshold=(avgNsLookup + stdNsLookup *3) | eval isOutlier=if(numNsLookup - > 20 and numNsLookup >= upperThreshold, 1, 0) | search isOutlier=1 | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `excessive_usage_of_nslookup_app_filter`' + | stats count as numNsLookup by dest, _time | eventstats avg(numNsLookup) as avgNsLookup, + stdev(numNsLookup) as stdNsLookup, count as numSlots by dest | eval upperThreshold=(avgNsLookup + + stdNsLookup *3) | eval isOutlier=if(numNsLookup > 20 and numNsLookup >= upperThreshold, + 1, 0) | search isOutlier=1 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `excessive_usage_of_nslookup_app_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -60,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/nslookup_exfil/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/nslookup_exfil/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/excessive_usage_of_sc_service_utility.yml b/detections/endpoint/excessive_usage_of_sc_service_utility.yml index bec9736486..074a2c9698 100644 --- a/detections/endpoint/excessive_usage_of_sc_service_utility.yml +++ b/detections/endpoint/excessive_usage_of_sc_service_utility.yml @@ -1,14 +1,18 @@ name: Excessive Usage Of SC Service Utility id: cb6b339e-d4c6-11eb-a026-acde48001122 -version: 1 -date: '2021-06-24' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a suspicious excessive usage of sc.exe in a - host machine. This technique was seen in several ransomware , xmrig and other malware - to create, modify, delete or disable a service may related to security application - or to gain privilege escalation. +description: The following analytic detects excessive usage of the `sc.exe` service + utility on a host machine. It leverages Sysmon EventCode 1 logs to identify instances + where `sc.exe` is executed more frequently than normal within a 15-minute window. + This behavior is significant as it is commonly associated with ransomware, cryptocurrency + miners, and other malware attempting to create, modify, delete, or disable services, + potentially related to security applications or for privilege escalation. If confirmed + malicious, this activity could allow attackers to manipulate critical services, + leading to system compromise or disruption of security defenses. data_source: - Sysmon EventID 1 search: '`sysmon` EventCode = 1 process_name = "sc.exe" | bucket _time span=15m | @@ -55,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/exchange_powershell_abuse_via_ssrf.yml b/detections/endpoint/exchange_powershell_abuse_via_ssrf.yml index dd011c249e..46ee0fee33 100644 --- a/detections/endpoint/exchange_powershell_abuse_via_ssrf.yml +++ b/detections/endpoint/exchange_powershell_abuse_via_ssrf.yml @@ -1,26 +1,18 @@ name: Exchange PowerShell Abuse via SSRF id: 29228ab4-0762-11ec-94aa-acde48001122 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-21' author: Michael Haag, Splunk status: experimental type: TTP -description: 'This analytic identifies suspicious behavior related to ProxyShell against - on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 - which utilizes the Web Datamodel. - - Modification of this analytic is requried to ensure fields are mapped accordingly. - - - A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. - This is indicative of accessing PowerShell on the back end of Exchange with SSRF. - - - An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` - (abbreviated) - - Review the source attempting to perform this activity against your environment. - In addition, review PowerShell logs and access recently granted to Exchange roles.' +description: 'The following analytic detects suspicious behavior indicative of ProxyShell + exploitation against on-premise Microsoft Exchange servers. It identifies HTTP POST + requests to `autodiscover.json` containing `PowerShell` in the URI, leveraging server-side + request forgery (SSRF) to access backend PowerShell. This detection uses Exchange + server logs ingested into Splunk. Monitoring this activity is crucial as it may + indicate an attacker attempting to execute commands or scripts on the Exchange server. + If confirmed malicious, this could lead to unauthorized access, privilege escalation, + or persistent control over the Exchange environment.' data_source: [] search: '`exchange` c_uri="*//autodiscover*" cs_uri_query="*PowerShell*" cs_method="POST" | stats count min(_time) as firstTime max(_time) as lastTime by dest, cs_uri_query, diff --git a/detections/endpoint/exchange_powershell_module_usage.yml b/detections/endpoint/exchange_powershell_module_usage.yml index 6d746adcb2..cc3fa2cf81 100644 --- a/detections/endpoint/exchange_powershell_module_usage.yml +++ b/detections/endpoint/exchange_powershell_module_usage.yml @@ -1,39 +1,26 @@ name: Exchange PowerShell Module Usage id: 2d10095e-05ae-11ec-8fdf-acde48001122 -version: 5 -date: '2023-07-10' +version: 6 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the usage of Exchange PowerShell modules - that were recently used for a proof of concept related to ProxyShell. Adversaries - may abuse a limited set of PwSh Modules related to Exchange once gained access via - ProxyShell or ProxyNotShell. - - Inherently, the usage of the modules is not malicious, but reviewing parallel processes, - and user, of the session will assist with determining the intent. - - Module - New-MailboxExportRequest will begin the process of exporting contents of - a primary mailbox or archive to a .pst file. - - Module - New-managementroleassignment can assign a management role to a management - role group, management role assignment policy, user, or universal security group - (USG). - - Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate - of search results, place search results on In-Place Hold or copy them to a Discovery - mailbox. You can also place all contents in a mailbox on hold by not specifying - a search query, which accomplishes similar results as Litigation Hold. \ Module - - Get-Recipient cmdlet to view existing recipient objects in your organization. - This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, - mail contacts, and distribution groups).' +description: 'The following analytic detects the usage of specific Exchange PowerShell + modules, such as New-MailboxExportRequest, New-ManagementRoleAssignment, New-MailboxSearch, + and Get-Recipient. It leverages PowerShell Script Block Logging (EventCode 4104) + to identify these commands. This activity is significant because these modules can + be exploited by adversaries who have gained access via ProxyShell or ProxyNotShell + vulnerabilities. If confirmed malicious, attackers could export mailbox contents, + assign management roles, conduct mailbox searches, or view recipient objects, potentially + leading to data exfiltration, privilege escalation, or unauthorized access to sensitive + information.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN ("*New-MailboxExportRequest*", "*New-ManagementRoleAssignment*", "*New-MailboxSearch*", "*Get-Recipient*", "Search-Mailbox") | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer - UserID EventCode ScriptBlockText | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `exchange_powershell_module_usage_filter`' + UserID EventCode ScriptBlockText | rename Computer as dest |rename UserID as user + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `exchange_powershell_module_usage_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -84,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/exchange/windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/exchange/windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/executable_file_written_in_administrative_smb_share.yml b/detections/endpoint/executable_file_written_in_administrative_smb_share.yml index f1fcfa6a5d..ac28c68fd7 100644 --- a/detections/endpoint/executable_file_written_in_administrative_smb_share.yml +++ b/detections/endpoint/executable_file_written_in_administrative_smb_share.yml @@ -1,22 +1,25 @@ name: Executable File Written in Administrative SMB Share id: f63c34fe-a435-11eb-935a-acde48001122 -version: 3 -date: '2024-02-14' +version: 4 +date: '2024-05-16' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies executable files (.exe or .dll) being - written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents - suspicious behavior as its commonly used by tools like PsExec/PaExec and others - to stage service binaries before creating and starting a Windows service on remote - endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral - movement and remote code execution. The Trickbot malware family also implements - this behavior to try to infect other machines in the infected network. +description: The following analytic detects executable files (.exe or .dll) being + written to Windows administrative SMB shares (Admin$, IPC$, C$). It leverages Windows + Security Event Logs with EventCode 5145 to identify this activity. This behavior + is significant as it is commonly used by tools like PsExec/PaExec for staging binaries + before creating and starting services on remote endpoints, a technique often employed + for lateral movement and remote code execution. If confirmed malicious, this activity + could allow an attacker to execute arbitrary code remotely, potentially compromising + additional systems within the network. data_source: - Windows Event Log Security 5145 -search: '`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.exe","*.dll") ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$") AccessMask= "0x2" - | stats min(_time) as firstTime max(_time) as lastTime count by EventCode ShareName RelativeTargetName ObjectType AccessMask src_user src_port IpAddress - | `security_content_ctime(firstTime)` | `executable_file_written_in_administrative_smb_share_filter`' +search: '`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.exe","*.dll") + ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$") AccessMask= + "0x2" | stats min(_time) as firstTime max(_time) as lastTime count by EventCode + ShareName RelativeTargetName ObjectType AccessMask src_user src_port IpAddress | + `security_content_ctime(firstTime)` | `executable_file_written_in_administrative_smb_share_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. @@ -42,8 +45,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 70 - message: $src_user$ dropped or created an executable file in known sensitive SMB share. Share - name=$ShareName$, Target name=$RelativeTargetName$, and Access mask=$AccessMask$ + message: $src_user$ dropped or created an executable file in known sensitive SMB + share. Share name=$ShareName$, Target name=$RelativeTargetName$, and Access mask=$AccessMask$ mitre_attack_id: - T1021 - T1021.002 @@ -71,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/exe_smbshare/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/exe_smbshare/windows-xml.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/executables_or_script_creation_in_suspicious_path.yml b/detections/endpoint/executables_or_script_creation_in_suspicious_path.yml index dc2bb72b2a..3d9eac40ef 100644 --- a/detections/endpoint/executables_or_script_creation_in_suspicious_path.yml +++ b/detections/endpoint/executables_or_script_creation_in_suspicious_path.yml @@ -1,17 +1,18 @@ name: Executables Or Script Creation In Suspicious Path id: a7e3f0f0-ae42-11eb-b245-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic identifies potentially malicious executables or scripts - by examining a list of suspicious file paths on Windows Operating System. The purpose - of this technique is to uncover files with known file extensions that could be used - by adversaries to evade detection and persistence. The suspicious file paths selected - for investigation are typically uncommon and uncommonly associated with executable - or script files. By scrutinizing these paths, we can proactively identify potential - security threats and enhance overall system security. +description: The following analytic identifies the creation of executables or scripts + in suspicious file paths on Windows systems. It leverages the Endpoint.Filesystem + data model to detect files with specific extensions (e.g., .exe, .dll, .ps1) created + in uncommon directories (e.g., \windows\fonts\, \users\public\). This activity is + significant as adversaries often use these paths to evade detection and maintain + persistence. If confirmed malicious, this behavior could allow attackers to execute + unauthorized code, escalate privileges, or persist within the environment, posing + a significant security threat. data_source: - Sysmon EventID 11 search: '|tstats `security_content_summariesonly` values(Filesystem.file_path) as @@ -103,6 +104,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/execute_javascript_with_jscript_com_clsid.yml b/detections/endpoint/execute_javascript_with_jscript_com_clsid.yml index a7694b8606..05722b76c7 100644 --- a/detections/endpoint/execute_javascript_with_jscript_com_clsid.yml +++ b/detections/endpoint/execute_javascript_with_jscript_com_clsid.yml @@ -1,14 +1,18 @@ name: Execute Javascript With Jscript COM CLSID id: dc64d064-d346-11eb-8588-acde48001122 -version: 1 -date: '2021-06-22' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will identify suspicious process of cscript.exe where it - tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique - was seen in ransomware (reddot ransomware) where it execute javascript with this - com object with combination of amsi disabling technique. +description: The following analytic detects the execution of JavaScript using the + JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, command-line executions, + and parent processes. This activity is significant as it is a known technique used + by ransomware, such as Reddot, to execute malicious scripts and potentially disable + AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow + attackers to execute arbitrary code, evade detection, and maintain persistence within + the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/execution_of_file_with_multiple_extensions.yml b/detections/endpoint/execution_of_file_with_multiple_extensions.yml index c1720e7072..e5a8a177a1 100644 --- a/detections/endpoint/execution_of_file_with_multiple_extensions.yml +++ b/detections/endpoint/execution_of_file_with_multiple_extensions.yml @@ -1,22 +1,27 @@ name: Execution of File with Multiple Extensions id: b06a555e-dce0-417d-a2eb-28a5d8d66ef7 -version: 3 -date: '2020-11-18' +version: 4 +date: '2024-05-26' author: Rico Valdez, Teoderick Contreras, Splunk status: production type: TTP -description: This search looks for processes launched from files that have double - extensions in the file name. This is typically done to obscure the "real" file extension - and make it appear as though the file being accessed is a data file, as opposed - to executable content. +description: The following analytic detects the execution of files with multiple extensions, + such as ".doc.exe" or ".pdf.exe". This behavior is identified using Endpoint Detection + and Response (EDR) telemetry, focusing on process creation events where the file + name contains double extensions. This activity is significant because attackers + often use double extensions to disguise malicious executables as benign documents, + increasing the likelihood of user execution. If confirmed malicious, this technique + can lead to unauthorized code execution, potentially compromising the endpoint and + allowing further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process IN ("*.doc.exe", "*.xls.exe","*.ppt.exe", "*.htm.exe", "*.html.exe", "*.txt.exe", "*.pdf.exe", "*.docx.exe", "*.xlsx.exe", "*.pptx.exe","*.one.exe", "*.bat.exe", "*rtf.exe") by Processes.dest - Processes.user Processes.process Processes.process_name Processes.parent_process | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | `execution_of_file_with_multiple_extensions_filter`' + Processes.user Processes.process Processes.process_name Processes.parent_process + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` + | `execution_of_file_with_multiple_extensions_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -72,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/extraction_of_registry_hives.yml b/detections/endpoint/extraction_of_registry_hives.yml index 8c65a999c5..bcadff399d 100644 --- a/detections/endpoint/extraction_of_registry_hives.yml +++ b/detections/endpoint/extraction_of_registry_hives.yml @@ -1,23 +1,27 @@ name: Extraction of Registry Hives id: 8bbb7d58-b360-11eb-ba21-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of `reg.exe` exporting Windows - Registry hives containing credentials. Adversaries may use this technique to export - registry hives for offline credential access attacks. Typically found executed from - a untrusted process or script. Upon execution, a file will be written to disk. +description: The following analytic detects the use of `reg.exe` to export Windows + Registry hives, which may contain sensitive credentials. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions involving `save` or `export` actions targeting the `sam`, `system`, or + `security` hives. This activity is significant as it indicates potential offline + credential access attacks, often executed from untrusted processes or scripts. If + confirmed malicious, attackers could gain access to credential data, enabling further + compromise and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_reg` (Processes.process=*save* OR Processes.process=*export*) AND (Processes.process="*\sam *" OR Processes.process="*\system *" OR Processes.process="*\security *") by Processes.dest Processes.user Processes.parent_process - Processes.process_name Processes.parent_process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `extraction_of_registry_hives_filter`' + Processes.process_name Processes.parent_process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `extraction_of_registry_hives_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -83,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/file_with_samsam_extension.yml b/detections/endpoint/file_with_samsam_extension.yml index 8a01dbf839..8cf0a0e31e 100644 --- a/detections/endpoint/file_with_samsam_extension.yml +++ b/detections/endpoint/file_with_samsam_extension.yml @@ -1,12 +1,12 @@ name: File with Samsam Extension id: 02c6cfc2-ae66-4735-bfc7-6291da834cbf -version: 1 -date: '2018-12-14' +version: 2 +date: '2024-05-22' author: Rico Valdez, Splunk status: production type: TTP description: |- - The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents. + The following analytic detects file writes with extensions indicative of a SamSam ransomware attack. It leverages file-system activity data to identify file names ending in .stubbin, .berkshire, .satoshi, .sophos, or .keyxml. This activity is significant because SamSam ransomware is highly destructive, leading to file encryption and ransom demands. If confirmed malicious, the impact includes significant financial losses, operational disruptions, and reputational damage. Immediate actions should include isolating affected systems, restoring files from backups, and investigating the attack source to prevent further incidents. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -60,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/samsam_extension/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/samsam_extension/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/firewall_allowed_program_enable.yml b/detections/endpoint/firewall_allowed_program_enable.yml index 8de88804cf..004add9e5c 100644 --- a/detections/endpoint/firewall_allowed_program_enable.yml +++ b/detections/endpoint/firewall_allowed_program_enable.yml @@ -1,15 +1,18 @@ name: Firewall Allowed Program Enable id: 9a8f63a8-43ac-11ec-904c-acde48001122 -version: 1 -date: '2021-11-12' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic detects a potential suspicious modification of firewall - rule allowing to execute specific application. This technique was identified when - an adversary and red teams to bypassed firewall file execution restriction in a - targetted host. Take note that this event or command can run by administrator during - testing or allowing legitimate tool or application. +description: The following analytic detects the modification of a firewall rule to + allow the execution of a specific application. This detection leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process creation events + with command-line arguments related to firewall rule changes. This activity is significant + as it may indicate an attempt to bypass firewall restrictions, potentially allowing + unauthorized applications to communicate over the network. If confirmed malicious, + this could enable an attacker to execute arbitrary code, escalate privileges, or + maintain persistence within the target environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/fodhelper_uac_bypass.yml b/detections/endpoint/fodhelper_uac_bypass.yml index 27f507f29d..3bf08952f6 100644 --- a/detections/endpoint/fodhelper_uac_bypass.yml +++ b/detections/endpoint/fodhelper_uac_bypass.yml @@ -1,31 +1,26 @@ name: FodHelper UAC Bypass id: 909f8fd8-7ac8-11eb-a1f3-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: 'Fodhelper.exe has a known UAC bypass as it attempts to look for specific - registry keys upon execution, that do not exist. Therefore, an attacker can write - its malicious commands in these registry keys to be executed by fodhelper.exe with - the highest privilege. - - * `HKCU:\Software\Classes\ms-settings\shell\open\command` - - * `HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute` - - * `HKCU:\Software\Classes\ms-settings\shell\open\command\(default)` - - Upon triage, fodhelper.exe will have a child process and read access will occur - on the registry keys. Isolate the endpoint and review parallel processes for additional - behavior.' +description: 'The following analytic detects the execution of fodhelper.exe, which + is known to exploit a User Account Control (UAC) bypass by leveraging specific registry + keys. The detection method uses Endpoint Detection and Response (EDR) telemetry + to identify when fodhelper.exe spawns a child process and accesses the registry + keys. This activity is significant because it indicates a potential privilege escalation + attempt by an attacker. If confirmed malicious, the attacker could execute commands + with elevated privileges, leading to unauthorized system changes and potential full + system compromise.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=fodhelper.exe - by Processes.dest Processes.user Processes.parent_process Processes.parent_process_name Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `fodhelper_uac_bypass_filter`' + by Processes.dest Processes.user Processes.parent_process Processes.parent_process_name + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` + | `fodhelper_uac_bypass_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -48,9 +43,8 @@ tags: asset_type: Endpoint confidence: 90 impact: 90 - message: Suspicious registy keys added by process fodhelper.exe - with a parent_process of $parent_process_name$ that has been executed on $dest$ - by $user$. + message: Suspicious registy keys added by process fodhelper.exe with a parent_process + of $parent_process_name$ that has been executed on $dest$ by $user$. mitre_attack_id: - T1112 - T1548.002 @@ -87,6 +81,7 @@ tags: 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 + - 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 diff --git a/detections/endpoint/fsutil_zeroing_file.yml b/detections/endpoint/fsutil_zeroing_file.yml index ed8f2d3f1c..b50136e550 100644 --- a/detections/endpoint/fsutil_zeroing_file.yml +++ b/detections/endpoint/fsutil_zeroing_file.yml @@ -1,13 +1,18 @@ name: Fsutil Zeroing File id: 4e5e024e-fabb-11eb-8b8f-acde48001122 -version: 1 -date: '2021-08-11' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious fsutil process to zeroing a target - file. This technique was seen in lockbit ransomware where it tries to zero out its - malware path as part of its defense evasion after encrypting the compromised host. +description: The following analytic detects the execution of the 'fsutil' command + with the 'setzerodata' parameter, which zeros out a target file. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + names and command-line arguments. This activity is significant because it is a technique + used by ransomware, such as LockBit, to evade detection by erasing its malware path + after encrypting the host. If confirmed malicious, this action could hinder forensic + investigations and allow attackers to cover their tracks, complicating incident + response efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/fsutil_file_zero/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/fsutil_file_zero/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell.yml b/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell.yml index 0d7ebb36de..0fc63d761e 100644 --- a/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell.yml +++ b/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell.yml @@ -1,14 +1,18 @@ name: Get ADDefaultDomainPasswordPolicy with Powershell id: 36e46ebe-065a-11ec-b4c7-acde48001122 -version: 1 -date: '2021-08-26' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` executing the - Get-ADDefaultDomainPasswordPolicy commandlet used to obtain the password policy - in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate - domain policies for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` running + the `Get-ADDefaultDomainPasswordPolicy` cmdlet, which is used to retrieve the password + policy in a Windows domain. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line executions. + Monitoring this activity is crucial as it can indicate attempts by adversaries to + gather information about domain policies for situational awareness and Active Directory + discovery. If confirmed malicious, this activity could lead to further reconnaissance + and potential exploitation of domain security settings. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell_script_block.yml b/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell_script_block.yml index 17098bb4c7..8933daddbf 100644 --- a/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell_script_block.yml +++ b/detections/endpoint/get_addefaultdomainpasswordpolicy_with_powershell_script_block.yml @@ -1,21 +1,24 @@ name: Get ADDefaultDomainPasswordPolicy with Powershell Script Block id: 1ff7ccc8-065a-11ec-91e4-acde48001122 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-27' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-ADDefaultDomainPasswordPolicy` commandlet - used to obtain the password policy in a Windows domain. Red Teams and adversaries - alike may use PowerShell to enumerate domain policies for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-ADDefaultDomainPasswordPolicy` + PowerShell cmdlet, which is used to retrieve the password policy in a Windows domain. + This detection leverages PowerShell Script Block Logging (EventCode=4104) to identify + the specific command execution. Monitoring this activity is significant as it can + indicate an attempt to gather domain policy information, which is often a precursor + to further malicious actions. If confirmed malicious, this activity could allow + an attacker to understand password policies, aiding in password attacks or further + domain enumeration. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText ="*Get-ADDefaultDomainPasswordPolicy*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `get_addefaultdomainpasswordpolicy_with_powershell_script_block_filter`' + Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `get_addefaultdomainpasswordpolicy_with_powershell_script_block_filter`' how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. @@ -30,7 +33,8 @@ tags: asset_type: Endpoint confidence: 30 impact: 30 - message: Powershell process having commandline "Get-ADDefaultDomainPasswordPolicy" to query domain password policy on $dest$ + message: Powershell process having commandline "Get-ADDefaultDomainPasswordPolicy" + to query domain password policy on $dest$ mitre_attack_id: - T1201 observable: @@ -57,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_aduser_with_powershell.yml b/detections/endpoint/get_aduser_with_powershell.yml index f96c8015a4..cfc54fe740 100644 --- a/detections/endpoint/get_aduser_with_powershell.yml +++ b/detections/endpoint/get_aduser_with_powershell.yml @@ -1,14 +1,18 @@ name: Get ADUser with PowerShell id: 0b6ee3f4-04e3-11ec-a87d-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to enumerate domain users. The `Get-AdUser' commandlet returns - a list of all domain users. Red Teams and adversaries alike may use this commandlet - to identify remote systems for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments used to enumerate domain users via the `Get-ADUser` cmdlet. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process names and command-line executions. This activity is significant as it may + indicate an attempt by adversaries to gather information about domain users for + situational awareness and Active Directory discovery. If confirmed malicious, this + behavior could lead to further reconnaissance, enabling attackers to identify high-value + targets and plan subsequent attacks. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_aduser_with_powershell_script_block.yml b/detections/endpoint/get_aduser_with_powershell_script_block.yml index 7abe863d9b..20c59c72ef 100644 --- a/detections/endpoint/get_aduser_with_powershell_script_block.yml +++ b/detections/endpoint/get_aduser_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: Get ADUser with PowerShell Script Block id: 21432e40-04f4-11ec-b7e6-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-29' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-AdGUser` commandlet. The `Get-AdUser` commandlet - is used to return a list of all domain users. Red Teams and adversaries may leverage - this commandlet to enumerate domain groups for situational awareness and Active - Directory Discovery. +description: The following analytic detects the execution of the `Get-AdUser` PowerShell + cmdlet, which is used to enumerate all domain users. It leverages PowerShell Script + Block Logging (EventCode=4104) to identify instances where this command is executed + with a filter. This activity is significant as it may indicate an attempt by adversaries + or Red Teams to gather information about domain users for situational awareness + and Active Directory discovery. If confirmed malicious, this behavior could lead + to further reconnaissance and potential exploitation of user accounts within the + domain. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-aduser*" ScriptBlockText @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/aduser_powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/aduser_powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell.yml b/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell.yml index ece8f4e24c..cb7cfc985d 100644 --- a/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell.yml +++ b/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell.yml @@ -1,14 +1,18 @@ name: Get ADUserResultantPasswordPolicy with Powershell id: 8b5ef342-065a-11ec-b0fc-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` executing the - Get ADUserResultantPasswordPolicy commandlet used to obtain the password policy - in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate - domain policies for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` running + the `Get-ADUserResultantPasswordPolicy` cmdlet, which is used to obtain the password + policy in a Windows domain. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant as it indicates potential enumeration of domain policies, a common + tactic for situational awareness and Active Directory discovery by adversaries. + If confirmed malicious, this could allow attackers to understand password policies, + aiding in further attacks such as password spraying or brute force attempts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell_script_block.yml b/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell_script_block.yml index 7f0fda236e..0b54225dd0 100644 --- a/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell_script_block.yml +++ b/detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: Get ADUserResultantPasswordPolicy with Powershell Script Block id: 737e1eb0-065a-11ec-921a-acde48001122 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-09' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-ADUserResultantPasswordPolicy` commandlet - used to obtain the password policy in a Windows domain. Red Teams and adversaries - alike may use PowerShell to enumerate domain policies for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-ADUserResultantPasswordPolicy` + PowerShell cmdlet, which is used to obtain the password policy in a Windows domain. + It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. + Monitoring this behavior is significant as it may indicate an attempt to enumerate + domain policies, a common tactic used by adversaries for situational awareness and + Active Directory discovery. If confirmed malicious, this activity could allow attackers + to understand password policies, aiding in further attacks such as password guessing + or policy exploitation. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText="*Get-ADUserResultantPasswordPolicy*" @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domainpolicy_with_powershell.yml b/detections/endpoint/get_domainpolicy_with_powershell.yml index d12e93cd23..327f40553b 100644 --- a/detections/endpoint/get_domainpolicy_with_powershell.yml +++ b/detections/endpoint/get_domainpolicy_with_powershell.yml @@ -1,14 +1,18 @@ name: Get DomainPolicy with Powershell id: b8f9947e-065a-11ec-aafb-acde48001122 -version: 1 -date: '2021-08-26' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` executing the - `Get-DomainPolicy` commandlet used to obtain the password policy in a Windows domain. - Red Teams and adversaries alike may use PowerShell to enumerate domain policies - for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` running + the `Get-DomainPolicy` cmdlet, which is used to retrieve password policies in a + Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions. This activity is significant + as it indicates potential reconnaissance efforts by adversaries to gather domain + policy information, which is crucial for planning further attacks. If confirmed + malicious, this could lead to unauthorized access to sensitive domain configurations, + aiding in privilege escalation and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1201/pwd_policy_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domainpolicy_with_powershell_script_block.yml b/detections/endpoint/get_domainpolicy_with_powershell_script_block.yml index 70a2e886e0..59b8d1e7b7 100644 --- a/detections/endpoint/get_domainpolicy_with_powershell_script_block.yml +++ b/detections/endpoint/get_domainpolicy_with_powershell_script_block.yml @@ -1,14 +1,18 @@ name: Get DomainPolicy with Powershell Script Block id: a360d2b2-065a-11ec-b0bf-acde48001122 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get DomainPolicy` commandlet used to obtain the - password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell - to enumerate domain policies for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-DomainPolicy` + cmdlet using PowerShell Script Block Logging (EventCode=4104). It leverages logs + capturing script block text to identify attempts to obtain the password policy in + a Windows domain. This activity is significant as it indicates potential reconnaissance + efforts by adversaries or Red Teams to gather domain policy information, which is + crucial for planning further attacks. If confirmed malicious, this behavior could + lead to detailed knowledge of domain security settings, aiding in privilege escalation + or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText ="*Get-DomainPolicy*" | stats @@ -58,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domainpolicy.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domainpolicy.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domaintrust_with_powershell.yml b/detections/endpoint/get_domaintrust_with_powershell.yml index d6001c8094..4932bbe871 100644 --- a/detections/endpoint/get_domaintrust_with_powershell.yml +++ b/detections/endpoint/get_domaintrust_with_powershell.yml @@ -1,16 +1,19 @@ name: Get-DomainTrust with PowerShell id: 4fa7f846-054a-11ec-a836-acde48001122 -version: 1 -date: '2021-08-24' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: TTP -description: This analytic identifies Get-DomainTrust from PowerView in order to gather - domain trust information. Typically, this is utilized within a script being executed - and used to enumerate the domain trust information. This grants the adversary an - understanding of how large or small the domain is. During triage, review parallel - processes using an EDR product or 4688 events. It will be important to understand - the timeline of events around this activity. +description: The following analytic identifies the execution of the Get-DomainTrust + command from PowerView using PowerShell, which is used to gather domain trust information. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process and command-line telemetry. This activity is significant as + it indicates potential reconnaissance efforts by an adversary to understand domain + trust relationships, which can inform lateral movement strategies. If confirmed + malicious, this could allow attackers to map out the network, identify potential + targets, and plan further attacks, potentially compromising additional systems within + the domain. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domaintrust_with_powershell_script_block.yml b/detections/endpoint/get_domaintrust_with_powershell_script_block.yml index d77e610a37..1e54882d05 100644 --- a/detections/endpoint/get_domaintrust_with_powershell_script_block.yml +++ b/detections/endpoint/get_domaintrust_with_powershell_script_block.yml @@ -1,28 +1,24 @@ name: Get-DomainTrust with PowerShell Script Block id: 89275e7e-0548-11ec-bf75-acde48001122 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies Get-DomainTrust from PowerView in order to gather domain - trust information. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of the Get-DomainTrust + command from PowerView using PowerShell Script Block Logging (EventCode=4104). This + method captures the full command sent to PowerShell, allowing for detailed inspection. + Identifying this activity is significant because it may indicate an attempt to gather + domain trust information, which is often a precursor to lateral movement or privilege + escalation. If confirmed malicious, this activity could enable an attacker to map + trust relationships within the domain, potentially leading to further exploitation + and compromise of additional systems.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-domaintrust*" | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode - ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `get_domaintrust_with_powershell_script_block_filter`' + ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `get_domaintrust_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -69,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domaintrust.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domaintrust.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domainuser_with_powershell.yml b/detections/endpoint/get_domainuser_with_powershell.yml index 88bc26415c..f72d056f00 100644 --- a/detections/endpoint/get_domainuser_with_powershell.yml +++ b/detections/endpoint/get_domainuser_with_powershell.yml @@ -1,15 +1,19 @@ name: Get DomainUser with PowerShell id: 9a5a41d6-04e7-11ec-923c-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to enumerate domain users. `Get-DomainUser` is part of PowerView, - a PowerShell tool used to perform enumeration on Windows domains. Red Teams and - adversaries alike may leverage PowerView to enumerate domain users for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments used to enumerate domain users via the `Get-DomainUser` command. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions mapped to the `Processes` + node of the `Endpoint` data model. This activity is significant as it indicates + potential reconnaissance efforts by adversaries or Red Teams using PowerView for + Active Directory discovery. If confirmed malicious, this could allow attackers to + gain situational awareness and identify valuable targets within the domain, potentially + leading to further exploitation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_domainuser_with_powershell_script_block.yml b/detections/endpoint/get_domainuser_with_powershell_script_block.yml index 74e9eeaaaf..e05a37c3ba 100644 --- a/detections/endpoint/get_domainuser_with_powershell_script_block.yml +++ b/detections/endpoint/get_domainuser_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: Get DomainUser with PowerShell Script Block id: 61994268-04f4-11ec-865c-acde48001122 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-09' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainUser` commandlet. `GetDomainUser` is - part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. - Red Teams and adversaries alike may use PowerView to enumerate domain users for - situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-DomainUser` + cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is part + of PowerView, a tool often used for domain enumeration. The detection leverages + PowerShell operational logs to identify instances where this command is executed. + Monitoring this activity is crucial as it may indicate an adversary's attempt to + gather information about domain users, which is a common step in Active Directory + Discovery. If confirmed malicious, this activity could lead to further reconnaissance + and potential exploitation of domain resources. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-DomainUser*" | stats @@ -58,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_foresttrust_with_powershell.yml b/detections/endpoint/get_foresttrust_with_powershell.yml index 5f2f0c740a..d14075d71f 100644 --- a/detections/endpoint/get_foresttrust_with_powershell.yml +++ b/detections/endpoint/get_foresttrust_with_powershell.yml @@ -1,16 +1,18 @@ name: Get-ForestTrust with PowerShell id: 584f4884-0bf1-11ec-a5ec-acde48001122 -version: 1 -date: '2021-09-02' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: This analytic identifies Get-ForestTrust from PowerSploit in order to - gather domain trust information. Typically, this is utilized within a script being - executed and used to enumerate the domain trust information. This grants the adversary - an understanding of how large or small the domain is. During triage, review parallel - processes using an EDR product or 4688 events. It will be important to understand - the timeline of events around this activity. +description: The following analytic detects the execution of the Get-ForestTrust command + via PowerShell, commonly used by adversaries to gather domain trust information. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions. Identifying this activity + is crucial as it indicates potential reconnaissance efforts to map out domain trusts, + which can inform further attacks. If confirmed malicious, this activity could allow + attackers to understand domain relationships, aiding in lateral movement and privilege + escalation within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_foresttrust_with_powershell_script_block.yml b/detections/endpoint/get_foresttrust_with_powershell_script_block.yml index abe8fe210d..553b45eccc 100644 --- a/detections/endpoint/get_foresttrust_with_powershell_script_block.yml +++ b/detections/endpoint/get_foresttrust_with_powershell_script_block.yml @@ -1,28 +1,24 @@ name: Get-ForestTrust with PowerShell Script Block id: 70fac80e-0bf1-11ec-9ba0-acde48001122 -version: 2 -date: '2022-02-24' +version: 3 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies Get-ForestTrust from PowerSploit in order to gather domain - trust information. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of the Get-ForestTrust + command from PowerSploit using PowerShell Script Block Logging (EventCode=4104). + This method captures the full command sent to PowerShell, providing detailed visibility + into potentially suspicious activities. Monitoring this behavior is crucial as it + can indicate an attempt to gather domain trust information, which is often a precursor + to lateral movement or privilege escalation. If confirmed malicious, this activity + could allow an attacker to map trust relationships within the domain, facilitating + further exploitation and access to sensitive resources.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-foresttrust*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `get_foresttrust_with_powershell_script_block_filter`' + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `get_foresttrust_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -67,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_wmiobject_group_discovery.yml b/detections/endpoint/get_wmiobject_group_discovery.yml index 92c916392c..1c49b46dd9 100644 --- a/detections/endpoint/get_wmiobject_group_discovery.yml +++ b/detections/endpoint/get_wmiobject_group_discovery.yml @@ -1,15 +1,17 @@ name: Get WMIObject Group Discovery id: 5434f670-155d-11ec-8cca-acde48001122 -version: 1 -date: '2021-09-14' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic identifies the use of `Get-WMIObject Win32_Group` - being used with PowerShell to identify local groups on the endpoint. \ Typically, - by itself, is not malicious but may raise suspicion based on time of day, endpoint - and username. \ During triage, review parallel processes and identify any further - suspicious behavior. +description: The following analytic detects the use of the `Get-WMIObject Win32_Group` + command executed via PowerShell to enumerate local groups on an endpoint. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + names and command-line executions. Identifying local groups can be a precursor to + privilege escalation or lateral movement. If confirmed malicious, this activity + could allow an attacker to map out group memberships, aiding in further exploitation + or unauthorized access to sensitive resources. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/get_wmiobject_group_discovery_with_script_block_logging.yml b/detections/endpoint/get_wmiobject_group_discovery_with_script_block_logging.yml index c41dfea6ef..7d41986854 100644 --- a/detections/endpoint/get_wmiobject_group_discovery_with_script_block_logging.yml +++ b/detections/endpoint/get_wmiobject_group_discovery_with_script_block_logging.yml @@ -1,29 +1,23 @@ name: Get WMIObject Group Discovery with Script Block Logging id: 69df7f7c-155d-11ec-a055-acde48001122 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies the usage of `Get-WMIObject Win32_Group`, which is typically - used as a way to identify groups on the endpoint. Typically, by itself, is not - malicious but may raise suspicion based on time of day, endpoint and username. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of the `Get-WMIObject Win32_Group` + command using PowerShell Script Block Logging (EventCode=4104). This method captures + the full command sent to PowerShell, allowing for detailed analysis. Identifying + group information on an endpoint is not inherently malicious but can be suspicious + based on context such as time, endpoint, and user. This activity is significant + as it may indicate reconnaissance efforts by an attacker. If confirmed malicious, + it could lead to further enumeration and potential lateral movement within the network.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-WMIObject*" AND ScriptBlockText = "*Win32_Group*" | stats count min(_time) as firstTime max(_time) as lastTime by - EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `get_wmiobject_group_discovery_with_script_block_logging_filter`' + EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `get_wmiobject_group_discovery_with_script_block_logging_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -69,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getadcomputer_with_powershell.yml b/detections/endpoint/getadcomputer_with_powershell.yml index 6362030f0d..fd71cbaada 100644 --- a/detections/endpoint/getadcomputer_with_powershell.yml +++ b/detections/endpoint/getadcomputer_with_powershell.yml @@ -1,14 +1,18 @@ name: GetAdComputer with PowerShell id: c5a31f80-5888-4d81-9f78-1cc65026316e -version: 1 -date: '2021-09-07' +version: 2 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to discover remote systems. The `Get-AdComputer' commandlet returns - a list of all domain computers. Red Teams and adversaries alike may use this commandlet - to identify remote systems for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + the `Get-AdComputer` commandlet, which is used to discover remote systems within + a domain. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line arguments. This activity is significant + because it indicates potential reconnaissance efforts by adversaries to map out + domain computers, which is a common step in the attack lifecycle. If confirmed malicious, + this behavior could allow attackers to gain situational awareness and plan further + attacks, potentially leading to unauthorized access and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getadcomputer_with_powershell_script_block.yml b/detections/endpoint/getadcomputer_with_powershell_script_block.yml index ba88a802d2..8170e16f90 100644 --- a/detections/endpoint/getadcomputer_with_powershell_script_block.yml +++ b/detections/endpoint/getadcomputer_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: GetAdComputer with PowerShell Script Block id: a9a1da02-8e27-4bf7-a348-f4389c9da487 -version: 3 -date: '2022-05-02' +version: 4 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet - is used to return a list of all domain computers. Red Teams and adversaries may - leverage this commandlet to enumerate domain computers for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-AdComputer` + PowerShell commandlet using PowerShell Script Block Logging (EventCode=4104). This + detection leverages script block text to identify when this commandlet is run. The + `Get-AdComputer` commandlet is significant as it can be used by adversaries to enumerate + all domain computers, aiding in situational awareness and Active Directory discovery. + If confirmed malicious, this activity could allow attackers to map the network, + identify targets, and plan further attacks, potentially leading to unauthorized + access and data exfiltration. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-AdComputer*") | stats @@ -54,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getadgroup_with_powershell.yml b/detections/endpoint/getadgroup_with_powershell.yml index d167e30ba4..83900cb33a 100644 --- a/detections/endpoint/getadgroup_with_powershell.yml +++ b/detections/endpoint/getadgroup_with_powershell.yml @@ -1,15 +1,18 @@ name: GetAdGroup with PowerShell id: 872e3063-0fc4-4e68-b2f3-f2b99184a708 -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query for domain groups. The `Get-AdGroup` commandlnet is - used to return a list of all groups available in a Windows Domain. Red Teams and - adversaries alike may leverage this commandlet to enumerate domain groups for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + the `Get-AdGroup` commandlet, which is used to query domain groups in a Windows + Domain. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line arguments. Monitoring this activity + is crucial as it may indicate an adversary or Red Team enumerating domain groups + for situational awareness and Active Directory discovery. If confirmed malicious, + this activity could lead to further reconnaissance, privilege escalation, or lateral + movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getadgroup_with_powershell_script_block.yml b/detections/endpoint/getadgroup_with_powershell_script_block.yml index 0e0d212168..efa6aa9cd5 100644 --- a/detections/endpoint/getadgroup_with_powershell_script_block.yml +++ b/detections/endpoint/getadgroup_with_powershell_script_block.yml @@ -1,20 +1,23 @@ name: GetAdGroup with PowerShell Script Block id: e4c73d68-794b-468d-b4d0-dac1772bbae7 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet - is used to return a list of all domain groups. Red Teams and adversaries may leverage - this commandlet to enumerate domain groups for situational awareness and Active - Directory Discovery. +description: The following analytic detects the execution of the `Get-AdGroup` PowerShell + cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is used + to enumerate all domain groups, which adversaries may exploit for situational awareness + and Active Directory discovery. Monitoring this activity is crucial as it can indicate + reconnaissance efforts within the network. If confirmed malicious, this behavior + could lead to further exploitation, such as privilege escalation or lateral movement, + by providing attackers with detailed information about the domain's group structure. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-ADGroup*" | stats count - min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `getadgroup_with_powershell_script_block_filter`' + min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer + UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `getadgroup_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -53,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getcurrent_user_with_powershell.yml b/detections/endpoint/getcurrent_user_with_powershell.yml index e774a291ef..a3f858c269 100644 --- a/detections/endpoint/getcurrent_user_with_powershell.yml +++ b/detections/endpoint/getcurrent_user_with_powershell.yml @@ -1,15 +1,18 @@ name: GetCurrent User with PowerShell id: 7eb9c3d5-c98c-4088-acc5-8240bad15379 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powerhsell.exe` with command-line - arguments that execute the `GetCurrent` method of the WindowsIdentity .NET class. - This method returns an object that represents the current Windows user. Red Teams - and adversaries may leverage this method to identify the logged user on a compromised - endpoint for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments invoking the `GetCurrent` method of the WindowsIdentity .NET + class. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line executions. This activity is + significant as adversaries may use this method to identify the logged-in user on + a compromised endpoint, aiding in situational awareness and Active Directory discovery. + If confirmed malicious, this could allow attackers to gain insights into user context, + potentially facilitating further exploitation and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getcurrent_user_with_powershell_script_block.yml b/detections/endpoint/getcurrent_user_with_powershell_script_block.yml index dbde8ca93d..acd52a9f63 100644 --- a/detections/endpoint/getcurrent_user_with_powershell_script_block.yml +++ b/detections/endpoint/getcurrent_user_with_powershell_script_block.yml @@ -1,21 +1,25 @@ name: GetCurrent User with PowerShell Script Block id: 80879283-c30f-44f7-8471-d1381f6d437a -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-21' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `GetCurrent` method of the WindowsIdentity .NET - class. This method returns an object that represents the current Windows user. Red - Teams and adversaries may leverage this method to identify the logged user on a - compromised endpoint for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `GetCurrent` method + from the WindowsIdentity .NET class using PowerShell Script Block Logging (EventCode=4104). + This method identifies the current Windows user. The detection leverages PowerShell + script block logs to identify when this method is called. This activity is significant + because adversaries and Red Teams may use it to gain situational awareness and perform + Active Directory discovery on compromised endpoints. If confirmed malicious, this + could allow attackers to map out user accounts and potentially escalate privileges + or move laterally within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*[System.Security.Principal.WindowsIdentity]*" ScriptBlockText = "*GetCurrent()*" | stats count min(_time) as firstTime max(_time) as lastTime - by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `getcurrent_user_with_powershell_script_block_filter`' + by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as + user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `getcurrent_user_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -55,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaincomputer_with_powershell.yml b/detections/endpoint/getdomaincomputer_with_powershell.yml index 78b806359e..0dba51ad46 100644 --- a/detections/endpoint/getdomaincomputer_with_powershell.yml +++ b/detections/endpoint/getdomaincomputer_with_powershell.yml @@ -1,15 +1,18 @@ name: GetDomainComputer with PowerShell id: ed550c19-712e-43f6-bd19-6f58f61b3a5e -version: 1 -date: '2021-09-07' +version: 2 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to discover remote systems. `Get-DomainComputer` is part of PowerView, - a PowerShell tool used to perform enumeration on Windows domains. Red Teams and - adversaries alike may leverage PowerView to enumerate domain groups for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments that utilize `Get-DomainComputer` to discover remote systems. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions. This activity is significant + as `Get-DomainComputer` is part of PowerView, a tool often used by adversaries for + domain enumeration and situational awareness. If confirmed malicious, this activity + could allow attackers to map out the network, identify critical systems, and plan + further attacks, potentially leading to unauthorized access and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaincomputer_with_powershell_script_block.yml b/detections/endpoint/getdomaincomputer_with_powershell_script_block.yml index 634f8a3103..592155e6e4 100644 --- a/detections/endpoint/getdomaincomputer_with_powershell_script_block.yml +++ b/detections/endpoint/getdomaincomputer_with_powershell_script_block.yml @@ -1,20 +1,24 @@ name: GetDomainComputer with PowerShell Script Block id: f64da023-b988-4775-8d57-38e512beb56e -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainComputer` commandlet. `GetDomainComputer` - is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. - Red Teams and adversaries alike may use PowerView to enumerate domain computers - for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-DomainComputer` + commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet + is part of PowerView, a tool often used for enumerating domain computers within + Windows environments. The detection leverages script block text analysis to identify + this specific command. Monitoring this activity is crucial as it can indicate an + adversary's attempt to gather information about domain computers, which is a common + step in Active Directory reconnaissance. If confirmed malicious, this activity could + lead to further network enumeration and potential lateral movement within the domain. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainComputer*") | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID - EventCode ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `getdomaincomputer_with_powershell_script_block_filter`' + EventCode ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `getdomaincomputer_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -52,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaincontroller_with_powershell.yml b/detections/endpoint/getdomaincontroller_with_powershell.yml index 0b41e228ff..b1e963083d 100644 --- a/detections/endpoint/getdomaincontroller_with_powershell.yml +++ b/detections/endpoint/getdomaincontroller_with_powershell.yml @@ -1,15 +1,18 @@ name: GetDomainController with PowerShell id: 868ee0e4-52ab-484a-833a-6d85b7c028d0 -version: 1 -date: '2021-09-07' +version: 2 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to discover remote systems. `Get-DomainController` is part of - PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red - Teams and adversaries alike may leverage PowerView to enumerate domain groups for - situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + the `Get-DomainController` command, which is used to discover remote systems within + a Windows domain. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line arguments. Monitoring this + activity is crucial as it may indicate an attempt to enumerate domain controllers, + a common tactic in Active Directory discovery. If confirmed malicious, this activity + could allow attackers to gain situational awareness, potentially leading to further + exploitation and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaincontroller_with_powershell_script_block.yml b/detections/endpoint/getdomaincontroller_with_powershell_script_block.yml index 0d0b088aa4..47f1e5591c 100644 --- a/detections/endpoint/getdomaincontroller_with_powershell_script_block.yml +++ b/detections/endpoint/getdomaincontroller_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: GetDomainController with PowerShell Script Block id: 676b600a-a94d-4951-b346-11329431e6c1 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-13' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainController` commandlet. `Get-DomainController` - is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. - Red Teams and adversaries alike may use PowerView to enumerate domain computers - for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-DomainController` + commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet + is part of PowerView, a tool often used for domain enumeration. The detection leverages + script block text to identify this specific activity. Monitoring this behavior is + crucial as it may indicate an adversary or Red Team performing reconnaissance to + map out domain controllers. If confirmed malicious, this activity could lead to + further domain enumeration, potentially exposing sensitive information and aiding + in lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainController*") @@ -53,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getdc.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getdc.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaingroup_with_powershell.yml b/detections/endpoint/getdomaingroup_with_powershell.yml index 26a5a2de12..33f2b2f707 100644 --- a/detections/endpoint/getdomaingroup_with_powershell.yml +++ b/detections/endpoint/getdomaingroup_with_powershell.yml @@ -1,15 +1,19 @@ name: GetDomainGroup with PowerShell id: 93c94be3-bead-4a60-860f-77ca3fe59903 -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query for domain groups. `Get-DomainGroup` is part of PowerView, - a PowerShell tool used to perform enumeration on Windows domains. Red Teams and - adversaries alike may leverage PowerView to enumerate domain groups for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments that query for domain groups using `Get-DomainGroup`. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line executions mapped to the `Processes` node of the + `Endpoint` data model. Monitoring this activity is crucial as `Get-DomainGroup` + is part of PowerView, a tool often used by adversaries for domain enumeration and + situational awareness. If confirmed malicious, this activity could allow attackers + to gain insights into domain group structures, aiding in further exploitation and + privilege escalation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getdomaingroup_with_powershell_script_block.yml b/detections/endpoint/getdomaingroup_with_powershell_script_block.yml index a1c44feff9..d8c35b4d1d 100644 --- a/detections/endpoint/getdomaingroup_with_powershell_script_block.yml +++ b/detections/endpoint/getdomaingroup_with_powershell_script_block.yml @@ -1,16 +1,18 @@ name: GetDomainGroup with PowerShell Script Block id: 09725404-a44f-4ed3-9efa-8ed5d69e4c53 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainGroup` commandlet. `Get-DomainGroup` - is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. - As the name suggests, `Get-DomainGroup` is used to query domain groups. Red Teams - and adversaries may leverage this function to enumerate domain groups for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-DomainGroup` + cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet, part + of the PowerView tool, is used to enumerate domain groups within a Windows domain. + The detection leverages script block text to identify this specific command. Monitoring + this activity is crucial as it may indicate an adversary or Red Team performing + reconnaissance to gain situational awareness and map out Active Directory structures. + If confirmed malicious, this activity could lead to further exploitation, including + privilege escalation and lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainGroup*") | stats @@ -55,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domaingroup.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/domaingroup.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getlocaluser_with_powershell.yml b/detections/endpoint/getlocaluser_with_powershell.yml index 73d1071de9..16483c1c3c 100644 --- a/detections/endpoint/getlocaluser_with_powershell.yml +++ b/detections/endpoint/getlocaluser_with_powershell.yml @@ -1,14 +1,18 @@ name: GetLocalUser with PowerShell id: 85fae8fa-0427-11ec-8b78-acde48001122 -version: 1 -date: '2021-08-23' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query for local users. The `Get-LocalUser` commandlet is used - to return a list of all local users. Red Teams and adversaries may leverage this - commandlet to enumerate users for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + the `Get-LocalUser` commandlet, which is used to query local user accounts. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments. Monitoring this activity is significant + because adversaries and Red Teams may use it to enumerate local users for situational + awareness and Active Directory discovery. If confirmed malicious, this activity + could allow attackers to identify potential targets for further exploitation or + privilege escalation within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -56,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getlocaluser_with_powershell_script_block.yml b/detections/endpoint/getlocaluser_with_powershell_script_block.yml index 4d4e5db842..68d2f1f35c 100644 --- a/detections/endpoint/getlocaluser_with_powershell_script_block.yml +++ b/detections/endpoint/getlocaluser_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: GetLocalUser with PowerShell Script Block id: 2e891cbe-0426-11ec-9c9c-acde48001122 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-13' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-LocalUser` commandlet. The `Get-LocalUser` - commandlet is used to return a list of all local users. Red Teams and adversaries - may leverage this commandlet to enumerate users for situational awareness and Active - Directory Discovery. +description: The following analytic detects the execution of the `Get-LocalUser` PowerShell + commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet + lists all local users on a system. The detection leverages script block text from + PowerShell logs to identify this activity. Monitoring this behavior is significant + as adversaries and Red Teams may use it to enumerate local users for situational + awareness and Active Directory discovery. If confirmed malicious, this activity + could lead to further reconnaissance, enabling attackers to identify potential targets + for privilege escalation or lateral movement. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-LocalUser*") | stats @@ -56,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getnettcpconnection_with_powershell.yml b/detections/endpoint/getnettcpconnection_with_powershell.yml index 44232a4ca7..e10e64b62a 100644 --- a/detections/endpoint/getnettcpconnection_with_powershell.yml +++ b/detections/endpoint/getnettcpconnection_with_powershell.yml @@ -1,14 +1,18 @@ name: GetNetTcpconnection with PowerShell id: e02af35c-1de5-4afe-b4be-f45aba57272b -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-19' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - utilized to get a listing of network connections on a compromised system. The `Get-NetTcpConnection` - commandlet lists the current TCP connections. Red Teams and adversaries alike may - use this commandlet for situational awareness and Active Directory Discovery. +description: The following analytic identifies the execution of `powershell.exe` with + the `Get-NetTcpConnection` command, which lists current TCP connections on a system. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line executions. Monitoring this activity + is significant as it may indicate an adversary or Red Team performing network reconnaissance + or situational awareness. If confirmed malicious, this activity could allow attackers + to map network connections, aiding in lateral movement or further exploitation within + the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getnettcpconnection_with_powershell_script_block.yml b/detections/endpoint/getnettcpconnection_with_powershell_script_block.yml index f9b9eb41f2..1c27f7acfd 100644 --- a/detections/endpoint/getnettcpconnection_with_powershell_script_block.yml +++ b/detections/endpoint/getnettcpconnection_with_powershell_script_block.yml @@ -1,15 +1,18 @@ name: GetNetTcpconnection with PowerShell Script Block id: 091712ff-b02a-4d43-82ed-34765515d95d -version: 2 -date: '2022-04-02' +version: 3 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-NetTcpconnection ` commandlet. This commandlet - is used to return a listing of network connections on a compromised system. Red - Teams and adversaries alike may use this commandlet for situational awareness and - Active Directory Discovery. +description: The following analytic detects the execution of the `Get-NetTcpconnection` + PowerShell cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet + lists network connections on a system, which adversaries may use for situational + awareness and Active Directory discovery. Monitoring this activity is crucial as + it can indicate reconnaissance efforts by an attacker. If confirmed malicious, this + behavior could allow an attacker to map the network, identify critical systems, + and plan further attacks, potentially leading to data exfiltration or lateral movement + within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-NetTcpconnection*") @@ -53,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/nettcpconnection.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/nettcpconnection.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_computer_with_powershell.yml b/detections/endpoint/getwmiobject_ds_computer_with_powershell.yml index 3d3559fa7e..73de135fe8 100644 --- a/detections/endpoint/getwmiobject_ds_computer_with_powershell.yml +++ b/detections/endpoint/getwmiobject_ds_computer_with_powershell.yml @@ -1,15 +1,19 @@ name: GetWmiObject Ds Computer with PowerShell id: 7141122c-3bc2-4aaa-ab3b-7a85a0bbefc3 -version: 1 -date: '2021-09-07' +version: 2 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to discover remote systems. The `Get-WmiObject` commandlet combined - with the `DS_Computer` parameter can be used to return a list of all domain computers. - Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, - to enumerate domain groups for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments that utilize the `Get-WmiObject` cmdlet to discover remote + systems, specifically targeting the `DS_Computer` parameter. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant as it indicates potential + reconnaissance efforts by adversaries to enumerate domain computers and gather situational + awareness within Active Directory. If confirmed malicious, this behavior could allow + attackers to map the network, identify critical systems, and plan further attacks, + potentially leading to unauthorized access and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_computer_with_powershell_script_block.yml b/detections/endpoint/getwmiobject_ds_computer_with_powershell_script_block.yml index 6a586fc0e1..831c8bacc4 100644 --- a/detections/endpoint/getwmiobject_ds_computer_with_powershell_script_block.yml +++ b/detections/endpoint/getwmiobject_ds_computer_with_powershell_script_block.yml @@ -1,15 +1,17 @@ name: GetWmiObject Ds Computer with PowerShell Script Block id: 29b99201-723c-4118-847a-db2b3d3fb8ea -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-WmiObject` commandlet. The `DS_Computer` class - parameter leverages WMI to query for all domain computers. Red Teams and adversaries - may leverage this commandlet to enumerate domain computers for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-WmiObject` cmdlet + with the `DS_Computer` class parameter via PowerShell Script Block Logging (EventCode=4104). + This detection leverages script block text to identify queries targeting domain + computers using WMI. Monitoring this activity is crucial as adversaries and Red + Teams may use it for Active Directory Discovery and situational awareness. If confirmed + malicious, this behavior could allow attackers to map out domain computers, facilitating + further attacks such as lateral movement or privilege escalation. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText=*Get-WmiObject* AND ScriptBlockText="*namespace @@ -54,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_group_with_powershell.yml b/detections/endpoint/getwmiobject_ds_group_with_powershell.yml index 81e4dce647..f9dd5ae4a3 100644 --- a/detections/endpoint/getwmiobject_ds_group_with_powershell.yml +++ b/detections/endpoint/getwmiobject_ds_group_with_powershell.yml @@ -1,16 +1,18 @@ name: GetWmiObject Ds Group with PowerShell id: df275a44-4527-443b-b884-7600e066e3eb -version: 1 -date: '2021-08-25' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query for domain groups. The `Get-WmiObject` commandlet combined - with the `-class ds_group` parameter can be used to return the full list of groups - in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, - using PowerShell, to enumerate domain groups for situational awareness and Active - Directory Discovery. +description: The following analytic identifies the execution of `powershell.exe` with + command-line arguments used to query domain groups via the `Get-WmiObject` cmdlet + and the `-class ds_group` parameter. This detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as it indicates potential reconnaissance + efforts by adversaries to enumerate domain groups, which is a common step in Active + Directory Discovery. If confirmed malicious, this could allow attackers to gain + insights into the domain structure, aiding in further attacks and privilege escalation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_group_with_powershell_script_block.yml b/detections/endpoint/getwmiobject_ds_group_with_powershell_script_block.yml index e2830e3e04..534309df72 100644 --- a/detections/endpoint/getwmiobject_ds_group_with_powershell_script_block.yml +++ b/detections/endpoint/getwmiobject_ds_group_with_powershell_script_block.yml @@ -1,21 +1,24 @@ name: GetWmiObject Ds Group with PowerShell Script Block id: 67740bd3-1506-469c-b91d-effc322cc6e5 -version: 2 -date: '2022-05-02' +version: 3 +date: '2024-05-18' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-WmiObject` commandlet used with specific parameters - . The `DS_Group` parameter leverages WMI to query for all domain groups. Red Teams - and adversaries may leverage this commandlet to enumerate domain groups for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-WmiObject` commandlet + with the `DS_Group` parameter via PowerShell Script Block Logging (EventCode=4104). + This method leverages WMI to query all domain groups. Monitoring this activity is + crucial as adversaries and Red Teams may use it for domain group enumeration, aiding + in situational awareness and Active Directory discovery. If confirmed malicious, + this activity could allow attackers to map out the domain structure, potentially + leading to further exploitation and privilege escalation within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText=*Get-WmiObject* AND ScriptBlockText="*namespace root\\directory\\ldap*" AND ScriptBlockText="*class ds_group*") | stats count min(_time) - as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`|`getwmiobject_ds_group_with_powershell_script_block_filter`' + as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText + | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)`|`getwmiobject_ds_group_with_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -55,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_user_with_powershell.yml b/detections/endpoint/getwmiobject_ds_user_with_powershell.yml index 72a1b0a7d9..5ede6227b8 100644 --- a/detections/endpoint/getwmiobject_ds_user_with_powershell.yml +++ b/detections/endpoint/getwmiobject_ds_user_with_powershell.yml @@ -1,16 +1,18 @@ name: GetWmiObject DS User with PowerShell id: 22d3b118-04df-11ec-8fa3-acde48001122 -version: 1 -date: '2021-08-24' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query for domain users. The `Get-WmiObject` commandlet combined - with the `-class ds_user` parameter can be used to return the full list of users - in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, - using PowerShell, to enumerate domain users for situational awareness and Active - Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments used to query domain users via the `Get-WmiObject` cmdlet + and `-class ds_user` parameter. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line executions. + This activity is significant as it indicates potential reconnaissance efforts by + adversaries to enumerate domain users, which is a common step in Active Directory + Discovery. If confirmed malicious, this could lead to further attacks, including + privilege escalation and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_ds_user_with_powershell_script_block.yml b/detections/endpoint/getwmiobject_ds_user_with_powershell_script_block.yml index 228fee7108..fbecd4cc1c 100644 --- a/detections/endpoint/getwmiobject_ds_user_with_powershell_script_block.yml +++ b/detections/endpoint/getwmiobject_ds_user_with_powershell_script_block.yml @@ -1,22 +1,25 @@ name: GetWmiObject DS User with PowerShell Script Block id: fabd364e-04f3-11ec-b34b-acde48001122 -version: 3 -date: '2023-11-07' +version: 4 +date: '2024-05-11' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-WmiObject` commandlet. The `DS_User` class - parameter leverages WMI to query for all domain users. Red Teams and adversaries - may leverage this commandlet to enumerate domain users for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-WmiObject` cmdlet + with the `DS_User` class parameter via PowerShell Script Block Logging (EventCode=4104). + It leverages logs to identify attempts to query all domain users using WMI. This + activity is significant as it may indicate an adversary or Red Team operation attempting + to enumerate domain users for situational awareness and Active Directory discovery. + If confirmed malicious, this behavior could lead to further reconnaissance, enabling + attackers to map out the network and identify potential targets for privilege escalation + or lateral movement. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-wmiobject*" ScriptBlockText = "*ds_user*" ScriptBlockText = "*-namespace*" ScriptBlockText = "*root\\directory\\ldap*" | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer - UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `getwmiobject_ds_user_with_powershell_script_block_filter`' + UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user| + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `getwmiobject_ds_user_with_powershell_script_block_filter`' how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. @@ -30,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: powershell process having commandline for user enumeration detected on host - $dest$ + message: powershell process having commandline for user enumeration detected on + host - $dest$ mitre_attack_id: - T1087.002 - T1087 @@ -59,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_user_account_with_powershell.yml b/detections/endpoint/getwmiobject_user_account_with_powershell.yml index 23d0d67cdd..ec1580ffee 100644 --- a/detections/endpoint/getwmiobject_user_account_with_powershell.yml +++ b/detections/endpoint/getwmiobject_user_account_with_powershell.yml @@ -1,15 +1,18 @@ name: GetWmiObject User Account with PowerShell id: b44f6ac6-0429-11ec-87e9-acde48001122 -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-22' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments utilized to query local users. The `Get-WmiObject` commandlet combined - with the `Win32_UserAccount` parameter is used to return a list of all local users. - Red Teams and adversaries may leverage this commandlet to enumerate users for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments that utilize the `Get-WmiObject` cmdlet and the `Win32_UserAccount` + parameter to query local user accounts. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line executions. + This activity is significant as it may indicate an attempt by adversaries to enumerate + user accounts for situational awareness or Active Directory discovery. If confirmed + malicious, this behavior could lead to further reconnaissance, privilege escalation, + or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -58,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/getwmiobject_user_account_with_powershell_script_block.yml b/detections/endpoint/getwmiobject_user_account_with_powershell_script_block.yml index 4be58a824c..f2d0eeb8bd 100644 --- a/detections/endpoint/getwmiobject_user_account_with_powershell_script_block.yml +++ b/detections/endpoint/getwmiobject_user_account_with_powershell_script_block.yml @@ -1,15 +1,17 @@ name: GetWmiObject User Account with PowerShell Script Block id: 640b0eda-0429-11ec-accd-acde48001122 -version: 2 -date: '2023-04-05' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-WmiObject` commandlet used with specific parameters. - The `Win32_UserAccount` parameter is used to return a list of all local users. Red - Teams and adversaries may leverage this commandlet to enumerate users for situational - awareness and Active Directory Discovery. +description: The following analytic detects the execution of the `Get-WmiObject` commandlet + with the `Win32_UserAccount` parameter via PowerShell Script Block Logging (EventCode=4104). + This method leverages script block text to identify when a list of all local users + is being enumerated. This activity is significant as it may indicate an adversary + or Red Team operation attempting to gather user information for situational awareness + and Active Directory discovery. If confirmed malicious, this could lead to further + reconnaissance, privilege escalation, or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText="*Get-WmiObject*" AND ScriptBlockText="*Win32_UserAccount*") @@ -56,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/gpupdate_with_no_command_line_arguments_with_network.yml b/detections/endpoint/gpupdate_with_no_command_line_arguments_with_network.yml index 78091b1833..d79351156a 100644 --- a/detections/endpoint/gpupdate_with_no_command_line_arguments_with_network.yml +++ b/detections/endpoint/gpupdate_with_no_command_line_arguments_with_network.yml @@ -1,28 +1,31 @@ name: GPUpdate with no Command Line Arguments with Network id: 2c853856-a140-11eb-a5b5-acde48001122 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies gpupdate.exe with no command line arguments - and with a network connection. It is unusual for gpupdate.exe to execute with no - command line arguments present. This particular behavior is common with malicious - software, including Cobalt Strike. During investigation, triage any network connections - and parallel processes. Identify any suspicious module loads related to credential - dumping or file writes. gpupdate.exe is natively found in C:\Windows\system32 and - C:\Windows\syswow64. +description: The following analytic detects the execution of gpupdate.exe without + command line arguments and with an active network connection. This behavior is identified + using Endpoint Detection and Response (EDR) telemetry, focusing on process execution + and network traffic data. It is significant because gpupdate.exe typically runs + with specific arguments, and its execution without them, especially with network + activity, is often associated with malicious software like Cobalt Strike. If confirmed + malicious, this activity could indicate an attacker leveraging gpupdate.exe for + lateral movement, command and control, or other nefarious purposes, potentially + leading to system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name=gpupdate.exe by _time span=1h Processes.process_id - Processes.process_name Processes.dest Processes.user Processes.process_path Processes.process Processes.parent_process_name - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | regex process="(?i)(gpupdate\.exe.{0,4}$)"| join process_id [| tstats `security_content_summariesonly` - count FROM datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port != - 0 by All_Traffic.process_id All_Traffic.dest All_Traffic.dest_port | `drop_dm_object_name(All_Traffic)` - | rename dest as C2 ] | table _time user dest parent_process_name process_name process_path - process process_id dest_port C2 | `gpupdate_with_no_command_line_arguments_with_network_filter`' + Processes.process_name Processes.dest Processes.user Processes.process_path Processes.process + Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | regex process="(?i)(gpupdate\.exe.{0,4}$)"| + join process_id [| tstats `security_content_summariesonly` count FROM datamodel=Network_Traffic.All_Traffic + where All_Traffic.dest_port != 0 by All_Traffic.process_id All_Traffic.dest All_Traffic.dest_port + | `drop_dm_object_name(All_Traffic)` | rename dest as C2 ] | table _time user dest + parent_process_name process_name process_path process process_id dest_port C2 | + `gpupdate_with_no_command_line_arguments_with_network_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -46,8 +49,8 @@ tags: confidence: 90 impact: 90 message: Process gpupdate.exe with parent_process $parent_process_name$ is executed - on $dest$ by user $user$, followed by an outbound network connection to $C2$ - on port $dest_port$. This behaviour is seen with cobaltstrike. + on $dest$ by user $user$, followed by an outbound network connection to $C2$ on + port $dest_port$. This behaviour is seen with cobaltstrike. mitre_attack_id: - T1055 observable: @@ -85,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/headless_browser_mockbin_or_mocky_request.yml b/detections/endpoint/headless_browser_mockbin_or_mocky_request.yml index 0d6227215f..eac39a1875 100644 --- a/detections/endpoint/headless_browser_mockbin_or_mocky_request.yml +++ b/detections/endpoint/headless_browser_mockbin_or_mocky_request.yml @@ -1,20 +1,34 @@ name: Headless Browser Mockbin or Mocky Request id: 94fc85a1-e55b-4265-95e1-4b66730e05c0 -version: 1 -date: '2023-09-11' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies headless browser activity accessing mockbin.org or mocky.io. Mockbin.org and mocky.io are web services that allow users to mock HTTP requests and responses. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing and the presence of mockbin.org or mocky.io in the process. +description: The following analytic detects headless browser activity accessing mockbin.org + or mocky.io. It identifies processes with the "--headless" and "--disable-gpu" command + line arguments, along with references to mockbin.org or mocky.io. This behavior + is significant as headless browsers are often used for automated tasks, including + malicious activities like web scraping or automated attacks. If confirmed malicious, + this activity could indicate an attempt to bypass traditional browser security measures, + potentially leading to data exfiltration or further exploitation of web applications. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where - (Processes.process="*--headless*" AND Processes.process="*--disable-gpu*" AND (Processes.process="*mockbin.org/*" OR Processes.process="*mocky.io/*")) by Processes.dest Processes.user Processes.parent_process + as lastTime from datamodel=Endpoint.Processes where (Processes.process="*--headless*" + AND Processes.process="*--disable-gpu*" AND (Processes.process="*mockbin.org/*" + OR Processes.process="*mocky.io/*")) by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `headless_browser_mockbin_or_mocky_request_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: False positives are not expected with this detection, unless within the organization there is a legitimate need for headless browsing accessing mockbin.org or mocky.io. + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `headless_browser_mockbin_or_mocky_request_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: False positives are not expected with this detection, unless + within the organization there is a legitimate need for headless browsing accessing + mockbin.org or mocky.io. references: - https://mockbin.org/ - https://www.mocky.io/ @@ -25,7 +39,8 @@ tags: atomic_guid: [] confidence: 70 impact: 80 - message: Headless browser activity accessing mockbin.org or mocky.io detected on $dest$ by $user$. + message: Headless browser activity accessing mockbin.org or mocky.io detected on + $dest$ by $user$. mitre_attack_id: - T1564.003 observable: @@ -54,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/headlessbrowser/headless_mockbin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/headlessbrowser/headless_mockbin.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/headless_browser_usage.yml b/detections/endpoint/headless_browser_usage.yml index 2e22b34fa0..c81b4af1fc 100644 --- a/detections/endpoint/headless_browser_usage.yml +++ b/detections/endpoint/headless_browser_usage.yml @@ -1,20 +1,34 @@ name: Headless Browser Usage id: 869ba261-c272-47d7-affe-5c0aa85c93d6 -version: 1 -date: '2023-09-08' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: Hunting data_source: - Sysmon EventID 1 -description: 'The following hunting analytic is designed to detect the usage of headless browsers in an organization. Headless browsers are web browsers without a graphical user interface and are operated via a command line interface or network requests. They are often used for automating tasks but can also be utilized by adversaries for malicious activities such as web scraping, automated testing, and performing actions on web pages without detection. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing.' +description: 'The following analytic detects the usage of headless browsers within + an organization. It identifies processes containing the "--headless" and "--disable-gpu" + command line arguments, which are indicative of headless browsing. This detection + leverages data from the Endpoint.Processes datamodel to identify such processes. + Monitoring headless browser usage is significant as these tools can be exploited + by adversaries for malicious activities like web scraping, automated testing, and + undetected web interactions. If confirmed malicious, this activity could lead to + unauthorized data extraction, automated attacks, or other covert operations on web + applications.' search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where - (Processes.process="*--headless*" AND Processes.process="*--disable-gpu*") by Processes.dest Processes.user Processes.parent_process + as lastTime from datamodel=Endpoint.Processes where (Processes.process="*--headless*" + AND Processes.process="*--disable-gpu*") by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `headless_browser_usage_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: This hunting analytic is meant to assist with baselining and understanding headless browsing in use. Filter as needed. + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `headless_browser_usage_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: This hunting analytic is meant to assist with baselining and + understanding headless browsing in use. Filter as needed. references: - https://cert.gov.ua/article/5702579 tags: @@ -54,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/headlessbrowser/headless_mockbin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/headlessbrowser/headless_mockbin.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/hide_user_account_from_sign_in_screen.yml b/detections/endpoint/hide_user_account_from_sign_in_screen.yml index 3dc6858675..69341e54f5 100644 --- a/detections/endpoint/hide_user_account_from_sign_in_screen.yml +++ b/detections/endpoint/hide_user_account_from_sign_in_screen.yml @@ -1,24 +1,28 @@ name: Hide User Account From Sign-In Screen id: 834ba832-ad89-11eb-937d-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-17' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies a suspicious registry modification to hide a - user account on the Windows Login screen. This technique was seen in some tradecraft - where the adversary will create a hidden user account with Admin privileges in login - screen to avoid noticing by the user that they already compromise and to persist - on that said machine. +description: The following analytic detects a suspicious registry modification that + hides a user account from the Windows Login screen. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path "*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" + with a value of "0x00000000". This activity is significant as it may indicate an + adversary attempting to create a hidden admin account to avoid detection and maintain + persistence on the compromised machine. If confirmed malicious, this could allow + the attacker to maintain undetected access and control over the system, posing a + severe security risk. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" - AND Registry.registry_value_data = "0x00000000") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data - Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `hide_user_account_from_sign_in_screen_filter`' + AND Registry.registry_value_data = "0x00000000") BY _time span=1h Registry.dest + Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` + | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `hide_user_account_from_sign_in_screen_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -71,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/hotkey_disabled_hidden_user/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/hotkey_disabled_hidden_user/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/hiding_files_and_directories_with_attrib_exe.yml b/detections/endpoint/hiding_files_and_directories_with_attrib_exe.yml index b8ab08fa9d..14fa643a85 100644 --- a/detections/endpoint/hiding_files_and_directories_with_attrib_exe.yml +++ b/detections/endpoint/hiding_files_and_directories_with_attrib_exe.yml @@ -1,21 +1,25 @@ name: Hiding Files And Directories With Attrib exe id: 6e5a3ae4-90a3-462d-9aa6-0119f638c0f1 -version: 5 -date: '2024-01-01' +version: 6 +date: '2024-05-13' author: Bhavin Patel, Splunk status: production type: TTP -description: Attackers leverage an existing Windows binary, attrib.exe, to mark specific - as hidden by using specific flags so that the victim does not see the file. The - search looks for specific command-line arguments to detect the use of attrib.exe - to hide files. +description: The following analytic detects the use of the Windows binary attrib.exe + to hide files or directories by marking them with specific flags. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments + that include the "+h" flag. This activity is significant because hiding files can + be a tactic used by attackers to conceal malicious files or tools from users and + security software. If confirmed malicious, this behavior could allow an attacker + to persist in the environment undetected, potentially leading to further compromise + or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) values(Processes.process) as process max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=attrib.exe - (Processes.process=*+h*) by Processes.parent_process_name Processes.process_name Processes.user - Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)`| - `hiding_files_and_directories_with_attrib_exe_filter` ' + (Processes.process=*+h*) by Processes.parent_process_name Processes.process_name + Processes.user Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` + |`hiding_files_and_directories_with_attrib_exe_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1222.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1222.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/high_frequency_copy_of_files_in_network_share.yml b/detections/endpoint/high_frequency_copy_of_files_in_network_share.yml index 45b2c13a75..0918d8df50 100644 --- a/detections/endpoint/high_frequency_copy_of_files_in_network_share.yml +++ b/detections/endpoint/high_frequency_copy_of_files_in_network_share.yml @@ -1,27 +1,32 @@ name: High Frequency Copy Of Files In Network Share id: 40925f12-4709-11ec-bb43-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious high frequency copying/moving - of files in network share as part of information sabotage. This anomaly event can - be a good indicator of insider trying to sabotage data by transfering classified - or internal files within network share to exfitrate it after or to lure evidence - of insider attack to other user. This behavior may catch several noise if network - share is a common place for classified or internal document processing. +description: The following analytic detects a high frequency of file copying or moving + within network shares, which may indicate potential data sabotage or exfiltration + attempts. It leverages Windows Security Event Logs (EventCode 5145) to monitor access + to specific file types and network shares. This activity is significant as it can + reveal insider threats attempting to transfer classified or internal files, potentially + leading to data breaches or evidence tampering. If confirmed malicious, this behavior + could result in unauthorized data access, data loss, or compromised sensitive information. data_source: - Windows Event Log Security 5145 -search: '`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.doc","*.docx","*.xls","*.xlsx","*.ppt","*.pptx","*.log","*.txt","*.db","*.7z","*.zip","*.rar","*.tar","*.gz","*.jpg","*.gif","*.png","*.bmp","*.pdf","*.rtf","*.key") ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$") AccessMask= "0x2" | bucket _time span=5m - | stats values(RelativeTargetName) as valRelativeTargetName, values(ShareName) as valShareName, values(ObjectType) as valObjectType, values(AccessMask) as valAccessmask, values(src_port) as valSrcPort, values(SourceAddress) as valSrcAddress count as numShareName by dest, _time, EventCode, src_user, src_ip - | eventstats avg(numShareName) as avgShareName, stdev(numShareName) as stdShareName, count as numSlots by dest, _time, EventCode, src_user - | eval upperThreshold=(avgShareName + stdShareName *3) - | eval isOutlier=if(avgShareName > 20 and avgShareName >= upperThreshold, 1, 0) +search: '`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.doc","*.docx","*.xls","*.xlsx","*.ppt","*.pptx","*.log","*.txt","*.db","*.7z","*.zip","*.rar","*.tar","*.gz","*.jpg","*.gif","*.png","*.bmp","*.pdf","*.rtf","*.key") + ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$") AccessMask= + "0x2" | bucket _time span=5m | stats values(RelativeTargetName) as valRelativeTargetName, + values(ShareName) as valShareName, values(ObjectType) as valObjectType, values(AccessMask) + as valAccessmask, values(src_port) as valSrcPort, values(SourceAddress) as valSrcAddress + count as numShareName by dest, _time, EventCode, src_user, src_ip | eventstats avg(numShareName) + as avgShareName, stdev(numShareName) as stdShareName, count as numSlots by dest, + _time, EventCode, src_user | eval upperThreshold=(avgShareName + stdShareName *3) + | eval isOutlier=if(avgShareName > 20 and avgShareName >= upperThreshold, 1, 0) | search isOutlier=1 | `high_frequency_copy_of_files_in_network_share_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting Windows - Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. - Also enable the object Audit access success/failure in your group policy. +how_to_implement: To successfully implement this search, you need to be ingesting + Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also + required. Also enable the object Audit access success/failure in your group policy. known_false_positives: This behavior may seen in normal transfer of file within network if network share is common place for sharing documents. references: @@ -64,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/high_frequency_copy_of_files_in_network_share/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1537/high_frequency_copy_of_files_in_network_share/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/high_process_termination_frequency.yml b/detections/endpoint/high_process_termination_frequency.yml index 1ccc6b5ac9..b70fe60b7e 100644 --- a/detections/endpoint/high_process_termination_frequency.yml +++ b/detections/endpoint/high_process_termination_frequency.yml @@ -1,20 +1,22 @@ name: High Process Termination Frequency id: 17cd75b2-8666-11eb-9ab4-acde48001122 -version: 2 -date: '2022-09-14' +version: 3 +date: '2024-05-12' author: Teoderick Contreras status: production type: Anomaly -description: This analytic is designed to identify a high frequency of process termination - events on a computer in a short period of time, which is a common behavior of ransomware - malware before encrypting files. This technique is designed to avoid an exception - error while accessing (docs, images, database and etc..) in the infected machine - for encryption. +description: The following analytic identifies a high frequency of process termination + events on a computer within a short period. It leverages Sysmon EventCode 5 logs + to detect instances where 15 or more processes are terminated within a 3-second + window. This behavior is significant as it is commonly associated with ransomware + attempting to avoid exceptions during file encryption. If confirmed malicious, this + activity could indicate an active ransomware attack, potentially leading to widespread + file encryption and significant data loss. data_source: - Sysmon EventID 5 search: '`sysmon` EventCode=5 |bin _time span=3s |stats values(Image) as proc_terminated - min(_time) as firstTime max(_time) as lastTime count by _time dest EventCode - ProcessID | where count >= 15 | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` + min(_time) as firstTime max(_time) as lastTime count by _time dest EventCode ProcessID + | where count >= 15 | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `high_process_termination_frequency_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Image (process full path of terminated process) from your endpoints. @@ -61,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/hunting_3cxdesktopapp_software.yml b/detections/endpoint/hunting_3cxdesktopapp_software.yml index f93240b57f..73a147297d 100644 --- a/detections/endpoint/hunting_3cxdesktopapp_software.yml +++ b/detections/endpoint/hunting_3cxdesktopapp_software.yml @@ -1,18 +1,19 @@ name: Hunting 3CXDesktopApp Software id: 553d0429-1a1c-44bf-b3f5-a8513deb9ee5 -version: 1 -date: '2023-03-30' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk type: Hunting status: production data_source: - Sysmon EventID 1 -description: The hunting analytic outlined below is designed to detect any version - of the 3CXDesktopApp, also known as the 3CX Desktop App, operating on either Mac - or Windows systems. It is important to note that this particular analytic employs - the Endpoint datamodel Processes node, which means that the file version information - is not provided. Recently, 3CX has identified a vulnerability specifically in versions - 18.12.407 and 18.12.416 of the desktop app. +description: The following analytic detects the presence of any version of the 3CXDesktopApp, + also known as the 3CX Desktop App, on Mac or Windows systems. It leverages the Endpoint + data model's Processes node to identify instances of the application running, although + it does not provide file version information. This activity is significant because + 3CX has identified vulnerabilities in versions 18.12.407 and 18.12.416, which could + be exploited by attackers. If confirmed malicious, this could lead to unauthorized + access, data exfiltration, or further compromise of the affected systems. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=3CXDesktopApp.exe OR Processes.process_name="3CX Desktop App" by Processes.dest Processes.user Processes.parent_process_name @@ -79,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.002/3CX/3cx_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.002/3CX/3cx_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/icacls_deny_command.yml b/detections/endpoint/icacls_deny_command.yml index 827ba5f4df..439ab93512 100644 --- a/detections/endpoint/icacls_deny_command.yml +++ b/detections/endpoint/icacls_deny_command.yml @@ -1,17 +1,18 @@ name: Icacls Deny Command id: cf8d753e-a8fe-11eb-8f58-acde48001122 -version: 1 -date: '2023-06-06' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies instances where an adversary modifies the security - permissions of a particular file or directory. This technique is frequently observed - in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. The - purpose of this behavior is to actively evade detection and impede access to their - associated files. By identifying these security permission changes, we can enhance - our ability to detect and respond to potential threats, mitigating the impact of - malicious activities on the system. +description: The following analytic detects instances where an adversary modifies + security permissions of a file or directory using commands like "icacls.exe", "cacls.exe", + or "xcacls.exe" with deny options. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process names and command-line executions. This + activity is significant as it is commonly used by Advanced Persistent Threats (APTs) + and coinminer scripts to evade detection and impede access to critical files. If + confirmed malicious, this could allow attackers to maintain persistence and hinder + incident response efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) @@ -71,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/icacls_grant_command.yml b/detections/endpoint/icacls_grant_command.yml index 851b6feb11..a3fac0b278 100644 --- a/detections/endpoint/icacls_grant_command.yml +++ b/detections/endpoint/icacls_grant_command.yml @@ -1,18 +1,18 @@ name: ICACLS Grant Command id: b1b1e316-accc-11eb-a9b4-acde48001122 -version: 1 -date: '2023-06-06' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies adversaries who manipulate the security permissions - of specific files or directories by granting additional access. This technique is - frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and - coinminer scripts. The objective behind this behavior is to actively evade detection - mechanisms and tightly control access to their associated files. By identifying - these security permission modifications, we can improve our ability to identify - and respond to potential threats, thereby minimizing the impact of malicious activities - on the system. +description: The following analytic detects the use of the ICACLS command to grant + additional access permissions to files or directories. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on specific process names and command-line + arguments. This activity is significant because it is commonly used by Advanced + Persistent Threats (APTs) and coinminer scripts to evade detection and maintain + control over compromised systems. If confirmed malicious, this behavior could allow + attackers to manipulate file permissions, potentially leading to unauthorized access, + data exfiltration, or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) @@ -70,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/impacket_lateral_movement_commandline_parameters.yml b/detections/endpoint/impacket_lateral_movement_commandline_parameters.yml index b5c2994bdb..4f1f6c8e85 100644 --- a/detections/endpoint/impacket_lateral_movement_commandline_parameters.yml +++ b/detections/endpoint/impacket_lateral_movement_commandline_parameters.yml @@ -1,18 +1,19 @@ name: Impacket Lateral Movement Commandline Parameters id: 8ce07472-496f-11ec-ab3b-3e22fbd008af -version: 3 -date: '2023-06-13' +version: 4 +date: '2024-05-30' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the presence of suspicious commandline parameters - typically present when using Impacket tools. Impacket is a collection of python - classes meant to be used with Microsoft network protocols. There are multiple scripts - that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` - and `atexec.py` used to execute commands on remote endpoints. By default, these - scripts leverage administrative shares and hardcoded parameters that can be used - as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets - tools for lateral movement and remote code execution. +description: The following analytic identifies the use of suspicious command-line + parameters associated with Impacket tools, such as `wmiexec.py`, `smbexec.py`, `dcomexec.py`, + and `atexec.py`, which are used for lateral movement and remote code execution. + It detects these activities by analyzing process execution logs from Endpoint Detection + and Response (EDR) agents, focusing on specific command-line patterns. This activity + is significant because Impacket tools are commonly used by adversaries and Red Teams + to move laterally within a network. If confirmed malicious, this could allow attackers + to execute commands remotely, potentially leading to further compromise and data + exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/impacket/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/impacket/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/impacket_lateral_movement_smbexec_commandline_parameters.yml b/detections/endpoint/impacket_lateral_movement_smbexec_commandline_parameters.yml index ffe6f5b5b7..bfd9ce7673 100644 --- a/detections/endpoint/impacket_lateral_movement_smbexec_commandline_parameters.yml +++ b/detections/endpoint/impacket_lateral_movement_smbexec_commandline_parameters.yml @@ -1,22 +1,20 @@ name: Impacket Lateral Movement smbexec CommandLine Parameters id: bb3c1bac-6bdf-4aa0-8dc9-068b8b712a76 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This analytic focuses on identifying suspicious command-line parameters - commonly associated with the use of Impacket wmiexec.py. Impacket is a set of Python - classes designed for working with Microsoft network protocols, and it includes several - scripts like wmiexec.py, smbexec.py, dcomexec.py, and atexec.py that enable command - execution on remote endpoints. These scripts typically utilize administrative shares - and hardcoded parameters, which can serve as signatures to detect their usage. Both - Red Teams and adversaries may employ Impacket tools for lateral movement and remote - code execution purposes. By monitoring for these specific command-line indicators, - the analytic aims to detect potentially malicious activities related to Impacket - tool usage. +description: The following analytic identifies suspicious command-line parameters + associated with the use of Impacket's smbexec.py for lateral movement. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line + patterns indicative of Impacket tool usage. This activity is significant as both + Red Teams and adversaries use Impacket for remote code execution and lateral movement. + If confirmed malicious, this activity could allow attackers to execute commands + on remote endpoints, potentially leading to unauthorized access, data exfiltration, + or further compromise of the network. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=cmd.exe by Processes.dest Processes.user Processes.parent_process_name Processes.process_name @@ -91,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/smbexec_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/smbexec_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/impacket_lateral_movement_wmiexec_commandline_parameters.yml b/detections/endpoint/impacket_lateral_movement_wmiexec_commandline_parameters.yml index cf2ae7a64a..974ea619a2 100644 --- a/detections/endpoint/impacket_lateral_movement_wmiexec_commandline_parameters.yml +++ b/detections/endpoint/impacket_lateral_movement_wmiexec_commandline_parameters.yml @@ -1,20 +1,20 @@ name: Impacket Lateral Movement WMIExec Commandline Parameters id: d6e464e4-5c6a-474e-82d2-aed616a3a492 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This analytic looks for the presence of suspicious commandline parameters - typically present when using Impacket tools. Impacket is a collection of python - classes meant to be used with Microsoft network protocols. There are multiple scripts - that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` - and `atexec.py` used to execute commands on remote endpoints. By default, these - scripts leverage administrative shares and hardcoded parameters that can be used - as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets - tools for lateral movement and remote code execution. +description: The following analytic detects the use of Impacket's `wmiexec.py` tool + for lateral movement by identifying specific command-line parameters. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on processes spawned + by `wmiprvse.exe` with command-line patterns indicative of Impacket usage. This + activity is significant as Impacket tools are commonly used by adversaries for remote + code execution and lateral movement within a network. If confirmed malicious, this + could allow attackers to execute arbitrary commands on remote systems, potentially + leading to further compromise and data exfiltration. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=wmiprvse.exe by Processes.dest Processes.user Processes.parent_process_name Processes.process_name @@ -88,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/wmiexec_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.002/atomic_red_team/wmiexec_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/interactive_session_on_remote_endpoint_with_powershell.yml b/detections/endpoint/interactive_session_on_remote_endpoint_with_powershell.yml index efa1b463dd..ef6c6e6352 100644 --- a/detections/endpoint/interactive_session_on_remote_endpoint_with_powershell.yml +++ b/detections/endpoint/interactive_session_on_remote_endpoint_with_powershell.yml @@ -1,24 +1,28 @@ name: Interactive Session on Remote Endpoint with PowerShell id: a4e8f3a4-48b2-11ec-bcfc-3e22fbd008af -version: 4 -date: '2023-11-07' +version: 5 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the usage of the `Enter-PSSession`. This commandlet can be used to open - an interactive session on a remote endpoint leveraging the WinRM protocol. Red Teams - and adversaries alike may abuse WinRM and `Enter-PSSession` for lateral movement - and remote code execution. +description: The following analytic detects the use of the `Enter-PSSession` cmdlet + to establish an interactive session on a remote endpoint via the WinRM protocol. + It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity + by searching for specific script block text patterns. This behavior is significant + as it may indicate lateral movement or remote code execution attempts by adversaries. + If confirmed malicious, this activity could allow attackers to execute commands + remotely, potentially leading to further compromise of the network and unauthorized + access to sensitive information. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText="*Enter-PSSession*" AND ScriptBlockText="*-ComputerName*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `interactive_session_on_remote_endpoint_with_powershell_filter`' + Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `interactive_session_on_remote_endpoint_with_powershell_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions - can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + can be found + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: Administrators may leverage WinRM and `Enter-PSSession` for administrative and troubleshooting tasks. This activity is usually limited to a small set of hosts or users. In certain environments, tuning may not be possible. @@ -55,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_pssession/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_pssession/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/java_class_file_download_by_java_user_agent.yml b/detections/endpoint/java_class_file_download_by_java_user_agent.yml index a567667ec0..77213e3c78 100644 --- a/detections/endpoint/java_class_file_download_by_java_user_agent.yml +++ b/detections/endpoint/java_class_file_download_by_java_user_agent.yml @@ -1,14 +1,17 @@ name: Java Class File download by Java User Agent id: 8281ce42-5c50-11ec-82d2-acde48001122 -version: 1 -date: '2021-12-13' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP description: The following analytic identifies a Java user agent performing a GET - request for a .class file from the remote site. This is potentially indicative of - exploitation of the Java application and may be related to current event CVE-2021-44228 - (Log4Shell). + request for a .class file from a remote site. It leverages web or proxy logs within + the Web Datamodel to detect this activity. This behavior is significant as it may + indicate exploitation attempts, such as those related to CVE-2021-44228 (Log4Shell). + If confirmed malicious, an attacker could exploit vulnerabilities in the Java application, + potentially leading to remote code execution and further compromise of the affected + system. data_source: - Splunk Stream HTTP search: '| tstats count from datamodel=Web where Web.http_user_agent="*Java*" Web.http_method="GET" @@ -64,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/java.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/java.log source: stream:http sourcetype: stream:http diff --git a/detections/endpoint/java_writing_jsp_file.yml b/detections/endpoint/java_writing_jsp_file.yml index 20a8f55311..ec20cfe789 100644 --- a/detections/endpoint/java_writing_jsp_file.yml +++ b/detections/endpoint/java_writing_jsp_file.yml @@ -1,14 +1,17 @@ name: Java Writing JSP File id: eb65619c-4f8d-4383-a975-d352765d344b -version: 2 -date: '2022-06-03' +version: 3 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the process java writing a .jsp to - disk. This is potentially indicative of a web shell being written to disk. Modify - and tune the analytic based on data ingested. For instance, it may be worth running - a broad query for jsp file writes first before performing a join. +description: The following analytic detects the Java process writing a .jsp file to + disk, which may indicate a web shell being deployed. It leverages data from the + Endpoint datamodel, specifically monitoring process and filesystem activities. This + activity is significant because web shells can provide attackers with remote control + over the compromised server, leading to further exploitation. If confirmed malicious, + this could allow unauthorized access, data exfiltration, or further compromise of + the affected system, posing a severe security risk. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -85,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/java_write_jsp-linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/java_write_jsp-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/jscript_execution_using_cscript_app.yml b/detections/endpoint/jscript_execution_using_cscript_app.yml index 1efa46b9f5..d1eb286807 100644 --- a/detections/endpoint/jscript_execution_using_cscript_app.yml +++ b/detections/endpoint/jscript_execution_using_cscript_app.yml @@ -1,15 +1,17 @@ name: Jscript Execution Using Cscript App id: 002f1e24-146e-11ec-a470-acde48001122 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a execution of jscript using cscript process. - Commonly when a user run jscript file it was executed by wscript.exe application. - This technique was seen in FIN7 js implant to execute its malicious script using - cscript process. This behavior is uncommon and a good artifacts to check further - anomalies within the network +description: The following analytic detects the execution of JScript using the cscript.exe + process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process and command-line telemetry. This behavior is significant because JScript + files are typically executed by wscript.exe, making cscript.exe execution unusual + and potentially indicative of malicious activity, such as the FIN7 group's tactics. + If confirmed malicious, this activity could allow attackers to execute arbitrary + scripts, leading to code execution, data exfiltration, or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/kerberoasting_spn_request_with_rc4_encryption.yml b/detections/endpoint/kerberoasting_spn_request_with_rc4_encryption.yml index 18c1ee775a..206a89180c 100644 --- a/detections/endpoint/kerberoasting_spn_request_with_rc4_encryption.yml +++ b/detections/endpoint/kerberoasting_spn_request_with_rc4_encryption.yml @@ -1,25 +1,24 @@ name: Kerberoasting spn request with RC4 encryption id: 5cc67381-44fa-4111-8a37-7a230943f027 -version: 5 -date: '2024-04-26' +version: 6 +date: '2024-05-16' author: Jose Hernandez, Patrick Bareiss, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic leverages Kerberos Event 4769, A Kerberos service - ticket was requested, to identify a potential kerberoasting attack against Active - Directory networks. Kerberoasting allows an adversary to request kerberos tickets - for domain accounts typically used as service accounts and attempt to crack them - offline allowing them to obtain privileged access to the domain. This analytic looks - for a specific combination of the Ticket_Options field based on common kerberoasting - tools. Defenders should be aware that it may be possible for a Kerberoast attack - to use different Ticket_Options. +description: The following analytic detects potential Kerberoasting attacks by identifying + Kerberos service ticket requests with RC4 encryption through Event ID 4769. It leverages + specific Ticket_Options values commonly used by Kerberoasting tools. This activity + is significant as Kerberoasting allows attackers to request service tickets for + domain accounts, typically service accounts, and crack them offline to gain privileged + access. If confirmed malicious, this could lead to unauthorized access, privilege + escalation, and further compromise of the Active Directory environment. data_source: - Windows Event Log Security 4769 -search: '`wineventlog_security` EventCode=4769 ServiceName!="*$" (TicketOptions=0x40810000 OR TicketOptions=0x40800000 OR TicketOptions=0x40810010) TicketEncryptionType=0x17 - | stats count min(_time) as firstTime max(_time) as lastTime by Computer, service_id, service, TicketEncryptionType, TicketOptions | rename Computer as dest - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `kerberoasting_spn_request_with_rc4_encryption_filter`' +search: '`wineventlog_security` EventCode=4769 ServiceName!="*$" (TicketOptions=0x40810000 + OR TicketOptions=0x40800000 OR TicketOptions=0x40810010) TicketEncryptionType=0x17 + | stats count min(_time) as firstTime max(_time) as lastTime by Computer, service_id, + service, TicketEncryptionType, TicketOptions | rename Computer as dest | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `kerberoasting_spn_request_with_rc4_encryption_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -64,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/kerberoasting_spn_request_with_rc4_encryption/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/kerberoasting_spn_request_with_rc4_encryption/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml b/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml index 1f0ab284b2..43385ce72c 100644 --- a/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml +++ b/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml @@ -1,22 +1,23 @@ name: Kerberos Pre-Authentication Flag Disabled in UserAccountControl id: 0cb847ee-9423-11ec-b2df-acde48001122 -version: 1 -date: '2022-02-22' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic leverages Windows Security Event 4738, `A user - account was changed`, to identify a change performed on a domain user object that - disables Kerberos Pre-Authentication. Disabling the Pre Authentication flag in the - UserAccountControl property allows an adversary to easily perform a brute force - attack against the user's password offline leveraging the ASP REP Roasting technique. - Red Teams and adversaries alike who have obtained privileges in an Active Directory - network may use this technique as a backdoor or a way to escalate privileges. +description: The following analytic detects when the Kerberos Pre-Authentication flag + is disabled in a user account, using Windows Security Event 4738. This event indicates + a change in the UserAccountControl property of a domain user object. Disabling this + flag allows adversaries to perform offline brute force attacks on the user's password + using the AS-REP Roasting technique. This activity is significant as it can be used + by attackers with existing privileges to escalate their access or maintain persistence. + If confirmed malicious, this could lead to unauthorized access and potential compromise + of sensitive information. data_source: - Windows Event Log Security 4738 search: ' `wineventlog_security` EventCode=4738 MSADChangedAttributes="*Don''t Require - Preauth'' - Enabled*" |rename Account_Name as user | table EventCode, user, dest, Security_ID, MSADChangedAttributes - | `kerberos_pre_authentication_flag_disabled_in_useraccountcontrol_filter`' + Preauth'' - Enabled*" |rename Account_Name as user | table EventCode, user, dest, + Security_ID, MSADChangedAttributes | `kerberos_pre_authentication_flag_disabled_in_useraccountcontrol_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `User Account Management` within `Account Management` needs to be enabled. @@ -55,7 +56,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/powershell/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/powershell/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog update_timestamp: true diff --git a/detections/endpoint/kerberos_pre_authentication_flag_disabled_with_powershell.yml b/detections/endpoint/kerberos_pre_authentication_flag_disabled_with_powershell.yml index b728f1b3cc..22119be938 100644 --- a/detections/endpoint/kerberos_pre_authentication_flag_disabled_with_powershell.yml +++ b/detections/endpoint/kerberos_pre_authentication_flag_disabled_with_powershell.yml @@ -1,26 +1,25 @@ name: Kerberos Pre-Authentication Flag Disabled with PowerShell id: 59b51620-94c9-11ec-b3d5-acde48001122 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Set-ADAccountControl` commandlet with specific - parameters. `Set-ADAccountControl` is part of the Active Directory PowerShell module - used to manage Windows Active Directory networks. As the name suggests, `Set-ADAccountControl` - is used to modify User Account Control values for an Active Directory domain account. - With the appropiate parameters, Set-ADAccountControl allows adversaries to disable - Kerberos Pre-Authentication for an account to to easily perform a brute force attack - against the user's password offline leveraging the ASP REP Roasting technique. Red - Teams and adversaries alike who have obtained privileges in an Active Directory - network may use this technique as a backdoor or a way to escalate privileges. +description: The following analytic detects the use of the `Set-ADAccountControl` + PowerShell cmdlet with parameters that disable Kerberos Pre-Authentication. It leverages + PowerShell Script Block Logging (EventCode=4104) to identify this specific command + execution. Disabling Kerberos Pre-Authentication is significant because it allows + adversaries to perform offline brute force attacks against user passwords using + the AS-REP Roasting technique. If confirmed malicious, this activity could enable + attackers to escalate privileges or maintain persistence within an Active Directory + environment, posing a severe security risk. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*Set-ADAccountControl*" AND ScriptBlockText="*DoesNotRequirePreAuth:$true*") | stats count min(_time) as firstTime - max(_time) as lastTime by EventCode ScriptBlockText Computer user_id | rename Computer as dest | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `kerberos_pre_authentication_flag_disabled_with_powershell_filter`' + max(_time) as lastTime by EventCode ScriptBlockText Computer user_id | rename Computer + as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `kerberos_pre_authentication_flag_disabled_with_powershell_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -60,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/powershell/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.004/powershell/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/kerberos_service_ticket_request_using_rc4_encryption.yml b/detections/endpoint/kerberos_service_ticket_request_using_rc4_encryption.yml index 2be16714c5..f361a4b6fc 100644 --- a/detections/endpoint/kerberos_service_ticket_request_using_rc4_encryption.yml +++ b/detections/endpoint/kerberos_service_ticket_request_using_rc4_encryption.yml @@ -1,28 +1,25 @@ name: Kerberos Service Ticket Request Using RC4 Encryption id: 7d90f334-a482-11ec-908c-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic leverages Kerberos Event 4769, A Kerberos service - ticket was requested, to identify a potential Kerberos Service Ticket request related - to a Golden Ticket attack. Adversaries who have obtained the Krbtgt account NTLM - password hash may forge a Kerberos Granting Ticket (TGT) to obtain unrestricted - access to an Active Directory environment. Armed with a Golden Ticket, attackers - can request service tickets to move laterally and execute code on remote systems. - Looking for Kerberos Service Ticket requests using the legacy RC4 encryption mechanism - could represent the second stage of a Golden Ticket attack. RC4 usage should be - rare on a modern network since Windows Vista & Windows Sever 2008 and newer support - AES Kerberos encryption.\ Defenders should note that if an attacker does not leverage - the NTLM password hash but rather the AES key to create a golden ticket, this detection - may be bypassed. +description: 'The following analytic detects Kerberos service ticket requests using + RC4 encryption, leveraging Kerberos Event 4769. This method identifies potential + Golden Ticket attacks, where adversaries forge Kerberos Granting Tickets (TGT) using + the Krbtgt account NTLM password hash to gain unrestricted access to an Active Directory + environment. Monitoring for RC4 encryption usage is significant as it is rare in + modern networks, indicating possible malicious activity. If confirmed malicious, + attackers could move laterally and execute code on remote systems, compromising + the entire network. Note: This detection may be bypassed if attackers use the AES + key instead of the NTLM hash.' data_source: - Windows Event Log Security 4769 -search: ' `wineventlog_security` EventCode=4769 ServiceName="*$" (TicketOptions=0x40810000 OR TicketOptions=0x40800000 OR TicketOptions=0x40810010) TicketEncryptionType=0x17 - | stats count min(_time) as firstTime max(_time) as lastTime by dest, service, service_id, TicketEncryptionType, TicketOptions - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` +search: ' `wineventlog_security` EventCode=4769 ServiceName="*$" (TicketOptions=0x40810000 + OR TicketOptions=0x40800000 OR TicketOptions=0x40810010) TicketEncryptionType=0x17 + | stats count min(_time) as firstTime max(_time) as lastTime by dest, service, service_id, + TicketEncryptionType, TicketOptions | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `kerberos_service_ticket_request_using_rc4_encryption_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting @@ -44,7 +41,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 90 - message: A Kerberos Service TTicket request with RC4 encryption was requested from $dest$ + message: A Kerberos Service TTicket request with RC4 encryption was requested from + $dest$ mitre_attack_id: - T1558 - T1558.001 @@ -70,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.001/kerberos_service_ticket_request_using_rc4_encryption/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.001/kerberos_service_ticket_request_using_rc4_encryption/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/kerberos_tgt_request_using_rc4_encryption.yml b/detections/endpoint/kerberos_tgt_request_using_rc4_encryption.yml index b8aa49a71a..31815fd33b 100644 --- a/detections/endpoint/kerberos_tgt_request_using_rc4_encryption.yml +++ b/detections/endpoint/kerberos_tgt_request_using_rc4_encryption.yml @@ -1,26 +1,22 @@ name: Kerberos TGT Request Using RC4 Encryption id: 18916468-9c04-11ec-bdc6-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic leverages Event 4768, A Kerberos authentication - ticket (TGT) was requested, to identify a TGT request with encryption type 0x17, - or RC4-HMAC. This encryption type is no longer utilized by newer systems and could - represent evidence of an OverPass The Hash attack. Similar to Pass The Hash, OverPass - The Hash is a form of credential theft that allows adversaries to move laterally - or consume resources in a target network. Leveraging this attack, an adversary who - has stolen the NTLM hash of a valid domain account is able to authenticate to the - Kerberos Distribution Center(KDC) on behalf of the legitimate account and obtain - a Kerberos TGT ticket. Depending on the privileges of the compromised account, this - ticket may be used to obtain unauthorized access to systems and other network resources. +description: The following analytic detects a Kerberos Ticket Granting Ticket (TGT) + request using RC4-HMAC encryption (type 0x17) by leveraging Event 4768. This encryption + type is outdated and its presence may indicate an OverPass The Hash attack. Monitoring + this activity is crucial as it can signify credential theft, allowing adversaries + to authenticate to the Kerberos Distribution Center (KDC) using a stolen NTLM hash. + If confirmed malicious, this could enable unauthorized access to systems and resources, + potentially leading to lateral movement and further compromise within the network. data_source: - Windows Event Log Security 4768 -search: ' `wineventlog_security` EventCode=4768 TicketEncryptionType=0x17 ServiceName!=*$ - | stats count min(_time) as firstTime max(_time) as lastTime by ServiceName src_ip dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: ' `wineventlog_security` EventCode=4768 TicketEncryptionType=0x17 ServiceName!=*$ + | stats count min(_time) as firstTime max(_time) as lastTime by ServiceName src_ip + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `kerberos_tgt_request_using_rc4_encryption_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting @@ -61,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/kerberos_tgt_request_using_rc4_encryption/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/kerberos_tgt_request_using_rc4_encryption/windows-xml.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/kerberos_user_enumeration.yml b/detections/endpoint/kerberos_user_enumeration.yml index d165e5ca54..9fd94aa879 100644 --- a/detections/endpoint/kerberos_user_enumeration.yml +++ b/detections/endpoint/kerberos_user_enumeration.yml @@ -1,29 +1,24 @@ name: Kerberos User Enumeration id: d82d4af4-a0bd-11ec-9445-3e22fbd008af -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: Anomaly -description: The following analytic leverages Event Id 4768, A Kerberos authentication - ticket (TGT) was requested, to identify one source endpoint trying to obtain an - unusual number Kerberos TGT ticket for non existing users. This behavior could represent - an adversary abusing the Kerberos protocol to perform a user enumeration attack - against an Active Directory environment. When Kerberos is sent a TGT request with - no preauthentication for an invalid username, it responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN - or 0x6. Red teams and adversaries alike may abuse the Kerberos protocol to validate - a list of users use them to perform further attacks.\ The detection calculates the - standard deviation for each host and leverages the 3-sigma statistical rule to identify - an unusual number requests. To customize this analytic, users can try different - combinations of the `bucket` span time and the calculation of the `upperBound` field. +description: The following analytic detects an unusual number of Kerberos Ticket Granting + Ticket (TGT) requests for non-existing users from a single source endpoint. It leverages + Event ID 4768 and identifies anomalies using the 3-sigma statistical rule. This + behavior is significant as it may indicate an adversary performing a user enumeration + attack against Active Directory. If confirmed malicious, the attacker could validate + a list of usernames, potentially leading to further attacks such as brute force + or credential stuffing, compromising the security of the environment. data_source: - Windows Event Log Security 4768 -search: ' `wineventlog_security` EventCode=4768 Status=0x6 TargetUserName!="*$" - | bucket span=2m _time - | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) as tried_accounts by _time, src_ip - | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by src_ip - | eval upperBound=(comp_avg+comp_std*3) - | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) +search: ' `wineventlog_security` EventCode=4768 Status=0x6 TargetUserName!="*$" | + bucket span=2m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) + as tried_accounts by _time, src_ip | eventstats avg(unique_accounts) as comp_avg + , stdev(unique_accounts) as comp_std by src_ip | eval upperBound=(comp_avg+comp_std*3) + | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) | search isOutlier=1| `kerberos_user_enumeration_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting @@ -64,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1589.002/kerberos_user_enumeration/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1589.002/kerberos_user_enumeration/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/known_services_killed_by_ransomware.yml b/detections/endpoint/known_services_killed_by_ransomware.yml index e9c3bb2b32..0a0cb065f2 100644 --- a/detections/endpoint/known_services_killed_by_ransomware.yml +++ b/detections/endpoint/known_services_killed_by_ransomware.yml @@ -1,15 +1,18 @@ name: Known Services Killed by Ransomware id: 3070f8e0-c528-11eb-b2a0-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search detects a suspicioous termination of known services killed - by ransomware before encrypting files in a compromised machine. This technique is - commonly seen in most of ransomware now a days to avoid exception error while accessing - the targetted files it wants to encrypts because of the open handle of those services - to the targetted file. +description: The following analytic detects the suspicious termination of known services + commonly targeted by ransomware before file encryption. It leverages Windows System + Event Logs (EventCode 7036) to identify when critical services such as Volume Shadow + Copy, backup, and antivirus services are stopped. This activity is significant because + ransomware often disables these services to avoid errors and ensure successful file + encryption. If confirmed malicious, this behavior could lead to widespread data + encryption, rendering files inaccessible and potentially causing significant operational + disruption and data loss. data_source: - Windows Event Log System 7036 search: '`wineventlog_system` EventCode=7036 param1 IN ("*Volume Shadow Copy*","*VSS*", @@ -17,8 +20,9 @@ search: '`wineventlog_system` EventCode=7036 param1 IN ("*Volume Shadow Copy*"," "ccEvtMgr", "ccSetMgr", "SavRoam", "RTVscan", "QBFCService", "QBIDPService", "Intuit.QuickBooks.FCS", "QBCFMonitorService" "YooBackup", "YooIT", "*Veeam*", "PDVFSService", "BackupExecVSSProvider", "BackupExecAgentAccelerator", "BackupExec*", "WdBoot", "WdFilter", "WdNisDrv", "WdNisSvc", - "WinDefend", "wscsvc", "Sense", "sppsvc", "SecurityHealthService") param2="stopped" | stats count min(_time) as firstTime max(_time) as - lastTime by EventCode param1 dest | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` + "WinDefend", "wscsvc", "Sense", "sppsvc", "SecurityHealthService") param2="stopped" + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode param1 + dest | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `known_services_killed_by_ransomware_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the 7036 EventCode ScManager in System audit Logs from your endpoints. @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1490/known_services_killed_by_ransomware/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1490/known_services_killed_by_ransomware/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml b/detections/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml index 5afb161c34..0f3add9bba 100644 --- a/detections/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml +++ b/detections/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml @@ -1,26 +1,26 @@ name: Linux Account Manipulation Of SSH Config and Keys id: 73a56508-1cf5-4df7-b8d9-5737fbdc27d2 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a deletion of ssh key in a linux machine. - attacker may delete or modify ssh key to impair some security features or act as - defense evasion in compromised linux machine. This Anomaly can be also a good indicator - of a malware trying to wipe or delete several files in a compromised host as part - of its destructive payload like what acidrain malware does in linux or router machines. - This detection can be a good pivot to check what process and user tries to delete - this type of files which is not so common and need further investigation. +description: The following analytic detects the deletion of SSH keys on a Linux machine. + It leverages filesystem event logs to identify when files within "/etc/ssh/*" or + "~/.ssh/*" are deleted. This activity is significant because attackers may delete + or modify SSH keys to evade security measures or as part of a destructive payload, + similar to the AcidRain malware. If confirmed malicious, this behavior could lead + to impaired security features, hindered forensic investigations, or further unauthorized + access, necessitating immediate investigation to identify the responsible process + and user. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted AND Filesystem.file_path IN ("/etc/ssh/*", "~/.ssh/*") by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest Filesystem.process_guid Filesystem.action | - `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `linux_account_manipulation_of_ssh_config_and_keys_filter`' + `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `linux_account_manipulation_of_ssh_config_and_keys_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux \ No newline at end of file + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_add_files_in_known_crontab_directories.yml b/detections/endpoint/linux_add_files_in_known_crontab_directories.yml index 31f63a8b63..606c573d9a 100644 --- a/detections/endpoint/linux_add_files_in_known_crontab_directories.yml +++ b/detections/endpoint/linux_add_files_in_known_crontab_directories.yml @@ -1,11 +1,17 @@ name: Linux Add Files In Known Crontab Directories id: 023f3452-5f27-11ec-bf00-acde48001122 -version: 1 -date: '2021-12-17' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic aims to detect unauthorized activities through suspicious file creation in recognized cron table directories, prevalent Unix-based locations for scheduling tasks. This behavior is often exploited by nefarious entities like malware or threat actors, including red teamers, to establish persistence on a targeted or compromised host. The analogy to Windows-based scheduled tasks helps explain the utility of a crontab or cron job. To enhance clarity and actionable intelligence, the anomaly query flags the anomaly, urging further investigation into the added file's details. A cybersecurity analyst should consider additional data points such as the user identity involved, the file's nature and purpose, file origin, timestamp, and any changes in system behavior post file execution. This comprehensive understanding aids in accurately determining the file's legitimacy, facilitating prompt and effective response actions. +description: The following analytic detects unauthorized file creation in known crontab + directories on Unix-based systems. It leverages filesystem data to identify new + files in directories such as /etc/cron* and /var/spool/cron/*. This activity is + significant as it may indicate an attempt by threat actors or malware to establish + persistence on a compromised host. If confirmed malicious, this could allow attackers + to execute arbitrary code at scheduled intervals, potentially leading to further + system compromise and unauthorized access to sensitive information. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -56,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_add_user_account.yml b/detections/endpoint/linux_add_user_account.yml index ed4dd1890f..dd614a81d2 100644 --- a/detections/endpoint/linux_add_user_account.yml +++ b/detections/endpoint/linux_add_user_account.yml @@ -1,15 +1,17 @@ name: Linux Add User Account id: 51fbcaf2-6259-11ec-b0f3-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic looks for commands to create user accounts on the linux - platform. This technique is commonly abuse by adversaries, malware author and red - teamers to persist on the targeted or compromised host by creating new user with - an elevated privilege. This Hunting query may catch normal creation of user by administrator - so filter is needed. +description: The following analytic detects the creation of new user accounts on Linux + systems using commands like "useradd" or "adduser." It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as adversaries often create new user accounts + to establish persistence on compromised hosts. If confirmed malicious, this could + allow attackers to maintain access, escalate privileges, and further compromise + the system, posing a severe security risk. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Processes @@ -65,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/linux_adduser/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/linux_adduser/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_adding_crontab_using_list_parameter.yml b/detections/endpoint/linux_adding_crontab_using_list_parameter.yml index 8a5e642751..2350c26f3d 100644 --- a/detections/endpoint/linux_adding_crontab_using_list_parameter.yml +++ b/detections/endpoint/linux_adding_crontab_using_list_parameter.yml @@ -1,24 +1,18 @@ name: Linux Adding Crontab Using List Parameter id: 52f6d751-1fd4-4c74-a4c9-777ecfeb5c58 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies suspicious modifications to cron jobs - on Linux systems using the crontab command with list parameters. This command line - parameter can be abused by malware like Industroyer2, as well as adversaries and - red teamers, to add a crontab entry for executing their malicious code on a schedule - of their choice. However, it's important to note that administrators or normal users - may also use this command for legitimate automation purposes, so filtering is required - to minimize false positives. Identifying the modification of cron jobs using list - parameters is valuable for a SOC as it indicates potential malicious activity or - an attempt to establish persistence on the system. If a true positive is detected, - further investigation should be conducted to analyze the added cron job, its associated - command, and the impact it may have on the system. This includes examining the purpose - of the job, reviewing any on-disk artifacts, and identifying any related processes - or activities occurring concurrently. The impact of a true positive can range from - unauthorized execution of malicious code to data destruction or other damaging outcomes. +description: The following analytic detects suspicious modifications to cron jobs + on Linux systems using the crontab command with list parameters. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + command-line executions. This activity is significant as it may indicate an attempt + to establish persistence or execute malicious code on a schedule. If confirmed malicious, + the impact could include unauthorized code execution, data destruction, or other + damaging outcomes. Further investigation should analyze the added cron job, its + associated command, and any related processes. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -49,6 +43,7 @@ tags: - Data Destruction - Linux Persistence Techniques - Scheduled Tasks + - Gomir asset_type: Endpoint confidence: 50 impact: 50 @@ -79,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_list_parameter/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_list_parameter/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_apt_get_privilege_escalation.yml b/detections/endpoint/linux_apt_get_privilege_escalation.yml index 568fbd898f..3f64e0e5be 100644 --- a/detections/endpoint/linux_apt_get_privilege_escalation.yml +++ b/detections/endpoint/linux_apt_get_privilege_escalation.yml @@ -1,16 +1,18 @@ name: Linux apt-get Privilege Escalation id: d870ce3b-e796-402f-b2af-cab4da1223f2 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-22' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: The apt-get is a command line tool for interacting with the Advanced - Package Tool (APT) library (a package management system for Linux distributions). - It allows you to search for, install, manage, update, and remove software. The tool - does not build software from the source code. If sudo right is given to the tool - for user, then the user can run system commands as root and possibly get a root - shell. +description: The following analytic detects the execution of the 'apt-get' command + with elevated privileges using 'sudo' on a Linux system. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process execution logs + that include command-line details. This activity is significant because it indicates + a user may be attempting to escalate privileges to root, which could lead to unauthorized + system control. If confirmed malicious, an attacker could gain root access, allowing + them to execute arbitrary commands, install or remove software, and potentially + compromise the entire system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt_get/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt_get/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_apt_privilege_escalation.yml b/detections/endpoint/linux_apt_privilege_escalation.yml index 31406a5709..388b86e419 100644 --- a/detections/endpoint/linux_apt_privilege_escalation.yml +++ b/detections/endpoint/linux_apt_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux APT Privilege Escalation id: 4d5a05fa-77d9-4fd0-af9c-05704f9f9a88 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-22' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Advanced Package Tool, more commonly known as APT, is a collection of - tools used to install, update, remove, and otherwise manage software packages on - Debian and its derivative operating systems, including Ubuntu and Linux Mint. If - sudo right is given to the tool for user, then the user can run system commands - as root and possibly get a root shell. +description: The following analytic detects the use of the Advanced Package Tool (APT) + with elevated privileges via sudo on Linux systems. It leverages Endpoint Detection + and Response (EDR) telemetry to identify processes where APT commands are executed + with sudo rights. This activity is significant because it indicates a user can run + system commands as root, potentially leading to unauthorized root shell access. + If confirmed malicious, this could allow an attacker to escalate privileges, execute + arbitrary commands, and gain full control over the affected system, posing a severe + security risk. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_at_allow_config_file_creation.yml b/detections/endpoint/linux_at_allow_config_file_creation.yml index 95765c3f32..25996012bd 100644 --- a/detections/endpoint/linux_at_allow_config_file_creation.yml +++ b/detections/endpoint/linux_at_allow_config_file_creation.yml @@ -1,13 +1,18 @@ name: Linux At Allow Config File Creation id: 977b3082-5f3d-11ec-b954-acde48001122 -version: 1 -date: '2021-12-17' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic detects the creation of suspicious configuration files, /etc/at.allow or /etc/at.deny, in Linux. These files are commonly abused by malware, adversaries, or red teamers to establish persistence on compromised hosts. The configuration files determine which users are allowed to execute the "at" application, which is used for scheduling tasks in Linux. Attackers can add their user or a compromised username to these files to execute malicious code using "at." It's important to consider potential false positives as administrators or network operators may create these files for legitimate automation purposes. Adjust the filter macros to minimize false positives. - - Identifying the creation of these configuration files is valuable for a SOC as it indicates potential unauthorized activities or an attacker attempting to establish persistence. If a true positive is found, further investigation is necessary to examine the contents of the created configuration file and determine the source of creation. The impact of a true positive can vary but could result in unauthorized execution of malicious code, data theft, or other detrimental consequences. Analysts should review the file path, creation time, and associated processes to assess the extent of the attack and initiate appropriate response actions. +description: The following analytic detects the creation of the /etc/at.allow or /etc/at.deny + configuration files in Linux. It leverages file creation events from the Endpoint + datamodel to identify when these files are created. This activity is significant + as these files control user permissions for the "at" scheduling application and + can be abused by attackers to establish persistence. If confirmed malicious, this + could allow unauthorized execution of malicious code, leading to potential data + theft or further system compromise. Analysts should review the file path, creation + time, and associated processes to assess the threat. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -57,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_at_application_execution.yml b/detections/endpoint/linux_at_application_execution.yml index 5fb5ff165e..05649e4cff 100644 --- a/detections/endpoint/linux_at_application_execution.yml +++ b/detections/endpoint/linux_at_application_execution.yml @@ -1,33 +1,19 @@ name: Linux At Application Execution id: bf0a378e-5f3c-11ec-a6de-acde48001122 -version: 2 -date: '2022-05-26' +version: 3 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly description: 'The following analytic detects the execution of the "At" application in Linux, which can be used by attackers to create persistence entries on a compromised - host. The "At" application can be used for automation purposes by administrators - or network operators, so the filter macros should be updated to remove false positives. - If a true positive is found, it suggests an attacker is trying to maintain access - to the environment or potentially deliver additional malicious payloads, leading - to data theft, ransomware, or other damaging outcomes. To implement this analytic, - ensure you are ingesting logs with the required fields from your endpoints into - the Endpoint datamodel. When a true positive is detected, it suggests that an attacker - is attempting to establish persistence or deliver additional malicious payloads - by leveraging the "At" application. This behavior can lead to data theft, ransomware - attacks, or other damaging outcomes. - - During triage, the SOC analyst should review the context surrounding the execution - of the "At" application. This includes identifying the user, the parent process - responsible for invoking the application, and the specific command-line arguments - used. It is important to consider whether the execution is expected behavior by - an administrator or network operator for legitimate automation purposes. - - The presence of "At" application execution may indicate an attacker''s attempt to - maintain unauthorized access to the environment. Immediate investigation and response - are necessary to mitigate further risks, identify the attacker''s intentions, and - prevent potential harm to the organization.' + host. This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and parent process names associated with "at" or "atd". + This activity is significant because the "At" application can be exploited to maintain + unauthorized access or deliver additional malicious payloads. If confirmed malicious, + this behavior could lead to data theft, ransomware attacks, or other severe consequences. + Immediate investigation is required to determine the legitimacy of the execution + and mitigate potential risks.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Processes @@ -86,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_awk_privilege_escalation.yml b/detections/endpoint/linux_awk_privilege_escalation.yml index 3389ced08c..a7fea37ec7 100644 --- a/detections/endpoint/linux_awk_privilege_escalation.yml +++ b/detections/endpoint/linux_awk_privilege_escalation.yml @@ -1,14 +1,18 @@ name: Linux AWK Privilege Escalation id: 4510cae0-96a2-4840-9919-91d262db210a -version: 1 -date: '2022-07-31' +version: 2 +date: '2024-05-26' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Awk is mostly used for processing and scanning patterns. It checks one - or more files to determine whether any lines fit the specified patterns, and if - so, it does the appropriate action. If sudo right is given to AWK binary for the - user, then the user can run system commands as root and possibly get a root shell. +description: The following analytic detects the use of the AWK command with elevated + privileges to execute system commands. It leverages Endpoint Detection and Response + (EDR) telemetry, specifically monitoring processes that include "sudo," "awk," and + "BEGIN*system" in their command lines. This activity is significant because it indicates + a potential privilege escalation attempt, where a user could gain root access by + executing commands as the root user. If confirmed malicious, this could allow an + attacker to fully compromise the system, execute arbitrary commands, and maintain + persistent control over the affected endpoint. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/awk/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/awk/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_busybox_privilege_escalation.yml b/detections/endpoint/linux_busybox_privilege_escalation.yml index f372d9d005..b32e411a9b 100644 --- a/detections/endpoint/linux_busybox_privilege_escalation.yml +++ b/detections/endpoint/linux_busybox_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Busybox Privilege Escalation id: 387c4e78-f4a4-413d-ad44-e9f7bc4642c9 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-27' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: BusyBox combines tiny versions of many common UNIX utilities into a single - small executable. It provides minimalist replacements for most of the utilities - you usually find in GNU coreutils, util-linux, etc. If sudo right is given to BusyBox - application for the user, then the user can run system commands as root and possibly - get a root shell. +description: The following analytic detects the execution of BusyBox with sudo privileges, + which can lead to privilege escalation on Linux systems. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process creation events + where BusyBox is executed with both 'sh' and 'sudo' commands. This activity is significant + because it indicates a user may be attempting to gain root access, bypassing standard + security controls. If confirmed malicious, this could allow an attacker to execute + arbitrary commands as root, leading to full system compromise and potential persistence + within the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/busybox/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/busybox/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_c89_privilege_escalation.yml b/detections/endpoint/linux_c89_privilege_escalation.yml index 435232ac7a..912bcac714 100644 --- a/detections/endpoint/linux_c89_privilege_escalation.yml +++ b/detections/endpoint/linux_c89_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux c89 Privilege Escalation id: 54c95f4d-3e5d-44be-9521-ea19ba62f7a8 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-30' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: The c89 and cc commands compile, assemble, and link-edit C programs; - the cxx or c++ command does the same for C++ programs. The c89 command should be - used when compiling C programs that are written according to Standard C. If sudo - right is given to c89 application for the user, then the user can run system commands - as root and possibly get a root shell. +description: The following analytic detects the execution of the 'c89' command with + elevated privileges, which can be used to compile and execute C programs as root. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process creation events that include command-line arguments. This activity + is significant because it indicates a potential privilege escalation attempt, allowing + a user to execute arbitrary commands as root. If confirmed malicious, this could + lead to full system compromise, enabling the attacker to gain root access and execute + any command with elevated privileges. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c89/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c89/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_c99_privilege_escalation.yml b/detections/endpoint/linux_c99_privilege_escalation.yml index ccdfb0028b..a13ecbdf76 100644 --- a/detections/endpoint/linux_c99_privilege_escalation.yml +++ b/detections/endpoint/linux_c99_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux c99 Privilege Escalation id: e1c6dec5-2249-442d-a1f9-99a4bd228183 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-21' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: The c99 utility is an interface to the standard C compilation system; - it shall accept source code conforming to the ISO C standard. The system conceptually - consists of a compiler and link editor. If sudo right is given to ruby application - for the user, then the user can run system commands as root and possibly get a root - shell. +description: The following analytic detects the execution of the c99 utility with + sudo privileges, which can lead to privilege escalation on Linux systems. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs that include command-line details. This activity is significant because it + indicates a potential misuse of the c99 utility to gain root access, which is critical + for maintaining system security. If confirmed malicious, this could allow an attacker + to execute commands as root, potentially compromising the entire system and accessing + sensitive information. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c99/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c99/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_change_file_owner_to_root.yml b/detections/endpoint/linux_change_file_owner_to_root.yml index 9c2933ac37..ac42f0748a 100644 --- a/detections/endpoint/linux_change_file_owner_to_root.yml +++ b/detections/endpoint/linux_change_file_owner_to_root.yml @@ -1,16 +1,17 @@ name: Linux Change File Owner To Root id: c1400ea2-6257-11ec-ad49-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for a commandline that change the file owner to root - using chown utility tool. This technique is commonly abuse by adversaries, malware - author and red teamers to escalate privilege to the targeted or compromised host - by changing the owner of their malicious file to root. This event is not so common - in corporate network except from the administrator doing normal task that needs - high privilege. +description: The following analytic detects the use of the 'chown' command to change + a file owner to 'root' on a Linux system. It leverages Endpoint Detection and Response + (EDR) telemetry, specifically monitoring command-line executions and process details. + This activity is significant as it may indicate an attempt to escalate privileges + by adversaries, malware, or red teamers. If confirmed malicious, this action could + allow an attacker to gain root-level access, leading to full control over the compromised + host and potential persistence within the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_clipboard_data_copy.yml b/detections/endpoint/linux_clipboard_data_copy.yml index a9c705ab7c..4281335323 100644 --- a/detections/endpoint/linux_clipboard_data_copy.yml +++ b/detections/endpoint/linux_clipboard_data_copy.yml @@ -82,5 +82,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1115/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_common_process_for_elevation_control.yml b/detections/endpoint/linux_common_process_for_elevation_control.yml index 00ed7645e9..f36c6826fd 100644 --- a/detections/endpoint/linux_common_process_for_elevation_control.yml +++ b/detections/endpoint/linux_common_process_for_elevation_control.yml @@ -1,16 +1,18 @@ name: Linux Common Process For Elevation Control id: 66ab15c0-63d0-11ec-9e70-acde48001122 -version: 1 -date: '2021-12-23' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic is to look for possible elevation control access using - a common known process in linux platform to change the attribute and file ownership. - This technique is commonly abused by adversaries, malware author and red teamers - to gain persistence or privilege escalation on the target or compromised host. This - common process is used to modify file attribute, file ownership or SUID. This tools - can be used in legitimate purposes so filter is needed. +description: The following analytic identifies the execution of common Linux processes + used for elevation control, such as `chmod`, `chown`, and `setuid`. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant because these processes + are often abused by adversaries to gain persistence or escalate privileges on compromised + hosts. If confirmed malicious, this behavior could allow attackers to modify file + attributes, change file ownership, or set user IDs, potentially leading to unauthorized + access and control over critical system resources. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_composer_privilege_escalation.yml b/detections/endpoint/linux_composer_privilege_escalation.yml index 3ee25ed43e..4860e1f884 100644 --- a/detections/endpoint/linux_composer_privilege_escalation.yml +++ b/detections/endpoint/linux_composer_privilege_escalation.yml @@ -1,14 +1,19 @@ name: Linux Composer Privilege Escalation id: a3bddf71-6ba3-42ab-a6b2-396929b16d92 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-28' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Composer is a tool for dependency management in PHP. It allows you to - declare the libraries your project depends on and it will manage (install/update) - them for you. If sudo right is given to tool for the user, then the user can run - system commands as root and possibly get a root shell. +description: The following analytic detects the execution of the Composer tool with + elevated privileges on a Linux system. It identifies instances where Composer is + run with the 'sudo' command, allowing the user to execute system commands as root. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process execution logs and command-line arguments. This activity is + significant because it can indicate an attempt to escalate privileges, potentially + leading to unauthorized root access. If confirmed malicious, an attacker could gain + full control over the system, execute arbitrary commands, and compromise sensitive + data. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/composer/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/composer/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_cpulimit_privilege_escalation.yml b/detections/endpoint/linux_cpulimit_privilege_escalation.yml index 3176c6f3e9..2b3e30b903 100644 --- a/detections/endpoint/linux_cpulimit_privilege_escalation.yml +++ b/detections/endpoint/linux_cpulimit_privilege_escalation.yml @@ -1,15 +1,17 @@ name: Linux Cpulimit Privilege Escalation id: d4e40b7e-aad3-4a7d-aac8-550ea5222be5 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-23' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: cpulimit is a simple program which attempts to limit the cpu usage of - a process (expressed in percentage, not in cpu time). This is useful to control - batch jobs, when you don't want them to eat too much cpu. If sudo right is given - to the program for the user, then the user can run system commands as root and possibly - get a root shell. +description: The following analytic detects the use of the 'cpulimit' command with + specific flags ('-l', '-f') executed with 'sudo' privileges. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments + and execution details. This activity is significant because if 'cpulimit' is granted + sudo rights, a user can potentially execute system commands as root, leading to + privilege escalation. If confirmed malicious, this could allow an attacker to gain + root access, execute arbitrary commands, and fully compromise the affected system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/cpulimit/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/cpulimit/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_csvtool_privilege_escalation.yml b/detections/endpoint/linux_csvtool_privilege_escalation.yml index 4125fa9651..d64d789396 100644 --- a/detections/endpoint/linux_csvtool_privilege_escalation.yml +++ b/detections/endpoint/linux_csvtool_privilege_escalation.yml @@ -1,13 +1,18 @@ name: Linux Csvtool Privilege Escalation id: f8384f9e-1a5c-4c3a-96d6-8a7e5a38a8b8 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-20' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: csvtool is an easy to use command-line tool to work with .CSV files. - If sudo right is given to the tool for the user, then the user can run system commands - as root and possibly get a root shell. +description: The following analytic detects the execution of the 'csvtool' command + with 'sudo' privileges, which can allow a user to run system commands as root. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process execution logs that include command-line details. This activity is significant + because it indicates a potential privilege escalation attempt, where a user could + gain unauthorized root access. If confirmed malicious, this could lead to full system + compromise, allowing an attacker to execute arbitrary commands, escalate privileges, + and maintain persistent access. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/csvtool/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/csvtool/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_curl_upload_file.yml b/detections/endpoint/linux_curl_upload_file.yml index 94628f72ca..108708e413 100644 --- a/detections/endpoint/linux_curl_upload_file.yml +++ b/detections/endpoint/linux_curl_upload_file.yml @@ -1,19 +1,18 @@ name: Linux Curl Upload File id: c1de2d9a-0c02-4bb4-a49a-510c6e9cf2bf -version: 1 -date: '2022-07-29' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies curl being utilized with the -F or - --form, --upload-file, -T, -d, --data, --data-raw, -I and --head switches to upload - AWS credentials or config to a remote destination. This enables uploading of binary - files and so forth. To force the 'content' part to be a file, prefix the file name - with an @ sign. To just get the content part from a file, prefix the file name with - the symbol <. The difference between @ and < is then that @ makes a file get attached - in the post as a file upload, while the < makes a text field and just get the contents - for that text field from a file. This technique was utlized by the TeamTNT group - to exfiltrate AWS credentials. +description: The following analytic detects the use of the curl command with specific + switches (-F, --form, --upload-file, -T, -d, --data, --data-raw, -I, --head) to + upload AWS credentials or configuration files to a remote destination. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and process details. This activity is significant as it may indicate + an attempt to exfiltrate sensitive AWS credentials, a technique known to be used + by the TeamTNT group. If confirmed malicious, this could lead to unauthorized access + and potential compromise of AWS resources. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -87,7 +86,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_data_destruction_command.yml b/detections/endpoint/linux_data_destruction_command.yml index 2d8d8d8775..7716d9c8e6 100644 --- a/detections/endpoint/linux_data_destruction_command.yml +++ b/detections/endpoint/linux_data_destruction_command.yml @@ -1,16 +1,18 @@ name: Linux Data Destruction Command id: b11d3979-b2f7-411b-bb1a-bd00e642173b -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a unix shell command that can wipe - root folders of a linux host. This commandline is being abused by Awfulshred malware - that wipes or corrupts files in a targeted Linux host. The shell command uses the - rm command with force recursive deletion even in the root folder. This TTP can be - a good indicator that a user or a process wants to wipe roots directory files in - Linux host. +description: The following analytic detects the execution of a Unix shell command + designed to wipe root directories on a Linux host. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on the 'rm' command with force recursive + deletion and the '--no-preserve-root' option. This activity is significant as it + indicates potential data destruction attempts, often associated with malware like + Awfulshred. If confirmed malicious, this behavior could lead to severe data loss, + system instability, and compromised integrity of the affected Linux host. Immediate + investigation and response are crucial to mitigate potential damage. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_dd_file_overwrite.yml b/detections/endpoint/linux_dd_file_overwrite.yml index 886f2a3b87..a948daa321 100644 --- a/detections/endpoint/linux_dd_file_overwrite.yml +++ b/detections/endpoint/linux_dd_file_overwrite.yml @@ -1,15 +1,17 @@ name: Linux DD File Overwrite id: 9b6aae5e-8d85-11ec-b2ae-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to look for dd command to overwrite file. This technique - was abused by adversaries or threat actor to destroy files or data on specific system - or in a large number of host within network to interrupt host avilability, services - and many more. This is also used to destroy data where it make the file irrecoverable - by forensic techniques through overwriting files, data or local and remote drives. +description: The following analytic detects the use of the 'dd' command to overwrite + files on a Linux system. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs that include command-line details. + This activity is significant because adversaries often use the 'dd' command to destroy + or irreversibly overwrite files, disrupting system availability and services. If + confirmed malicious, this behavior could lead to data destruction, making recovery + difficult and potentially causing significant operational disruptions. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/linux_dd_file_overwrite/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/linux_dd_file_overwrite/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_decode_base64_to_shell.yml b/detections/endpoint/linux_decode_base64_to_shell.yml index a63476aaf4..9673b8a687 100644 --- a/detections/endpoint/linux_decode_base64_to_shell.yml +++ b/detections/endpoint/linux_decode_base64_to_shell.yml @@ -1,12 +1,12 @@ name: Linux Decode Base64 to Shell id: 637b603e-1799-40fd-bf87-47ecbd551b66 -version: 1 -date: '2022-07-27' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP description: |- - The following analytic detects the behavior of decoding base64-encoded data and passing it to a Linux shell. Additionally, it mitigates the potential damage and protects the organization's systems and data.The detection is made by searching for specific commands in the Splunk query, namely "base64 -d" and "base64 --decode", within the Endpoint.Processes data model. The analytic also includes a filter for Linux shells. The detection is important because it indicates the presence of malicious activity since Base64 encoding is commonly used to obfuscate malicious commands or payloads, and decoding it can be a step in running those commands. It suggests that an attacker is attempting to run malicious commands on a Linux system to gain unauthorized access, for data exfiltration, or perform other malicious actions. + The following analytic detects the decoding of base64-encoded data and its execution in a Linux shell. It leverages the Endpoint.Processes data model to search for commands like "base64 -d" and "base64 --decode" combined with Linux shell execution. This activity is significant because base64 encoding is often used to obfuscate malicious commands or payloads, indicating potential malicious activity. If confirmed malicious, this behavior could allow an attacker to execute unauthorized commands, gain unauthorized access, exfiltrate data, or perform other harmful actions on the Linux system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +80,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml b/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml index f5e654e748..5ed033e710 100644 --- a/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml +++ b/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml @@ -1,16 +1,18 @@ name: Linux Deleting Critical Directory Using RM Command id: 33f89303-cc6f-49ad-921d-2eaea38a6f7a -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a suspicious deletion of a critical - folder in Linux machine using rm command. This technique was seen in industroyer2 - campaign to wipe or destroy energy facilities of a targeted sector. Deletion in - these list of folder is not so common since it need some elevated privileges to - access some of it. We recommend to look further events specially in file access - or file deletion, process commandline that may related to this technique. +description: The following analytic detects the deletion of critical directories on + a Linux machine using the `rm` command with argument rf. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions targeting directories + like /boot, /var/log, /etc, and /dev. This activity is significant because deleting + these directories can severely disrupt system operations and is often associated + with destructive campaigns like Industroyer2. If confirmed malicious, this action + could lead to system instability, data loss, and potential downtime, making it crucial + for immediate investigation and response. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_deletion_of_cron_jobs.yml b/detections/endpoint/linux_deletion_of_cron_jobs.yml index 8ae82ba644..7c403ff139 100644 --- a/detections/endpoint/linux_deletion_of_cron_jobs.yml +++ b/detections/endpoint/linux_deletion_of_cron_jobs.yml @@ -1,24 +1,23 @@ name: Linux Deletion Of Cron Jobs id: 3b132a71-9335-4f33-9932-00bb4f6ac7e8 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a deletion of cron job in a linux machine. - This technique can be related to an attacker, threat actor or malware to disable - scheduled cron jobs that might be related to security or to evade some detections. - We also saw that this technique can be a good indicator for malware that is trying - to wipe or delete several files on the compromised host like the acidrain malware. - This anomaly detection can be a good pivot detection to look for process and user - doing it why they doing. Take note that this event can be done by administrator - so filtering on those possible false positive event is needed. +description: The following analytic detects the deletion of cron jobs on a Linux machine. + It leverages filesystem event logs to identify when files within the "/etc/cron.*" + directory are deleted. This activity is significant because attackers or malware + may delete cron jobs to disable scheduled security tasks or evade detection mechanisms. + If confirmed malicious, this action could allow an attacker to disrupt system operations, + evade security measures, or facilitate further malicious activities such as data + wiping, as seen with the acidrain malware. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path="/etc/cron.*" by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest - Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` + as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path="/etc/cron.*" + by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest Filesystem.process_guid + Filesystem.action | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `linux_deletion_of_cron_jobs_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -66,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_deletion_of_init_daemon_script.yml b/detections/endpoint/linux_deletion_of_init_daemon_script.yml index a4b32b5e74..4dd0291868 100644 --- a/detections/endpoint/linux_deletion_of_init_daemon_script.yml +++ b/detections/endpoint/linux_deletion_of_init_daemon_script.yml @@ -1,27 +1,24 @@ name: Linux Deletion Of Init Daemon Script id: 729aab57-d26f-4156-b97f-ab8dda8f44b1 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a deletion of init daemon script in a linux - machine. daemon script that place in /etc/init.d/ is a directory that can start - and stop some daemon services in linux machines. attacker may delete or modify daemon - script to impair some security features or act as defense evasion in a compromised - linux machine. This TTP can be also a good indicator of a malware trying to wipe - or delete several files in compromised host as part of its destructive payload like - what acidrain malware does in linux or router machines. This detection can be a - good pivot to check what process and user tries to delete this type of files which - is not so common and need further investigation. +description: The following analytic detects the deletion of init daemon scripts on + a Linux machine. It leverages filesystem event logs to identify when files within + the /etc/init.d/ directory are deleted. This activity is significant because init + daemon scripts control the start and stop of critical services, and their deletion + can indicate an attempt to impair security features or evade defenses. If confirmed + malicious, this behavior could allow an attacker to disrupt essential services, + execute destructive payloads, or persist undetected in the environment. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path IN ( "/etc/init.d/*") by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `linux_deletion_of_init_daemon_script_filter`' + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `linux_deletion_of_init_daemon_script_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from @@ -68,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux \ No newline at end of file + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_deletion_of_services.yml b/detections/endpoint/linux_deletion_of_services.yml index 9a3c8eb071..d3c227e341 100644 --- a/detections/endpoint/linux_deletion_of_services.yml +++ b/detections/endpoint/linux_deletion_of_services.yml @@ -1,26 +1,26 @@ name: Linux Deletion Of Services id: b509bbd3-0331-4aaa-8e4a-d2affe100af6 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a deletion of services in a linux machine. - attacker may delete or modify services to impair some security features or act as - defense evasion in a compromised linux machine. This TTP can be also a good indicator - of a malware trying to wipe or delete several files in a compromised host as part - of its destructive payload like what acidrain malware does in linux or router machines. - This detection can be a good pivot to check what process and user tries to delete - this type of files which is not so common and need further investigation. +description: The following analytic detects the deletion of services on a Linux machine. + It leverages filesystem event logs to identify when service files within system + directories (e.g., /etc/systemd/, /lib/systemd/, /run/systemd/) are deleted. This + activity is significant because attackers may delete or modify services to disable + security features or evade defenses. If confirmed malicious, this behavior could + indicate an attempt to impair system functionality or execute a destructive payload, + potentially leading to system instability or data loss. Immediate investigation + is required to determine the responsible process and user. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path IN ( "/etc/systemd/*", "*/lib/systemd/*", "*/run/systemd/*") Filesystem.file_path = "*.service" by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest - Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `linux_deletion_of_services_filter`' + Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `linux_deletion_of_services_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from @@ -70,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux \ No newline at end of file + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_deletion_of_ssl_certificate.yml b/detections/endpoint/linux_deletion_of_ssl_certificate.yml index c0c12269cc..d43e710d0f 100644 --- a/detections/endpoint/linux_deletion_of_ssl_certificate.yml +++ b/detections/endpoint/linux_deletion_of_ssl_certificate.yml @@ -1,26 +1,25 @@ name: Linux Deletion of SSL Certificate id: 839ab790-a60a-4f81-bfb3-02567063f615 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a deletion of ssl certificate in a linux machine. - attacker may delete or modify ssl certificate to impair some security features or - act as defense evasion in compromised linux machine. This Anomaly can be also a - good indicator of a malware trying to wipe or delete several files in a compromised - host as part of its destructive payload like what acidrain malware does in linux - or router machines. This detection can be a good pivot to check what process and - user tries to delete this type of files which is not so common and need further - investigation. +description: The following analytic detects the deletion of SSL certificates on a + Linux machine. It leverages filesystem event logs to identify when files with extensions + .pem or .crt are deleted from the /etc/ssl/certs/ directory. This activity is significant + because attackers may delete or modify SSL certificates to disable security features + or evade defenses on a compromised system. If confirmed malicious, this behavior + could indicate an attempt to disrupt secure communications, evade detection, or + execute a destructive payload, potentially leading to significant security breaches + and data loss. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path = "/etc/ssl/certs/*" Filesystem.file_path IN ("*.pem", "*.crt") by _time span=1h Filesystem.file_name Filesystem.file_path Filesystem.dest Filesystem.process_guid - Filesystem.action | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` + Filesystem.action | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `linux_deletion_of_ssl_certificate_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -67,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux \ No newline at end of file + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_disable_services.yml b/detections/endpoint/linux_disable_services.yml index 7a5da4f568..9c16ea6bf1 100644 --- a/detections/endpoint/linux_disable_services.yml +++ b/detections/endpoint/linux_disable_services.yml @@ -1,15 +1,18 @@ name: Linux Disable Services id: f2e08a38-6689-4df4-ad8c-b51c16262316 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is to detect events that attempts to disable a - service. This is typically identified in parallel with other instances of service - enumeration of attempts to stop a service and then delete it. Adversaries utilize - this technique like industroyer2 malware to terminate security services or other - related services to continue there objective as a destructive payload. +description: The following analytic detects attempts to disable a service on a Linux + system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on processes like "systemctl," "service," and "svcadm" with commands containing + "disable." This activity is significant as adversaries may disable security or critical + services to evade detection and facilitate further malicious actions, such as deploying + destructive payloads. If confirmed malicious, this could lead to the termination + of essential security services, allowing attackers to persist undetected and potentially + cause significant damage to the system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_doas_conf_file_creation.yml b/detections/endpoint/linux_doas_conf_file_creation.yml index c131a51474..b17c9253c8 100644 --- a/detections/endpoint/linux_doas_conf_file_creation.yml +++ b/detections/endpoint/linux_doas_conf_file_creation.yml @@ -1,17 +1,17 @@ name: Linux Doas Conf File Creation id: f6343e86-6e09-11ec-9376-acde48001122 -version: 1 -date: '2022-01-05' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect the creation of doas.conf file in linux host - platform. This configuration file can be use by doas utility tool to allow or permit - standard users to perform tasks as root, the same way sudo does. This tool is developed - as a minimalistic alternative to sudo application. This tool can be abused advesaries, - attacker or malware to gain elevated privileges to the targeted or compromised host. - On the other hand this can also be executed by administrator for a certain task - that needs admin rights. In this case filter is needed. +description: The following analytic detects the creation of the doas.conf file on + a Linux host. This file is used by the doas utility to allow standard users to perform + tasks as root, similar to sudo. The detection leverages filesystem data from the + Endpoint data model, focusing on the creation of the doas.conf file. This activity + is significant because it can indicate an attempt to gain elevated privileges, potentially + by an adversary. If confirmed malicious, this could allow an attacker to execute + commands with root privileges, leading to full system compromise. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -60,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_doas_tool_execution.yml b/detections/endpoint/linux_doas_tool_execution.yml index 5a1e744cb1..7b3ac542c7 100644 --- a/detections/endpoint/linux_doas_tool_execution.yml +++ b/detections/endpoint/linux_doas_tool_execution.yml @@ -1,17 +1,17 @@ name: Linux Doas Tool Execution id: d5a62490-6e09-11ec-884e-acde48001122 -version: 1 -date: '2022-01-05' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect the doas tool execution in linux host platform. - This utility tool allow standard users to perform tasks as root, the same way sudo - does. This tool is developed as a minimalistic alternative to sudo application. - This tool can be abused advesaries, attacker or malware to gain elevated privileges - to the targeted or compromised host. On the other hand this can also be executed - by administrator for a certain task that needs admin rights. In this case filter - is needed. +description: The following analytic detects the execution of the 'doas' tool on a + Linux host. This tool allows standard users to perform tasks with root privileges, + similar to 'sudo'. The detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant as 'doas' can be exploited by adversaries to gain elevated privileges + on a compromised host. If confirmed malicious, this could lead to unauthorized administrative + access, potentially compromising the entire system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas_exec/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas_exec/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_docker_privilege_escalation.yml b/detections/endpoint/linux_docker_privilege_escalation.yml index 938a048798..e0ff97e473 100644 --- a/detections/endpoint/linux_docker_privilege_escalation.yml +++ b/detections/endpoint/linux_docker_privilege_escalation.yml @@ -1,17 +1,18 @@ name: Linux Docker Privilege Escalation id: 2e7bfb78-85f6-47b5-bc2f-15813a4ef2b3 -version: 1 -date: '2022-07-31' +version: 2 +date: '2024-05-24' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Docker is an open source containerization platform. It helps programmers - to bundle applications into containers, which are standardized executable parts - that include the application source code along with the OS libraries and dependencies - needed to run that code in any setting. The user can add mount the root directory - into a container and edit the /etc/password file to add a super user. This requires - the user to be privileged enough to run docker, i.e. being in the docker group or - being root. +description: The following analytic detects attempts to escalate privileges on a Linux + system using Docker. It identifies processes where Docker commands are used to mount + the root directory or execute shell commands within a container. This detection + leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names, + command-line arguments, and parent processes. This activity is significant because + it can allow an attacker with Docker privileges to modify critical system files, + such as /etc/passwd, to create a superuser. If confirmed malicious, this could lead + to full system compromise and persistent unauthorized access. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/docker/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/docker/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_edit_cron_table_parameter.yml b/detections/endpoint/linux_edit_cron_table_parameter.yml index c0f46ec1f5..fd1845cafb 100644 --- a/detections/endpoint/linux_edit_cron_table_parameter.yml +++ b/detections/endpoint/linux_edit_cron_table_parameter.yml @@ -1,29 +1,17 @@ name: Linux Edit Cron Table Parameter id: 0d370304-5f26-11ec-a4bb-acde48001122 -version: 1 -date: '2021-12-17' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Hunting description: 'The following analytic detects the suspicious editing of cron jobs in - Linux via the crontab command-line parameter. This tactic could be used by adversaries - or malware to schedule execution of their malicious code, potentially leading to - system compromise or unauthorized persistent access. It pinpoints this activity - by monitoring command-line executions involving ''crontab'' and the edit parameter - (-e). - - Recognizing such activity is vital for a SOC as cron job manipulations might signal - unauthorized persistence attempts or scheduled malicious actions, potentially resulting - in substantial harm. A true positive signifies an active threat, with implications - ranging from unauthorized access to broader network compromise. - - To implement this analytic, logs capturing process name, parent process, and command-line - executions from your endpoints must be ingested. - - Known false positives could stem from valid administrative tasks or automation processes - using crontab. To reduce these, fine-tune the filter macros according to the benign - activities within your environment. These adjustments ensure legitimate actions - aren''t mistaken for threats, allowing analysts to focus on genuine potential risks.' + Linux using the crontab command-line parameter (-e). It identifies this activity + by monitoring command-line executions involving ''crontab'' and the edit parameter. + This behavior is significant for a SOC as cron job manipulations can indicate unauthorized + persistence attempts or scheduled malicious actions. If confirmed malicious, this + activity could lead to system compromise, unauthorized access, or broader network + compromise.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_edit_parameter/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_edit_parameter/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_emacs_privilege_escalation.yml b/detections/endpoint/linux_emacs_privilege_escalation.yml index f328cd4cc2..80663bbd03 100644 --- a/detections/endpoint/linux_emacs_privilege_escalation.yml +++ b/detections/endpoint/linux_emacs_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Emacs Privilege Escalation id: 92033cab-1871-483d-a03b-a7ce98665cfc -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-24' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: EMACS is a family of text editors that are characterized by their extensibility. - The manual for the most widely used variant, GNU Emacs, describes it as "the extensible, - customizable, self-documenting, real-time display editor". If sudo right is given - to EMACS tool for the user, then the user can run special commands as root and possibly - get a root shell. +description: The following analytic detects the execution of Emacs with elevated privileges + using the `sudo` command and the `--eval` option. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process execution logs that include + command-line arguments. This activity is significant because it indicates a potential + privilege escalation attempt, where a user could gain root access by running Emacs + with elevated permissions. If confirmed malicious, this could allow an attacker + to execute arbitrary commands as root, leading to full system compromise and unauthorized + access to sensitive information. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/emacs/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/emacs/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_file_created_in_kernel_driver_directory.yml b/detections/endpoint/linux_file_created_in_kernel_driver_directory.yml index 76137b9485..a1abd5c193 100644 --- a/detections/endpoint/linux_file_created_in_kernel_driver_directory.yml +++ b/detections/endpoint/linux_file_created_in_kernel_driver_directory.yml @@ -1,18 +1,16 @@ name: Linux File Created In Kernel Driver Directory id: b85bbeec-6326-11ec-9311-acde48001122 -version: 1 -date: '2021-12-22' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious file creation in kernel/driver directory - in linux platform. This directory is known folder for all linux kernel module available - within the system. so creation of file in this directory is a good indicator that - there is a possible rootkit installation in the host machine. This technique was - abuse by adversaries, malware author and red teamers to gain high privileges to - their malicious code such us in kernel level. Even this event is not so common administrator - or legitimate 3rd party tool may install driver or linux kernel module as part of - its installation. +description: The following analytic detects the creation of files in the Linux kernel/driver + directory. It leverages filesystem data to identify new files in this critical directory. + This activity is significant because the kernel/driver directory is typically reserved + for kernel modules, and unauthorized file creation here can indicate a rootkit installation. + If confirmed malicious, this could allow an attacker to gain high-level privileges, + potentially compromising the entire system by executing code at the kernel level. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -62,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_file_creation_in_init_boot_directory.yml b/detections/endpoint/linux_file_creation_in_init_boot_directory.yml index 87c84a7dbd..4f2897be3f 100644 --- a/detections/endpoint/linux_file_creation_in_init_boot_directory.yml +++ b/detections/endpoint/linux_file_creation_in_init_boot_directory.yml @@ -1,16 +1,17 @@ name: Linux File Creation In Init Boot Directory id: 97d9cfb2-61ad-11ec-bb2d-acde48001122 -version: 1 -date: '2021-12-20' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious file creation on init system directories - for automatic execution of script or file upon boot up. This technique is commonly - abuse by adversaries, malware author and red teamer to persist on the targeted or - compromised host. This behavior can be executed or use by an administrator or network - operator to add script files or binary files as part of a task or automation. filter - is needed. +description: The following analytic detects the creation of files in Linux init boot + directories, which are used for automatic execution upon system startup. It leverages + file system logs to identify new files in directories such as /etc/init.d/ and /etc/rc.d/. + This activity is significant as it is a common persistence technique used by adversaries, + malware authors, and red teamers. If confirmed malicious, this could allow an attacker + to maintain persistence on the compromised host, potentially leading to further + exploitation and unauthorized control over the system. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -57,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_file_creation_in_profile_directory.yml b/detections/endpoint/linux_file_creation_in_profile_directory.yml index 71ad6343ba..3a9a11e994 100644 --- a/detections/endpoint/linux_file_creation_in_profile_directory.yml +++ b/detections/endpoint/linux_file_creation_in_profile_directory.yml @@ -1,16 +1,17 @@ name: Linux File Creation In Profile Directory id: 46ba0082-61af-11ec-9826-acde48001122 -version: 1 -date: '2021-12-20' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious file creation in /etc/profile.d directory - to automatically execute scripts by shell upon boot up of a linux machine. This - technique is commonly abused by adversaries, malware and red teamers as a persistence - mechanism to the targeted or compromised host. This Anomaly detection is a good - indicator that someone wants to run a code after boot up which can be done also - by the administrator or network operator for automation purposes. +description: The following analytic detects the creation of files in the /etc/profile.d + directory on Linux systems. It leverages filesystem data to identify new files in + this directory, which is often used by adversaries for persistence by executing + scripts upon system boot. This activity is significant as it may indicate an attempt + to maintain long-term access to the compromised host. If confirmed malicious, this + could allow attackers to execute arbitrary code with elevated privileges each time + the system boots, potentially leading to further compromise and data exfiltration. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -59,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_find_privilege_escalation.yml b/detections/endpoint/linux_find_privilege_escalation.yml index 68825be92e..337e22a5a1 100644 --- a/detections/endpoint/linux_find_privilege_escalation.yml +++ b/detections/endpoint/linux_find_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Find Privilege Escalation id: 2ff4e0c2-8256-4143-9c07-1e39c7231111 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-28' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Find is a command-line utility that locates files based on some user-specified - criteria and either prints the pathname of each matched object or, if another action - is requested, performs that action on each matched object. If sudo right is given - to find utility for the user, then the user can run system commands as root and - possibly get a root shell. +description: The following analytic detects the use of the 'find' command with 'sudo' + and '-exec' options, which can indicate an attempt to escalate privileges on a Linux + system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process execution logs that include command-line arguments. This activity is + significant because it can allow a user to execute system commands as root, potentially + leading to a root shell. If confirmed malicious, this could enable an attacker to + gain full control over the system, leading to severe security breaches and unauthorized + access to sensitive data. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/find/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/find/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_gdb_privilege_escalation.yml b/detections/endpoint/linux_gdb_privilege_escalation.yml index bfd60d2819..a4d996349f 100644 --- a/detections/endpoint/linux_gdb_privilege_escalation.yml +++ b/detections/endpoint/linux_gdb_privilege_escalation.yml @@ -1,14 +1,17 @@ name: Linux GDB Privilege Escalation id: 310b7da2-ab52-437f-b1bf-0bd458674308 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-16' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: GDB is the acronym for GNU Debugger. This tool helps to debug the programs - written in C, C++, Ada, Fortran, etc. The console can be opened using the gdb command - on terminal. If sudo right is given to GDB tool for the user, then the user can - run system commands as root and possibly get a root shell. +description: The following analytic detects the execution of the GNU Debugger (GDB) + with specific flags that indicate an attempt to escalate privileges on a Linux system. + It leverages Endpoint Detection and Response (EDR) telemetry to identify processes + where GDB is run with the `-nx`, `-ex`, and `sudo` flags. This activity is significant + because it can allow a user to execute system commands as root, potentially leading + to a root shell. If confirmed malicious, this could result in full system compromise, + allowing an attacker to gain complete control over the affected endpoint. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gdb/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gdb/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_gem_privilege_escalation.yml b/detections/endpoint/linux_gem_privilege_escalation.yml index 0470837218..8b642f2b9a 100644 --- a/detections/endpoint/linux_gem_privilege_escalation.yml +++ b/detections/endpoint/linux_gem_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Gem Privilege Escalation id: 0115482a-5dcb-4bb0-bcca-5d095d224236 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-24' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: RubyGems is a package manager for the Ruby programming language that - provides a standard format for distributing Ruby programs and libraries (in a self-contained - format called a "gem"), a tool designed to easily manage the installation of gems, - and a server for distributing them. If sudo right is given to GEM utility for the - user, then the user can run system commands as root and possibly get a root shell. +description: The following analytic detects the execution of the RubyGems utility + with elevated privileges, specifically when it is used to run system commands as + root. This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on command-line executions that include "gem open -e" and "sudo". This + activity is significant because it indicates a potential privilege escalation attempt, + allowing a user to execute commands as the root user. If confirmed malicious, this + could lead to full system compromise, enabling the attacker to gain root access + and execute arbitrary commands with elevated privileges. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gem/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gem/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_gnu_awk_privilege_escalation.yml b/detections/endpoint/linux_gnu_awk_privilege_escalation.yml index d529e30597..739707132d 100644 --- a/detections/endpoint/linux_gnu_awk_privilege_escalation.yml +++ b/detections/endpoint/linux_gnu_awk_privilege_escalation.yml @@ -1,18 +1,17 @@ name: Linux GNU Awk Privilege Escalation id: 0dcf43b9-50d8-42a6-acd9-d1c9201fe6ae -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-16' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: gawk command in Linux is used for pattern scanning and processing language. - The awk command requires no compiling and allows the user to use variables, numeric - functions, string functions, and logical operators. It is a utility that enables - programmers to write tiny and effective programs in the form of statements that - define text patterns that are to be searched for, in a text document and the action - that is to be taken when a match is found within a line. If sudo right is given - to gawk tool for the user, then the user can run system commands as root and possibly - get a root shell. +description: The following analytic detects the execution of the 'gawk' command with + elevated privileges on a Linux system. It leverages Endpoint Detection and Response + (EDR) telemetry to identify command-line executions where 'gawk' is used with 'sudo' + and 'BEGIN{system' patterns. This activity is significant because it indicates a + potential privilege escalation attempt, allowing a user to execute system commands + as root. If confirmed malicious, this could lead to full root access, enabling the + attacker to control the system, modify critical files, and maintain persistent access. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -77,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gawk/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gawk/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_hardware_addition_swapoff.yml b/detections/endpoint/linux_hardware_addition_swapoff.yml index 48b191db22..25501520b6 100644 --- a/detections/endpoint/linux_hardware_addition_swapoff.yml +++ b/detections/endpoint/linux_hardware_addition_swapoff.yml @@ -1,15 +1,18 @@ name: Linux Hardware Addition SwapOff id: c1eea697-99ed-44c2-9b70-d8935464c499 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for process execution to disable the swapping of - paging devices. This technique was seen in Awfulshred malware that disables the - swapping of the specified devices and files. This anomaly detection can be a good - indicator that a process or a user tries to disable this Linux feature in a targeted - host. +description: The following analytic detects the execution of the "swapoff" command, + which disables the swapping of paging devices on a Linux system. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs. This activity is significant because disabling swap can be a tactic used by + malware, such as Awfulshred, to evade detection and hinder forensic analysis. If + confirmed malicious, this action could allow an attacker to manipulate system memory + management, potentially leading to data corruption, system instability, or evasion + of memory-based detection mechanisms. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml b/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml index 0c10109704..96a4c94991 100644 --- a/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml +++ b/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml @@ -1,24 +1,25 @@ name: Linux High Frequency Of File Deletion In Boot Folder id: e27fbc5d-0445-4c4a-bc39-87f060d5c602 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a high frequency of file deletion relative - to process name and process id /boot/ folder. These events was seen in industroyer2 - wiper malware where it tries to delete all files in a critical directory in linux - directory. This detection already contains some filter that might cause false positive - during our testing. +description: The following analytic detects a high frequency of file deletions in + the /boot/ folder on Linux systems. It leverages filesystem event logs to identify + when 200 or more files are deleted within an hour by the same process. This behavior + is significant as it may indicate the presence of wiper malware, such as Industroyer2, + which targets critical system directories. If confirmed malicious, this activity + could lead to system instability or failure, hindering the boot process and potentially + causing a complete system compromise. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` values(Filesystem.file_name) as deletedFileNames values(Filesystem.file_path) as deletedFilePath dc(Filesystem.file_path) as numOfDelFilePath count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path = "/boot/*" by _time span=1h Filesystem.dest - Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` | where numOfDelFilePath >= 200 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` | + where numOfDelFilePath >= 200 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `linux_high_frequency_of_file_deletion_in_boot_folder_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -63,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_boot_dir/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_boot_dir/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux \ No newline at end of file + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_high_frequency_of_file_deletion_in_etc_folder.yml b/detections/endpoint/linux_high_frequency_of_file_deletion_in_etc_folder.yml index ee27adad27..5ee59ba96b 100644 --- a/detections/endpoint/linux_high_frequency_of_file_deletion_in_etc_folder.yml +++ b/detections/endpoint/linux_high_frequency_of_file_deletion_in_etc_folder.yml @@ -1,24 +1,25 @@ name: Linux High Frequency Of File Deletion In Etc Folder id: 9d867448-2aff-4d07-876c-89409a752ff8 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a high frequency of file deletion relative - to process name and process id /etc/ folder. These events was seen in acidrain wiper - malware where it tries to delete all files in a non-standard directory in linux - directory. This detection already contains some filter that might cause false positive - during our testing. But we recommend to add more filter if needed. +description: The following analytic detects a high frequency of file deletions in + the /etc/ folder on Linux systems. It leverages the Endpoint.Filesystem data model + to identify instances where 200 or more files are deleted within an hour, grouped + by process name and process ID. This behavior is significant as it may indicate + the presence of wiper malware, such as AcidRain, which aims to delete critical system + files. If confirmed malicious, this activity could lead to severe system instability, + data loss, and potential disruption of services. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` values(Filesystem.file_name) as deletedFileNames values(Filesystem.file_path) as deletedFilePath dc(Filesystem.file_path) as numOfDelFilePath count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.action=deleted Filesystem.file_path = "/etc/*" by _time span=1h Filesystem.dest - Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` | where numOfDelFilePath >= 200 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + Filesystem.process_guid Filesystem.action | `drop_dm_object_name(Filesystem)` | + where numOfDelFilePath >= 200 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `linux_high_frequency_of_file_deletion_in_etc_folder_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -62,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_impair_defenses_process_kill.yml b/detections/endpoint/linux_impair_defenses_process_kill.yml index 13e1afec2a..2780fcd8c0 100644 --- a/detections/endpoint/linux_impair_defenses_process_kill.yml +++ b/detections/endpoint/linux_impair_defenses_process_kill.yml @@ -1,16 +1,18 @@ name: Linux Impair Defenses Process Kill id: 435c6b33-adf9-47fe-be87-8e29fd6654f5 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic looks for PKILL process execution for possible termination - of process. This technique is being used by several Threat actors, adversaries and - red teamers to terminate processes in a targeted linux machine. This Hunting detection - can be a good pivot to check a possible defense evasion technique or termination - of security application in a linux host or wiper like Awfulshred that corrupt all - files. +description: The following analytic identifies the execution of the 'pkill' command, + which is used to terminate processes on a Linux system. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant because threat actors often use 'pkill' + to disable security defenses or terminate critical processes, facilitating further + malicious actions. If confirmed malicious, this behavior could lead to the disruption + of security applications, enabling attackers to evade detection and potentially + corrupt or destroy files on the targeted system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_indicator_removal_clear_cache.yml b/detections/endpoint/linux_indicator_removal_clear_cache.yml index 507605f8d8..11e72cdef5 100644 --- a/detections/endpoint/linux_indicator_removal_clear_cache.yml +++ b/detections/endpoint/linux_indicator_removal_clear_cache.yml @@ -1,15 +1,17 @@ name: Linux Indicator Removal Clear Cache id: e0940505-0b73-4719-84e6-cb94c44a5245 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic looks for processes that clear or free page cache in Linux - system host. This technique was seen in Awfulshred malware wiper that tries to clear - the cache using kernel system request drop_caches while wiping all files in the - targeted host. This TTP detection can be a good indicator of user or process tries - to clear page cache to delete tracks or might be a wiper like Awfulshred. +description: The following analytic detects processes that clear or free page cache + on a Linux system. It leverages Endpoint Detection and Response (EDR) data, focusing + on specific command-line executions involving the kernel system request `drop_caches`. + This activity is significant as it may indicate an attempt to delete forensic evidence + or the presence of wiper malware like Awfulshred. If confirmed malicious, this behavior + could allow an attacker to cover their tracks, making it difficult to investigate + other malicious activities or system compromises. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test3/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test3/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_indicator_removal_service_file_deletion.yml b/detections/endpoint/linux_indicator_removal_service_file_deletion.yml index 609e1ae9b3..bfe37dea46 100644 --- a/detections/endpoint/linux_indicator_removal_service_file_deletion.yml +++ b/detections/endpoint/linux_indicator_removal_service_file_deletion.yml @@ -1,16 +1,18 @@ name: Linux Indicator Removal Service File Deletion id: 6c077f81-2a83-4537-afbc-0e62e3215d55 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious linux processes that delete service - unit configuration files. This technique was seen in several malware to delete service - configuration files to corrupt a services or security product as part of its defense - evasion. This TTP detection can be a good indicator of possible malware try to kill - several services or a wiper like AwfulShred shell script that wipes the targeted - linux host +description: The following analytic detects the deletion of Linux service unit configuration + files by suspicious processes. It leverages Endpoint Detection and Response (EDR) + telemetry, focusing on processes executing the 'rm' command targeting '.service' + files. This activity is significant as it may indicate malware attempting to disable + critical services or security products, a common defense evasion tactic. If confirmed + malicious, this behavior could lead to service disruption, security tool incapacitation, + or complete system compromise, severely impacting the integrity and availability + of the affected Linux host. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test1/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ingress_tool_transfer_hunting.yml b/detections/endpoint/linux_ingress_tool_transfer_hunting.yml index 43cf1b6192..207c64c6cd 100644 --- a/detections/endpoint/linux_ingress_tool_transfer_hunting.yml +++ b/detections/endpoint/linux_ingress_tool_transfer_hunting.yml @@ -86,5 +86,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ingress_tool_transfer_with_curl.yml b/detections/endpoint/linux_ingress_tool_transfer_with_curl.yml index 521395771e..c0c2a18a16 100644 --- a/detections/endpoint/linux_ingress_tool_transfer_with_curl.yml +++ b/detections/endpoint/linux_ingress_tool_transfer_with_curl.yml @@ -1,15 +1,17 @@ name: Linux Ingress Tool Transfer with Curl id: 8c1de57d-abc1-4b41-a727-a7a8fc5e0857 -version: 1 -date: '2022-07-29' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies curl with the command-line switches - that are commonly used to download, output, a remote script or binary. MetaSploit - Framework will combine the -sO switch with | chmod +x to enable a simple one liner - to download and set the execute bit to run the file immediately. During triage, - review the remote domain and file being downloaded for legitimacy. +description: The following analytic detects the use of the curl command with specific + switches (-O, -sO, -ksO, --output) commonly used to download remote scripts or binaries. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line arguments. This activity is significant + as it may indicate an attempt to download and execute potentially malicious files, + often used in initial stages of an attack. If confirmed malicious, this could lead + to unauthorized code execution, enabling attackers to compromise the system further. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +82,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_insert_kernel_module_using_insmod_utility.yml b/detections/endpoint/linux_insert_kernel_module_using_insmod_utility.yml index 3c13040797..41d35b04ca 100644 --- a/detections/endpoint/linux_insert_kernel_module_using_insmod_utility.yml +++ b/detections/endpoint/linux_insert_kernel_module_using_insmod_utility.yml @@ -1,15 +1,18 @@ name: Linux Insert Kernel Module Using Insmod Utility id: 18b5a1a0-6326-11ec-943a-acde48001122 -version: 1 -date: '2021-12-22' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for inserting of linux kernel module using insmod - utility function. This event can detect a installation of rootkit or malicious kernel - module to gain elevated privileges to their malicious code and bypassed detections. - This Anomaly detection is a good indicator that someone installing kernel module - in a linux host either admin or adversaries. filter is needed in this scenario +description: The following analytic detects the insertion of a Linux kernel module + using the insmod utility. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs that include process names and + command-line details. This activity is significant as it may indicate the installation + of a rootkit or malicious kernel module, potentially allowing an attacker to gain + elevated privileges and bypass security detections. If confirmed malicious, this + could lead to unauthorized code execution, persistent access, and severe compromise + of the affected system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_install_kernel_module_using_modprobe_utility.yml b/detections/endpoint/linux_install_kernel_module_using_modprobe_utility.yml index 70eaacec9c..9049b9a000 100644 --- a/detections/endpoint/linux_install_kernel_module_using_modprobe_utility.yml +++ b/detections/endpoint/linux_install_kernel_module_using_modprobe_utility.yml @@ -1,15 +1,18 @@ name: Linux Install Kernel Module Using Modprobe Utility id: 387b278a-6326-11ec-aa2c-acde48001122 -version: 1 -date: '2021-12-22' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for possible installing a linux kernel module using - modprobe utility function. This event can detect a installation of rootkit or malicious - kernel module to gain elevated privileges to their malicious code and bypassed detections. - This Anomaly detection is a good indicator that someone installing kernel module - in a linux host either admin or adversaries. filter is needed in this scenario +description: The following analytic detects the installation of a Linux kernel module + using the modprobe utility. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant because installing a kernel module can indicate an attempt to deploy + a rootkit or other malicious kernel-level code, potentially leading to elevated + privileges and bypassing security detections. If confirmed malicious, this could + allow an attacker to gain persistent, high-level access to the system, compromising + its integrity and security. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_iptables_firewall_modification.yml b/detections/endpoint/linux_iptables_firewall_modification.yml index 5b9bc92001..7a97f54ae9 100644 --- a/detections/endpoint/linux_iptables_firewall_modification.yml +++ b/detections/endpoint/linux_iptables_firewall_modification.yml @@ -1,26 +1,36 @@ name: Linux Iptables Firewall Modification id: 309d59dc-1e1b-49b2-9800-7cf18d12f7b7 -version: 3 -date: '2023-04-12' +version: 4 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly datamodel: - Endpoint -description: This analytic looks for suspicious commandline that modify the iptables - firewall setting of a linux machine. This technique was seen in cyclopsblink malware - where it modifies the firewall setting of the compromised machine to allow traffic - to its tcp port that will be used to communicate with its C2 server. +description: The following analytic detects suspicious command-line activity that + modifies the iptables firewall settings on a Linux machine. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on specific command patterns + that alter firewall rules to accept traffic on certain TCP ports. This activity + is significant as it can indicate malware, such as CyclopsBlink, modifying firewall + settings to allow communication with a Command and Control (C2) server. If confirmed + malicious, this could enable attackers to maintain persistent access and exfiltrate + data, posing a severe security risk. data_source: - Sysmon for Linux EventID 1 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process = "*iptables *" AND Processes.process = "* --dport *" AND Processes.process = "* ACCEPT*" AND Processes.process = "*&>/dev/null*" AND Processes.process = "* tcp *" AND NOT(Processes.parent_process_path IN("/bin/*", "/lib/*", "/usr/bin/*", "/sbin/*")) by Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid Processes.dest _time span=10s Processes.user Processes.parent_process_name Processes.parent_process_path Processes.process_path -| rex field=Processes.process "--dport (?3269|636|989|994|995|8443)" -| stats values(Processes.process) as processes_exec values(port) as ports values(Processes.process_guid) as guids values(Processes.process_id) as pids dc(port) as port_count count by Processes.process_name Processes.parent_process_name Processes.parent_process_id Processes.dest Processes.user Processes.parent_process_path Processes.process_path -| where port_count >=3 -| `drop_dm_object_name(Processes)` -| `security_content_ctime(firstTime)` -| `security_content_ctime(lastTime)` -| `linux_iptables_firewall_modification_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process = "*iptables + *" AND Processes.process = "* --dport *" AND Processes.process = "* ACCEPT*" AND + Processes.process = "*&>/dev/null*" AND Processes.process = "* tcp *" AND + NOT(Processes.parent_process_path IN("/bin/*", "/lib/*", "/usr/bin/*", "/sbin/*")) + by Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + Processes.process_guid Processes.dest _time span=10s Processes.user Processes.parent_process_name + Processes.parent_process_path Processes.process_path | rex field=Processes.process + "--dport (?3269|636|989|994|995|8443)" | stats values(Processes.process) as + processes_exec values(port) as ports values(Processes.process_guid) as guids values(Processes.process_id) + as pids dc(port) as port_count count by Processes.process_name Processes.parent_process_name + Processes.parent_process_id Processes.dest Processes.user Processes.parent_process_path + Processes.process_path | where port_count >=3 | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `linux_iptables_firewall_modification_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -69,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_java_spawning_shell.yml b/detections/endpoint/linux_java_spawning_shell.yml index df5226bc3f..991d68fae9 100644 --- a/detections/endpoint/linux_java_spawning_shell.yml +++ b/detections/endpoint/linux_java_spawning_shell.yml @@ -1,16 +1,18 @@ name: Linux Java Spawning Shell id: 7b09db8a-5c20-11ec-9945-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the process name of Java, Apache, or - Tomcat spawning a Linux shell. This is potentially indicative of exploitation of - the Java application and may be related to current event CVE-2021-44228 (Log4Shell). - The shells included in the macro are "sh", "ksh", "zsh", "bash", "dash", "rbash", - "fish", "csh', "tcsh', "ion", "eshell". Upon triage, review parallel processes and - command-line arguments to determine legitimacy. +description: The following analytic detects instances where Java, Apache, or Tomcat + processes spawn a Linux shell, which may indicate exploitation attempts, such as + those related to CVE-2021-44228 (Log4Shell). This detection leverages Endpoint Detection + and Response (EDR) telemetry, focusing on process names and parent-child process + relationships. This activity is significant as it can signify a compromised Java + application, potentially leading to unauthorized shell access. If confirmed malicious, + attackers could execute arbitrary commands, escalate privileges, or maintain persistent + access, posing a severe threat to the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/java_spawn_shell_nix.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/java_spawn_shell_nix.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_kernel_module_enumeration.yml b/detections/endpoint/linux_kernel_module_enumeration.yml index 3d5cb8cfbb..9716b729ca 100644 --- a/detections/endpoint/linux_kernel_module_enumeration.yml +++ b/detections/endpoint/linux_kernel_module_enumeration.yml @@ -86,5 +86,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1082/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_kworker_process_in_writable_process_path.yml b/detections/endpoint/linux_kworker_process_in_writable_process_path.yml index d9b034568c..e3ff726822 100644 --- a/detections/endpoint/linux_kworker_process_in_writable_process_path.yml +++ b/detections/endpoint/linux_kworker_process_in_writable_process_path.yml @@ -1,19 +1,20 @@ name: Linux Kworker Process In Writable Process Path id: 1cefb270-74a5-4e27-aa0c-2b6fa7c5b4ed -version: 2 -date: '2023-04-12' +version: 3 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Hunting datamodel: - Endpoint -description: This analytic looks for suspicious process kworker commandline in a linux - machine. kworker process name or thread are common names of kernel threads in linux - process. This hunting detections can lead to investigate process contains process - path in writable directory in linux like /home/, /var/log and /tmp/. This technique - was seen in cyclopsblink malware to blend its core and other of its child process - as normal kworker on the compromised machine. This detection might be a good pivot - to look for other IOC related to cyclopsblink malware or attacks. +description: The following analytic detects the execution of a kworker process with + a command line in writable directories such as /home/, /var/log, and /tmp on a Linux + machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process and parent process paths. This activity is significant as kworker processes + are typically kernel threads, and their presence in writable directories is unusual + and indicative of potential malware, such as CyclopsBlink. If confirmed malicious, + this could allow attackers to blend malicious processes with legitimate ones, leading + to persistent access and further system compromise. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_make_privilege_escalation.yml b/detections/endpoint/linux_make_privilege_escalation.yml index 943587ba22..45512b41a9 100644 --- a/detections/endpoint/linux_make_privilege_escalation.yml +++ b/detections/endpoint/linux_make_privilege_escalation.yml @@ -1,15 +1,17 @@ name: Linux Make Privilege Escalation id: 80b22836-5091-4944-80ee-f733ac443f4f -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-12' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: The Linux make command is used to build and maintain groups of programs - and files from the source code. In Linux, it is one of the most frequently used - commands by the developers. It assists developers to install and compile many utilities - from the terminal. If sudo right is given to make utility for the user, then the - user can run system commands as root and possibly get a root shell. +description: The following analytic detects the use of the 'make' command with elevated + privileges to execute system commands as root, potentially leading to a root shell. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + command-line executions that include 'make', '--eval', and 'sudo'. This activity + is significant because it indicates a possible privilege escalation attempt, allowing + a user to gain root access. If confirmed malicious, an attacker could achieve full + control over the system, execute arbitrary commands, and compromise the entire environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/make/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/make/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_mysql_privilege_escalation.yml b/detections/endpoint/linux_mysql_privilege_escalation.yml index f4680d2920..5d3a2ddc22 100644 --- a/detections/endpoint/linux_mysql_privilege_escalation.yml +++ b/detections/endpoint/linux_mysql_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux MySQL Privilege Escalation id: c0d810f4-230c-44ea-b703-989da02ff145 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-17' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: MySQL is an open-source relational database management system. Its name - is a combination of "My", the name of co-founder Michael Widenius's daughter My, - and "SQL", the abbreviation for Structured Query Language. If sudo right is given - to mysql utility for the user, then the user can run system commands as root and - possibly get a root shell. +description: The following analytic detects the execution of MySQL commands with elevated + privileges using sudo, which can lead to privilege escalation. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs that include command-line details. This activity is significant because it + indicates a potential misuse of MySQL to execute system commands as root, which + could allow an attacker to gain root shell access. If confirmed malicious, this + could result in full control over the affected system, leading to severe security + breaches and unauthorized access to sensitive data. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/mysql/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/mysql/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ngrok_reverse_proxy_usage.yml b/detections/endpoint/linux_ngrok_reverse_proxy_usage.yml index 7d20064606..0f435fca52 100644 --- a/detections/endpoint/linux_ngrok_reverse_proxy_usage.yml +++ b/detections/endpoint/linux_ngrok_reverse_proxy_usage.yml @@ -1,15 +1,17 @@ name: Linux Ngrok Reverse Proxy Usage id: bc84d574-708c-467d-b78a-4c1e20171f97 -version: 1 -date: '2023-01-12' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the use of Ngrok being utilized on - the Linux operating system. Unfortunately, there is no original file name for Ngrok, - so it may be worth an additional hunt to identify any command-line arguments. The - sign of someone using Ngrok is not malicious, however, more recently it has become - an adversary tool. +description: The following analytic detects the use of Ngrok on a Linux operating + system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments associated with Ngrok. This activity + is significant because Ngrok can be used by adversaries to establish reverse proxies, + potentially bypassing network defenses. If confirmed malicious, this could allow + attackers to create persistent, unauthorized access channels, facilitating data + exfiltration or further exploitation of the compromised system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,7 +86,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/ngrok_linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/ngrok_linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_node_privilege_escalation.yml b/detections/endpoint/linux_node_privilege_escalation.yml index 385e792315..6b7f465551 100644 --- a/detections/endpoint/linux_node_privilege_escalation.yml +++ b/detections/endpoint/linux_node_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Node Privilege Escalation id: 2e58a4ff-398f-42f4-8fd0-e01ebfe2a8ce -version: 1 -date: '2022-07-31' +version: 2 +date: '2024-05-29' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Node.js is a back-end JavaScript runtime environment that is open-source, - cross-platform, runs on the V8 engine, and executes JavaScript code outside of a - web browser. It was created to help create scalable network applications. If the - binary is allowed to run as superuser by sudo, it does not drop the elevated privileges - and may be used to access the file system, escalate or maintain privileged access. +description: The following analytic identifies the execution of Node.js with elevated + privileges using sudo, specifically when spawning child processes. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions that include specific Node.js commands. This activity is significant + because running Node.js as a superuser without dropping privileges can allow unauthorized + access to the file system and potential privilege escalation. If confirmed malicious, + this could enable an attacker to maintain privileged access, execute arbitrary code, + and compromise sensitive data within the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/node/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/node/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_nopasswd_entry_in_sudoers_file.yml b/detections/endpoint/linux_nopasswd_entry_in_sudoers_file.yml index 95334a9564..0eb96a8627 100644 --- a/detections/endpoint/linux_nopasswd_entry_in_sudoers_file.yml +++ b/detections/endpoint/linux_nopasswd_entry_in_sudoers_file.yml @@ -1,17 +1,18 @@ name: Linux NOPASSWD Entry In Sudoers File id: ab1e0d52-624a-11ec-8e0b-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for suspicious command lines that may add entry - to /etc/sudoers with NOPASSWD attribute in linux platform. This technique is commonly - abuse by adversaries, malware author and red teamers to gain elevated privilege - to the targeted or compromised host. /etc/sudoers file controls who can run what - commands users can execute on the machines and can also control whether user need - a password to execute particular commands. This file is composed of aliases (basically - variables) and user specifications. +description: The following analytic detects the addition of NOPASSWD entries to the + /etc/sudoers file on Linux systems. It leverages Endpoint Detection and Response + (EDR) telemetry to identify command lines containing "NOPASSWD:". This activity + is significant because it allows users to execute commands with elevated privileges + without requiring a password, which can be exploited by adversaries to maintain + persistent, privileged access. If confirmed malicious, this could lead to unauthorized + privilege escalation, persistent access, and potential compromise of sensitive data + and system integrity. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/nopasswd_sudoers/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/nopasswd_sudoers/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_obfuscated_files_or_information_base64_decode.yml b/detections/endpoint/linux_obfuscated_files_or_information_base64_decode.yml index 10c47da133..f7104c6502 100644 --- a/detections/endpoint/linux_obfuscated_files_or_information_base64_decode.yml +++ b/detections/endpoint/linux_obfuscated_files_or_information_base64_decode.yml @@ -87,5 +87,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_octave_privilege_escalation.yml b/detections/endpoint/linux_octave_privilege_escalation.yml index 52cb235314..91976f6e5f 100644 --- a/detections/endpoint/linux_octave_privilege_escalation.yml +++ b/detections/endpoint/linux_octave_privilege_escalation.yml @@ -1,16 +1,18 @@ name: Linux Octave Privilege Escalation id: 78f7487d-42ce-4f7f-8685-2159b25fb477 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-18' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: GNU Octave is a high-level programming language primarily intended for - scientific computing and numerical computation. Octave helps in solving linear and - nonlinear problems numerically, and for performing other numerical experiments using - a language that is mostly compatible with MATLAB. If sudo right is given to the - application for the user, then the user can run system commands as root and possibly - get a root shell. +description: The following analytic detects the execution of GNU Octave with elevated + privileges, specifically when it runs system commands via sudo. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process command-line + arguments that include "octave-cli," "--eval," "system," and "sudo." This activity + is significant because it indicates a potential privilege escalation attempt, allowing + a user to execute commands as root. If confirmed malicious, this could lead to full + system compromise, enabling an attacker to gain root access and execute arbitrary + commands, severely impacting system security and integrity. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/octave/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/octave/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_openvpn_privilege_escalation.yml b/detections/endpoint/linux_openvpn_privilege_escalation.yml index a4fd4973ad..cf1aadc893 100644 --- a/detections/endpoint/linux_openvpn_privilege_escalation.yml +++ b/detections/endpoint/linux_openvpn_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux OpenVPN Privilege Escalation id: d25feebe-fa1c-4754-8a1e-afb03bedc0f2 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-15' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: OpenVPN is a virtual private network system that implements techniques - to create secure point-to-point or site-to-site connections in routed or bridged - configurations and remote access facilities. It implements both client and server - applications. If sudo right is given to the OpenVPN application for the user, then - the user can run system commands as root and possibly get a root shell. +description: The following analytic detects the execution of OpenVPN with elevated + privileges, specifically when combined with the `--dev`, `--script-security`, `--up`, + and `sudo` options. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process command-line arguments and execution details. + This activity is significant because it indicates a potential privilege escalation + attempt, allowing a user to execute system commands as root. If confirmed malicious, + this could lead to full system compromise, enabling an attacker to gain root access + and execute arbitrary commands with elevated privileges. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/openvpn/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/openvpn/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml b/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml index 6b446d9ffa..c9db51e233 100644 --- a/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml +++ b/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml @@ -1,15 +1,18 @@ name: Linux Persistence and Privilege Escalation Risk Behavior id: ad5ac21b-3b1e-492c-8e19-ea5d5e8e5cf1 -version: 3 -date: '2022-08-30' +version: 4 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: Correlation -description: The following correlation is specific to Linux persistence and privilege - escalation tactics and is tied to two analytic stories and any Linux analytic tied - to persistence and privilege escalation. These techniques often overlap with Persistence - techniques, as OS features that let an adversary persist can execute in an elevated - context. +description: The following analytic identifies potential Linux persistence and privilege + escalation activities. It leverages risk scores and event counts from various Linux-related + data sources, focusing on tactics associated with persistence and privilege escalation. + This activity is significant for a SOC because it highlights behaviors that could + allow an attacker to maintain access or gain elevated privileges on a Linux system. + If confirmed malicious, this activity could enable an attacker to execute code with + higher privileges, persist in the environment, and potentially access sensitive + information, posing a severe security risk. data_source: [] search: '| 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) @@ -66,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/linux_risk/linuxrisk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/linux_risk/linuxrisk.log source: linuxrisk sourcetype: stash update_timestamp: true diff --git a/detections/endpoint/linux_php_privilege_escalation.yml b/detections/endpoint/linux_php_privilege_escalation.yml index f421888efa..3b41c80d4c 100644 --- a/detections/endpoint/linux_php_privilege_escalation.yml +++ b/detections/endpoint/linux_php_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux PHP Privilege Escalation id: 4fc4c031-e5be-4cc0-8cf9-49f9f507bcb5 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-19' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: PHP is a general-purpose scripting language geared toward web development. - It was originally created by Danish-Canadian programmer Rasmus Lerdorf in 1994. - The PHP reference implementation is now produced by The PHP Group. If sudo right - is given to php application for the user, then the user can run system commands - as root and possibly get a root shell. +description: The following analytic detects the execution of PHP commands with elevated + privileges on a Linux system. It identifies instances where PHP is used in conjunction + with 'sudo' and 'system' commands, indicating an attempt to run system commands + as the root user. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process command-line arguments. This activity is significant + because it can indicate an attempt to escalate privileges, potentially leading to + full root access. If confirmed malicious, this could allow an attacker to execute + arbitrary commands with root privileges, compromising the entire system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/php/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/php/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_pkexec_privilege_escalation.yml b/detections/endpoint/linux_pkexec_privilege_escalation.yml index a00b3e4ccc..118b7f8937 100644 --- a/detections/endpoint/linux_pkexec_privilege_escalation.yml +++ b/detections/endpoint/linux_pkexec_privilege_escalation.yml @@ -1,14 +1,18 @@ name: Linux pkexec Privilege Escalation id: 03e22c1c-8086-11ec-ac2e-acde48001122 -version: 1 -date: '2022-01-28' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies `pkexec` spawning with no command-line - arguments. A vulnerability in Polkit's pkexec component identified as CVE-2021-4034 - (PwnKit) which is present in the default configuration of all major Linux distributions - and can be exploited to gain full root privileges on the system. +description: The following analytic detects the execution of `pkexec` without any + command-line arguments. This behavior leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process telemetry. The significance lies in the + fact that this pattern is associated with the exploitation of CVE-2021-4034 (PwnKit), + a critical vulnerability in Polkit's pkexec component. If confirmed malicious, this + activity could allow an attacker to gain full root privileges on the affected Linux + system, leading to complete system compromise and potential unauthorized access + to sensitive information. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -84,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/pkexec/linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/pkexec/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml b/detections/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml index 9b526491b7..1795a873f8 100644 --- a/detections/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml +++ b/detections/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml @@ -1,16 +1,18 @@ name: Linux Possible Access Or Modification Of sshd Config File id: 7a85eb24-72da-11ec-ac76-acde48001122 -version: 1 -date: '2022-01-11' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for suspicious process command-line that might - be accessing or modifying sshd_config. This file is the ssh configuration file that - might be modify by threat actors or adversaries to redirect port connection, allow - user using authorized key generated during attack. This anomaly detection might - catch noise from administrator auditing or modifying ssh configuration file. In - this scenario filter is needed +description: The following analytic detects suspicious access or modification of the + sshd_config file on Linux systems. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command-line executions involving processes like + "cat," "nano," "vim," and "vi" accessing the sshd_config file. This activity is + significant because unauthorized changes to sshd_config can allow threat actors + to redirect port connections or use unauthorized keys, potentially compromising + the system. If confirmed malicious, this could lead to unauthorized access, privilege + escalation, or persistent backdoor access, posing a severe security risk. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_access_to_credential_files.yml b/detections/endpoint/linux_possible_access_to_credential_files.yml index 45ba11cce0..81a283e83d 100644 --- a/detections/endpoint/linux_possible_access_to_credential_files.yml +++ b/detections/endpoint/linux_possible_access_to_credential_files.yml @@ -1,17 +1,17 @@ name: Linux Possible Access To Credential Files id: 16107e0e-71fc-11ec-b862-acde48001122 -version: 1 -date: '2022-01-10' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a possible attempt to dump or access the content - of /etc/passwd and /etc/shadow to enable offline credential cracking. "etc/passwd" - store user information within linux OS while "etc/shadow" contain the user passwords - hash. Adversaries and threat actors may attempt to access this to gain persistence - and/or privilege escalation. This anomaly detection can be a good indicator of possible - credential dumping technique but it might catch some normal administrator automation - scripts or during credential auditing. In this scenario filter is needed. +description: The following analytic detects attempts to access or dump the contents + of /etc/passwd and /etc/shadow files on Linux systems. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on processes like 'cat', 'nano', 'vim', + and 'vi' accessing these files. This activity is significant as it may indicate + credential dumping, a technique used by adversaries to gain persistence or escalate + privileges. If confirmed malicious, attackers could obtain hashed passwords for + offline cracking, leading to unauthorized access and potential system compromise. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_access_to_sudoers_file.yml b/detections/endpoint/linux_possible_access_to_sudoers_file.yml index 2823bd44e8..814f5dfe46 100644 --- a/detections/endpoint/linux_possible_access_to_sudoers_file.yml +++ b/detections/endpoint/linux_possible_access_to_sudoers_file.yml @@ -1,15 +1,17 @@ name: Linux Possible Access To Sudoers File id: 4479539c-71fc-11ec-b2e2-acde48001122 -version: 1 -date: '2022-01-10' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a possible access or modification of /etc/sudoers - file. "/etc/sudoers" file controls who can run what command as what users on what - machine and can also control whether a specific user need a password for particular - commands. adversaries and threat actors abuse this file to gain persistence and/or - privilege escalation during attack on targeted host. +description: The following analytic detects potential access or modification of the + /etc/sudoers file on a Linux system. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on processes like "cat," "nano," "vim," and "vi" + accessing the /etc/sudoers file. This activity is significant because the sudoers + file controls user permissions for executing commands with elevated privileges. + If confirmed malicious, an attacker could gain persistence or escalate privileges, + compromising the security of the targeted host. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_append_command_to_at_allow_config_file.yml b/detections/endpoint/linux_possible_append_command_to_at_allow_config_file.yml index 4df933ceee..009ff74a40 100644 --- a/detections/endpoint/linux_possible_append_command_to_at_allow_config_file.yml +++ b/detections/endpoint/linux_possible_append_command_to_at_allow_config_file.yml @@ -1,20 +1,18 @@ name: Linux Possible Append Command To At Allow Config File id: 7bc20606-5f40-11ec-a586-acde48001122 -version: 2 -date: '2022-05-26' +version: 3 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: 'The following analytic is designed to identify suspicious command lines - that may append user entries to either /etc/at.allow or /etc/at.deny. These files - can be exploited by malicious actors for persistence on a compromised Linux host - by altering permissions for scheduled tasks using the at command. - - In this context, an attacker can create a user or add an existing user to these - configuration files to execute their malicious code through scheduled tasks. The - detection of such anomalous behavior can serve as an effective indicator warranting - further investigation to validate if the activity is indeed malicious or a false - positive.' +description: 'The following analytic detects suspicious command lines that append + user entries to /etc/at.allow or /etc/at.deny files. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on command-line executions involving + these files. This activity is significant because altering these configuration files + can allow attackers to schedule tasks with elevated permissions, facilitating persistence + on a compromised Linux host. If confirmed malicious, this could enable attackers + to execute arbitrary code at scheduled intervals, potentially leading to further + system compromise and unauthorized access to sensitive information.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Processes @@ -72,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_append_command_to_profile_config_file.yml b/detections/endpoint/linux_possible_append_command_to_profile_config_file.yml index 74e4d84fc2..f907aa375e 100644 --- a/detections/endpoint/linux_possible_append_command_to_profile_config_file.yml +++ b/detections/endpoint/linux_possible_append_command_to_profile_config_file.yml @@ -1,17 +1,18 @@ name: Linux Possible Append Command To Profile Config File id: 9c94732a-61af-11ec-91e3-acde48001122 -version: 1 -date: '2021-12-20' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious command-lines that can be possibly - used to modify user profile files to automatically execute scripts/executables by - shell upon reboot of the machine. This technique is commonly abused by adversaries, - malware and red teamers as persistence mechanism to the targeted or compromised - host. This Anomaly detection is a good indicator that someone wants to run code - after reboot which can be done also by the administrator or network operator for - automation purposes. +description: The following analytic detects suspicious command-lines that modify user + profile files to automatically execute scripts or executables upon system reboot. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + command-line executions involving profile files like ~/.bashrc and /etc/profile. + This activity is significant as it indicates potential persistence mechanisms used + by adversaries to maintain access to compromised hosts. If confirmed malicious, + this could allow attackers to execute arbitrary code upon reboot, leading to persistent + control over the system and potential further exploitation. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml b/detections/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml index b90e23fb5f..a221d86e38 100644 --- a/detections/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml +++ b/detections/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml @@ -1,26 +1,18 @@ name: Linux Possible Append Cronjob Entry on Existing Cronjob File id: b5b91200-5f27-11ec-bb4e-acde48001122 -version: 1 -date: '2021-12-17' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Hunting -description: 'The following analytic is designed to detect potential tampering with - cronjob files on a Linux system. It specifically searches for command lines that - may be used to append code to existing cronjob files, a technique often employed - by adversaries, malware, and red teamers for persistence or privilege escalation. - Altering existing or sometimes normal cronjob script files allows malicious code - to be executed automatically. - - The analytic operates by monitoring logs for specific process names, parent processes, - and command-line executions from your endpoints. It specifically checks for any - ''echo'' command which modifies files in directories commonly associated with cron - jobs such as ''/etc/cron*'', ''/var/spool/cron/'', and ''/etc/anacrontab''. If such - activity is detected, an alert is triggered. - - This behavior is worth identifying for a SOC because malicious cron jobs can lead - to system compromises and unauthorized data access, impacting business operations - and data integrity.' +description: 'The following analytic detects potential tampering with cronjob files + on a Linux system by identifying ''echo'' commands that append code to existing + cronjob files. It leverages logs from Endpoint Detection and Response (EDR) agents, + focusing on process names, parent processes, and command-line executions. This activity + is significant because adversaries often use it for persistence or privilege escalation. + If confirmed malicious, this could allow attackers to execute unauthorized code + automatically, leading to system compromises and unauthorized data access, thereby + impacting business operations and data integrity.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Processes @@ -81,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_cronjob_modification_with_editor.yml b/detections/endpoint/linux_possible_cronjob_modification_with_editor.yml index cdf2bb724c..7ad33cf314 100644 --- a/detections/endpoint/linux_possible_cronjob_modification_with_editor.yml +++ b/detections/endpoint/linux_possible_cronjob_modification_with_editor.yml @@ -1,31 +1,17 @@ name: Linux Possible Cronjob Modification With Editor id: dcc89bde-5f24-11ec-87ca-acde48001122 -version: 1 -date: '2021-12-17' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Hunting description: 'The following analytic detects potential unauthorized modifications - to Linux cronjobs using text editors like "nano", "vi" or "vim". It identifies this - behavior by tracking command-line executions that interact with paths related to - cronjob configuration, a common Linux scheduling utility. Cronjob files may be manipulated - by attackers for privilege escalation or persistent access, making such changes - critical to monitor.\ The identified behavior is significant for a Security Operations - Center (SOC) as it could indicate an ongoing attempt at establishing persistent - access or privilege escalation, leading to data breaches, system compromise, or - other malicious activities. - - In case of a true positive, the impact could be severe. An attacker with escalated - privileges or persistent access could carry out damaging actions, such as data theft, - sabotage, or further network penetration. - - To implement this analytic, ensure ingestion of logs tracking process name, parent - process, and command-line executions from your endpoints. Utilize the Add-on for - Linux Sysmon from Splunkbase if you''re using Sysmon. - - Known false positives include legitimate administrative tasks, as these commands - may also be used for benign purposes. Careful tuning and filtering based on known - benign activity in your environment can minimize these instances.' + to Linux cronjobs using text editors like "nano," "vi," or "vim." It identifies + this activity by monitoring command-line executions that interact with cronjob configuration + paths. This behavior is significant for a SOC as it may indicate attempts at privilege + escalation or establishing persistent access. If confirmed malicious, the impact + could be severe, allowing attackers to execute damaging actions such as data theft, + system sabotage, or further network penetration.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_possible_ssh_key_file_creation.yml b/detections/endpoint/linux_possible_ssh_key_file_creation.yml index 2599d5881a..9b2bd11807 100644 --- a/detections/endpoint/linux_possible_ssh_key_file_creation.yml +++ b/detections/endpoint/linux_possible_ssh_key_file_creation.yml @@ -1,15 +1,16 @@ name: Linux Possible Ssh Key File Creation id: c04ef40c-72da-11ec-8eac-acde48001122 -version: 1 -date: '2022-01-11' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for possible ssh key file creation on ~/.ssh/ - folder. This technique is commonly abused by threat actors and adversaries to gain - persistence and privilege escalation to the targeted host. by creating ssh private - and public key and passing the public key to the attacker server. threat actor can - access remotely the machine using openssh daemon service. +description: The following analytic detects the creation of SSH key files in the ~/.ssh/ + directory. It leverages filesystem data to identify new files in this specific path. + This activity is significant because threat actors often create SSH keys to gain + persistent access and escalate privileges on a compromised host. If confirmed malicious, + this could allow attackers to remotely access the machine using the OpenSSH daemon + service, leading to potential unauthorized control and data exfiltration. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -59,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_preload_hijack_library_calls.yml b/detections/endpoint/linux_preload_hijack_library_calls.yml index 638e00fa1c..d9e8cd45eb 100644 --- a/detections/endpoint/linux_preload_hijack_library_calls.yml +++ b/detections/endpoint/linux_preload_hijack_library_calls.yml @@ -1,15 +1,18 @@ name: Linux Preload Hijack Library Calls id: cbe2ca30-631e-11ec-8670-acde48001122 -version: 1 -date: '2021-12-22' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious command that may hijack a library - function in linux platform. This technique is commonly abuse by adversaries, malware - author and red teamers to gain privileges and persist on the machine. This detection - pertains to loading a dll to hijack or hook a library function of specific program - using LD_PRELOAD command. +description: The following analytic detects the use of the LD_PRELOAD environment + variable to hijack or hook library functions on a Linux platform. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs that include command-line details. This activity is significant because adversaries, + malware authors, and red teamers commonly use this technique to gain elevated privileges + and establish persistence on a compromised machine. If confirmed malicious, this + behavior could allow attackers to execute arbitrary code, escalate privileges, and + maintain long-term access to the system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.006/lib_hijack/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.006/lib_hijack/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_proxy_socks_curl.yml b/detections/endpoint/linux_proxy_socks_curl.yml index ed48907888..00d9d54891 100644 --- a/detections/endpoint/linux_proxy_socks_curl.yml +++ b/detections/endpoint/linux_proxy_socks_curl.yml @@ -1,20 +1,18 @@ name: Linux Proxy Socks Curl id: bd596c22-ad1e-44fc-b242-817253ce8b08 -version: 1 -date: '2022-07-29' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies curl being utilized with a proxy based - on command-line arguments - -x, socks, --preproxy and --proxy. This behavior is - built into the MetaSploit Framework as a auxiliary module. What does socks buy an - adversary? SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination - domain name rather than an IP address. The SOCKS5 protocol is defined in RFC 1928. - It is an incompatible extension of the SOCKS4 protocol; it offers more choices for - authentication and adds support for IPv6 and UDP, the latter of which can be used - for DNS lookups. The protocols, and a proxy itself, allow an adversary to evade - controls in place monitoring traffic, making it harder for the defender to identify - and track activity. +description: The following analytic detects the use of the `curl` command with proxy-related + arguments such as `-x`, `socks`, `--preproxy`, and `--proxy`. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and process details. This activity is significant as it may indicate + an adversary attempting to use a proxy to evade network monitoring and obscure their + actions. If confirmed malicious, this behavior could allow attackers to bypass security + controls, making it difficult to track their activities and potentially leading + to unauthorized data access or exfiltration. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -89,7 +87,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_puppet_privilege_escalation.yml b/detections/endpoint/linux_puppet_privilege_escalation.yml index 3e6ee65e69..fc160989a9 100644 --- a/detections/endpoint/linux_puppet_privilege_escalation.yml +++ b/detections/endpoint/linux_puppet_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Puppet Privilege Escalation id: 1d19037f-466e-4d56-8d87-36fafd9aa3ce -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-17' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: In computing, Puppet is a software configuration management tool which - includes its own declarative language to describe system configuration. It is a - model-driven solution that requires limited programming knowledge to use. If sudo - right is given to the tool for the user, then the user can run system commands as - root and possibly get a root shell. +description: The following analytic detects the execution of Puppet commands with + elevated privileges, specifically when Puppet is used to apply configurations with + sudo rights. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs that include command-line details. + This activity is significant because it indicates a potential privilege escalation + attempt, where a user could gain root access and execute system commands as the + root user. If confirmed malicious, this could allow an attacker to fully compromise + the system, execute arbitrary commands, and maintain persistent control. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/puppet/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/puppet/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_rpm_privilege_escalation.yml b/detections/endpoint/linux_rpm_privilege_escalation.yml index efe8dc290c..69c6e106e7 100644 --- a/detections/endpoint/linux_rpm_privilege_escalation.yml +++ b/detections/endpoint/linux_rpm_privilege_escalation.yml @@ -1,16 +1,18 @@ name: Linux RPM Privilege Escalation id: f8e58a23-cecd-495f-9c65-6c76b4cb9774 -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-21' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: RPM Package Manager is a free and open-source package management system. - The name RPM refers to the .rpm file format and the package manager program itself. - RPM was intended primarily for Linux distributions; the file format is the baseline - package format of the Linux Standard Base. If sudo right is given to rpm utility - for the user, then the user can run system commands as root and possibly get a root - shell. +description: The following analytic detects the execution of the RPM Package Manager + with elevated privileges, specifically when it is used to run system commands as + root via the `--eval` and `lua:os.execute` options. This detection leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line executions + and process metadata. This activity is significant because it indicates a potential + privilege escalation attempt, allowing a user to gain root access. If confirmed + malicious, this could lead to full system compromise, unauthorized access to sensitive + data, and further exploitation of the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/rpm/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/rpm/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ruby_privilege_escalation.yml b/detections/endpoint/linux_ruby_privilege_escalation.yml index 28a56dab7e..a4ebe6d2ad 100644 --- a/detections/endpoint/linux_ruby_privilege_escalation.yml +++ b/detections/endpoint/linux_ruby_privilege_escalation.yml @@ -1,14 +1,17 @@ name: Linux Ruby Privilege Escalation id: 097b28b5-7004-4d40-a715-7e390501788b -version: 1 -date: '2022-08-09' +version: 2 +date: '2024-05-25' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: Ruby is one of the most used and easy to use programming languages. Ruby - is an open-source, object-oriented interpreter that can be installed on a Linux - system. If sudo right is given to ruby application for the user, then the user can - run system commands as root and possibly get a root shell. +description: The following analytic detects the execution of Ruby commands with elevated + privileges on a Linux system. It identifies processes where Ruby is used with the + `-e` flag to execute commands via `sudo`, leveraging Endpoint Detection and Response + (EDR) telemetry. This activity is significant because it indicates a potential privilege + escalation attempt, allowing a user to execute commands as root. If confirmed malicious, + this could lead to full system compromise, enabling an attacker to gain root access, + execute arbitrary commands, and maintain persistent control over the affected system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/ruby/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/ruby/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_service_file_created_in_systemd_directory.yml b/detections/endpoint/linux_service_file_created_in_systemd_directory.yml index ed5bfce79e..4c165ae904 100644 --- a/detections/endpoint/linux_service_file_created_in_systemd_directory.yml +++ b/detections/endpoint/linux_service_file_created_in_systemd_directory.yml @@ -1,13 +1,17 @@ name: Linux Service File Created In Systemd Directory id: c7495048-61b6-11ec-9a37-acde48001122 -version: 1 -date: '2021-12-20' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is designed to detect suspicious file creation within the systemd timer directory on Linux platforms. Systemd is a system and service manager for Linux, similar to the combination of wininit.exe and services.exe on Windows. This process initializes a Linux system and starts defined services in unit files. Malicious actors, such as adversaries, malware, or red teamers, can exploit this feature by embedding a systemd service file for persistence on the targeted or compromised host. - - The analytic works by monitoring logs with file name, file path, and process GUID data from your endpoints. If a .service file is created in certain systemd directories, the analytic triggers an alert. This behavior is significant for a Security Operations Center (SOC) as it may indicate a persistent threat within the network, with a potential impact of system compromise or data exfiltration. +description: The following analytic detects the creation of suspicious service files + within the systemd directories on Linux platforms. It leverages logs containing + file name, file path, and process GUID data from endpoints. This activity is significant + for a SOC as it may indicate an adversary attempting to establish persistence on + a compromised host. If confirmed malicious, this could lead to system compromise + or data exfiltration, allowing attackers to maintain control over the system and + execute further malicious activities. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -21,7 +25,11 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime how_to_implement: To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. -known_false_positives: False positives may arise when administrators or network operators create files in systemd directories for legitimate automation tasks. Therefore, it's important to adjust filter macros to account for valid activities. To implement this search successfully, it's crucial to ingest appropriate logs, preferably using the Linux Sysmon Add-on from Splunkbase for those using Sysmon. +known_false_positives: False positives may arise when administrators or network operators + create files in systemd directories for legitimate automation tasks. Therefore, + it's important to adjust filter macros to account for valid activities. To implement + this search successfully, it's crucial to ingest appropriate logs, preferably using + the Linux Sysmon Add-on from Splunkbase for those using Sysmon. references: - https://attack.mitre.org/techniques/T1053/006/ - https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/ @@ -33,6 +41,7 @@ tags: - Linux Persistence Techniques - Linux Living Off The Land - Scheduled Tasks + - Gomir asset_type: Endpoint confidence: 80 impact: 80 @@ -61,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_service_restarted.yml b/detections/endpoint/linux_service_restarted.yml index faac92c0fd..6926755af4 100644 --- a/detections/endpoint/linux_service_restarted.yml +++ b/detections/endpoint/linux_service_restarted.yml @@ -1,29 +1,18 @@ name: Linux Service Restarted id: 084275ba-61b8-11ec-8d64-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly description: 'The following analytic detects the restarting or re-enabling of services - in the Linux platform. It focuses on the use of the systemctl or service tools for - executing these actions. Adversaries may leverage this technique to repeatedly execute - malicious payloads as a form of persistence. Linux hosts typically start services - during boot to perform background system functions. However, administrators may - also create legitimate services for specific tools or applications as part of task - automation. In such cases, it is recommended to verify the service path of the registered - script or executable and identify the creator of the service for further validation. - - It''s important to be aware that this analytic may generate false positives as administrators - or network operators may use the same command-line for legitimate automation purposes. - Filter macros should be updated accordingly to minimize false positives. - - Identifying restarted or re-enabled services is valuable for a SOC as it can indicate - potential malicious activities attempting to maintain persistence or execute unauthorized - actions on Linux systems. By detecting and investigating these events, security - analysts can respond promptly to mitigate risks and prevent further compromise. - The impact of a true positive can range from unauthorized access to data destruction - or other damaging outcomes.' + on Linux systems using the `systemctl` or `service` commands. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process and command-line + execution logs. This activity is significant as adversaries may use it to maintain + persistence or execute unauthorized actions. If confirmed malicious, this behavior + could lead to repeated execution of malicious payloads, unauthorized access, or + data destruction. Security analysts should investigate these events to mitigate + risks and prevent further compromise.' data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -54,6 +43,7 @@ tags: - Data Destruction - Linux Persistence Techniques - Scheduled Tasks + - Gomir asset_type: Endpoint confidence: 50 impact: 50 @@ -84,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_service_started_or_enabled.yml b/detections/endpoint/linux_service_started_or_enabled.yml index 61cf358632..72eebc0fce 100644 --- a/detections/endpoint/linux_service_started_or_enabled.yml +++ b/detections/endpoint/linux_service_started_or_enabled.yml @@ -1,30 +1,28 @@ name: Linux Service Started Or Enabled id: e0428212-61b7-11ec-88a3-acde48001122 -version: 2 -date: '2024-01-24' +version: 3 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic detects the creation or enabling of services in - Linux platforms, specifically using the systemctl or service tool application. This - behavior is worth identifying as adversaries may create or modify services to execute - malicious payloads as part of persistence. Legitimate services created by administrators - for automation purposes may also trigger this analytic, so it is important to update - the filter macros to remove false positives. If a true positive is found, it suggests - an possible attacker is attempting to persist within the environment or deliver - additional malicious payloads, leading to data theft, ransomware, or other damaging - outcomes. To implement this analytic, ensure you are ingesting logs with the process - name, parent process, and command-line executions from your endpoints. +description: The following analytic detects the creation or enabling of services on + Linux platforms using the systemctl or service tools. It leverages Endpoint Detection + and Response (EDR) logs, focusing on process names, parent processes, and command-line + executions. This activity is significant as adversaries may create or modify services + to maintain persistence or execute malicious payloads. If confirmed malicious, this + behavior could lead to persistent access, data theft, ransomware deployment, or + other damaging outcomes. Monitoring and investigating such activities are crucial + for maintaining the security and integrity of the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_name IN ("systemctl", "service") OR Processes.process IN ("*systemctl *", "*service *")) Processes.process - IN ("* start *", "* enable *") AND NOT (Processes.os="Microsoft Windows" OR Processes.vendor_product="Microsoft Windows") - by Processes.dest Processes.user Processes.parent_process_name - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - Processes.process_guid | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `linux_service_started_or_enabled_filter`' + IN ("* start *", "* enable *") AND NOT (Processes.os="Microsoft Windows" OR Processes.vendor_product="Microsoft + Windows") by Processes.dest Processes.user Processes.parent_process_name Processes.process_name + Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `linux_service_started_or_enabled_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -44,6 +42,7 @@ tags: - Linux Persistence Techniques - Linux Living Off The Land - Scheduled Tasks + - Gomir asset_type: Endpoint confidence: 70 impact: 60 @@ -74,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_setuid_using_chmod_utility.yml b/detections/endpoint/linux_setuid_using_chmod_utility.yml index c0b8e30144..661c9931e7 100644 --- a/detections/endpoint/linux_setuid_using_chmod_utility.yml +++ b/detections/endpoint/linux_setuid_using_chmod_utility.yml @@ -1,19 +1,18 @@ name: Linux Setuid Using Chmod Utility id: bf0304b6-6250-11ec-9d7c-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious chmod utility execution to enable - SUID bit. This allows a user to temporarily gain root access, usually in order to - run a program. For example, only the root account is allowed to change the password - information contained in the password database; If the SUID bit appears as an s, - the file's owner also has execute permission to the file; if it appears as an S, - the file's owner does not have execute permission. The second specialty permission - is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily - change group membership, usually to execute a program. The SGID bit is set if an - s or an S appears in the group section of permissions. +description: The following analytic detects the execution of the chmod utility to + set the SUID or SGID bit on files, which can allow users to temporarily gain root + or group-level access. This detection leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process names and command-line arguments related + to chmod. This activity is significant as it can indicate an attempt to escalate + privileges or maintain persistence on a system. If confirmed malicious, an attacker + could gain elevated access, potentially compromising sensitive data or critical + system functions. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_setuid_using_setcap_utility.yml b/detections/endpoint/linux_setuid_using_setcap_utility.yml index c0c5c6cb67..a6478eb949 100644 --- a/detections/endpoint/linux_setuid_using_setcap_utility.yml +++ b/detections/endpoint/linux_setuid_using_setcap_utility.yml @@ -1,19 +1,18 @@ name: Linux Setuid Using Setcap Utility id: 9d96022e-6250-11ec-9a19-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic looks for suspicious setcap utility execution to enable - SUID bit. This allows a user to temporarily gain root access, usually in order to - run a program. For example, only the root account is allowed to change the password - information contained in the password database; If the SUID bit appears as an s, - the file's owner also has execute permission to the file; if it appears as an S, - the file's owner does not have execute permission. The second specialty permission - is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily - change group membership, usually to execute a program. The SGID bit is set if an - s or an S appears in the group section of permissions. +description: The following analytic detects the execution of the 'setcap' utility + to enable the SUID bit on Linux systems. It leverages Endpoint Detection and Response + (EDR) data, focusing on process names and command-line arguments that indicate the + use of 'setcap' with specific capabilities. This activity is significant because + setting the SUID bit allows a user to temporarily gain root access, posing a substantial + security risk. If confirmed malicious, an attacker could escalate privileges, execute + arbitrary commands with elevated permissions, and potentially compromise the entire + system. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_setcap/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_setcap/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_shred_overwrite_command.yml b/detections/endpoint/linux_shred_overwrite_command.yml index 86a913b9a4..d6af5c9e88 100644 --- a/detections/endpoint/linux_shred_overwrite_command.yml +++ b/detections/endpoint/linux_shred_overwrite_command.yml @@ -1,17 +1,18 @@ name: Linux Shred Overwrite Command id: c1952cf1-643c-4965-82de-11c067cbae76 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a shred process to overwrite a files in a - linux machine. Shred Linux application is designed to overwrite file to hide its - contents or make the deleted file un-recoverable. Weve seen this technique in industroyer2 - malware that tries to wipe energy facilities of targeted sector as part of its destructive - attack. It might be some normal user may use this command for valid purposes but - it is recommended to check what files, disk or folder it tries to shred that might - be good pivot for incident response in this type of destructive malware. +description: The following analytic detects the execution of the 'shred' command on + a Linux machine, which is used to overwrite files to make them unrecoverable. It + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + names and command-line arguments. This activity is significant because the 'shred' + command can be used in destructive attacks, such as those seen in the Industroyer2 + malware targeting energy facilities. If confirmed malicious, this activity could + lead to the permanent destruction of critical files, severely impacting system integrity + and data availability. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_sqlite3_privilege_escalation.yml b/detections/endpoint/linux_sqlite3_privilege_escalation.yml index 0ab89bd45f..24fd1e2fed 100644 --- a/detections/endpoint/linux_sqlite3_privilege_escalation.yml +++ b/detections/endpoint/linux_sqlite3_privilege_escalation.yml @@ -1,15 +1,18 @@ name: Linux Sqlite3 Privilege Escalation id: ab75dbb7-c3ba-4689-9c1b-8d2717bdcba1 -version: 1 -date: '2022-08-11' +version: 2 +date: '2024-05-13' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly -description: sqlite3 is a terminal-based front-end to the SQLite library that can - evaluate queries interactively and display the results in multiple formats. sqlite3 - can also be used within shell scripts and other applications to provide batch processing - features. If sudo right is given to this application for the user, then the user - can run system commands as root and possibly get a root shell. +description: The following analytic detects the execution of the sqlite3 command with + elevated privileges, which can be exploited for privilege escalation. It leverages + Endpoint Detection and Response (EDR) telemetry to identify instances where sqlite3 + is used in conjunction with shell commands and sudo. This activity is significant + because it indicates a potential attempt to gain root access, which could lead to + full system compromise. If confirmed malicious, an attacker could execute arbitrary + commands as root, leading to unauthorized access, data exfiltration, or further + lateral movement within the network. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/sqlite3/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/sqlite3/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ssh_authorized_keys_modification.yml b/detections/endpoint/linux_ssh_authorized_keys_modification.yml index 605511721a..2caccf2eb4 100644 --- a/detections/endpoint/linux_ssh_authorized_keys_modification.yml +++ b/detections/endpoint/linux_ssh_authorized_keys_modification.yml @@ -87,5 +87,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/authkey_linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_ssh_remote_services_script_execute.yml b/detections/endpoint/linux_ssh_remote_services_script_execute.yml index 4709d20a5f..9e13bd446e 100644 --- a/detections/endpoint/linux_ssh_remote_services_script_execute.yml +++ b/detections/endpoint/linux_ssh_remote_services_script_execute.yml @@ -82,5 +82,5 @@ tests: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.004/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_stdout_redirection_to_dev_null_file.yml b/detections/endpoint/linux_stdout_redirection_to_dev_null_file.yml index a44c4940b0..4fe80ecb18 100644 --- a/detections/endpoint/linux_stdout_redirection_to_dev_null_file.yml +++ b/detections/endpoint/linux_stdout_redirection_to_dev_null_file.yml @@ -1,16 +1,18 @@ name: Linux Stdout Redirection To Dev Null File id: de62b809-a04d-46b5-9a15-8298d330f0c8 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: experimental type: Anomaly -description: This analytic looks for suspicious commandline that redirect the stdout - or possible stderror to dev/null file. This technique was seen in cyclopsblink malware - where it redirect the possible output or error while modify the iptables firewall - setting of the compromised machine to hide its action from the user. This Anomaly - detection is a good pivot to look further why process or user use this un common - approach. +description: The following analytic detects command-line activities that redirect + stdout or stderr to the /dev/null file. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs. This behavior is + significant as it can indicate attempts to hide command outputs, a technique observed + in the CyclopsBlink malware to conceal modifications to iptables firewall settings. + If confirmed malicious, this activity could allow an attacker to stealthily alter + system configurations, potentially leading to unauthorized access or persistent + control over the compromised machine. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_stop_services.yml b/detections/endpoint/linux_stop_services.yml index 3a00cf09fa..28b9aee7f8 100644 --- a/detections/endpoint/linux_stop_services.yml +++ b/detections/endpoint/linux_stop_services.yml @@ -1,15 +1,18 @@ name: Linux Stop Services id: d05204a5-9f1c-4946-a7f3-4fa58d76d5fd -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is to detect events that attempt to stop or clear - a service. This is typically identified in parallel with other instances of service - enumeration of attempts to stop a service and then delete it. Adversaries utilize - this technique like industroyer2 malware to terminate security services or other - related services to continue there objective as a destructive payload. +description: The following analytic detects attempts to stop or clear a service on + Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on processes like "systemctl," "service," and "svcadm" executing stop commands. + This activity is significant as adversaries often terminate security or critical + services to disable defenses or disrupt operations, as seen in malware like Industroyer2. + If confirmed malicious, this could lead to the disabling of security mechanisms, + allowing attackers to persist, escalate privileges, or deploy destructive payloads, + severely impacting system integrity and availability. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_sudo_or_su_execution.yml b/detections/endpoint/linux_sudo_or_su_execution.yml index 5a640e75a3..323969cbee 100644 --- a/detections/endpoint/linux_sudo_or_su_execution.yml +++ b/detections/endpoint/linux_sudo_or_su_execution.yml @@ -1,18 +1,18 @@ name: Linux Sudo OR Su Execution id: 4b00f134-6d6a-11ec-a90c-acde48001122 -version: 1 -date: '2022-01-04' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic is to detect the execution of sudo or su command in linux - operating system. The "sudo" command allows a system administrator to delegate authority - to give certain users (or groups of users) the ability to run some (or all) commands - as root or another user while providing an audit trail of the commands and their - arguments. This command is commonly abused by adversaries, malware author and red - teamers to elevate privileges to the targeted host. This command can be executed - by administrator for legitimate purposes or to execute process that need admin privileges, - In this scenario filter is needed. +description: The following analytic detects the execution of the "sudo" or "su" command + on a Linux operating system. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and parent process names. This activity + is significant because "sudo" and "su" commands are commonly used by adversaries + to elevate privileges, potentially leading to unauthorized access or control over + the system. If confirmed malicious, this activity could allow attackers to execute + commands with root privileges, leading to severe security breaches, data exfiltration, + or further system compromise. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudo_su/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudo_su/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_sudoers_tmp_file_creation.yml b/detections/endpoint/linux_sudoers_tmp_file_creation.yml index 9da64e71d5..8e3da22f96 100644 --- a/detections/endpoint/linux_sudoers_tmp_file_creation.yml +++ b/detections/endpoint/linux_sudoers_tmp_file_creation.yml @@ -1,17 +1,18 @@ name: Linux Sudoers Tmp File Creation id: be254a5c-63e7-11ec-89da-acde48001122 -version: 1 -date: '2021-12-23' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to looks for file creation of sudoers.tmp file cause - by editing /etc/sudoers using visudo or editor in linux platform. This technique - may abuse by adversaries, malware author and red teamers to gain elevated privilege - to targeted or compromised host. /etc/sudoers file controls who can run what commands - as what users on what machines and can also control special things such as whether - you need a password for particular commands. The file is composed of aliases (basically - variables) and user specifications (which control who can run what). +description: The following analytic detects the creation of the "sudoers.tmp" file, + which occurs when editing the /etc/sudoers file using visudo or another editor on + a Linux platform. This detection leverages filesystem data to identify the presence + of "sudoers.tmp" files. Monitoring this activity is crucial as adversaries may exploit + it to gain elevated privileges on a compromised host. If confirmed malicious, this + activity could allow attackers to modify sudoers configurations, potentially granting + them unauthorized access to execute commands as other users, including root, thereby + compromising the system's security. data_source: - Sysmon for Linux EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -59,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudoers_temp/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudoers_temp/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_system_network_discovery.yml b/detections/endpoint/linux_system_network_discovery.yml index b4ecf7fb3d..6247fc97d8 100644 --- a/detections/endpoint/linux_system_network_discovery.yml +++ b/detections/endpoint/linux_system_network_discovery.yml @@ -1,15 +1,18 @@ name: Linux System Network Discovery id: 535cb214-8b47-11ec-a2c7-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for possible enumeration of local network configuration. - This technique is commonly used as part of recon of adversaries or threat actor - to know some network information for its next or further attack. This anomaly detections - may capture normal event made by administrator during auditing or testing network - connection of specific host or network to network. +description: The following analytic identifies potential enumeration of local network + configuration on Linux systems. It detects this activity by monitoring processes + such as "arp," "ifconfig," "ip," "netstat," "firewall-cmd," "ufw," "iptables," "ss," + and "route" within a 30-minute window. This behavior is significant as it often + indicates reconnaissance efforts by adversaries to gather network information for + subsequent attacks. If confirmed malicious, this activity could enable attackers + to map the network, identify vulnerabilities, and plan further exploitation or lateral + movement within the environment. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1016/atomic_red_team/linux_net_discovery/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1016/atomic_red_team/linux_net_discovery/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/linux_system_reboot_via_system_request_key.yml b/detections/endpoint/linux_system_reboot_via_system_request_key.yml index bf374eba9b..6351f75b97 100644 --- a/detections/endpoint/linux_system_reboot_via_system_request_key.yml +++ b/detections/endpoint/linux_system_reboot_via_system_request_key.yml @@ -1,17 +1,17 @@ name: Linux System Reboot Via System Request Key id: e1912b58-ed9c-422c-bbb0-2dbc70398345 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to look for possible execution of SysReq hack to reboot - the Linux system host. This technique was seen in Awfulshred malware wiper to reboot - the compromised host by using the linux magic sysreq key. This kernel configuration - can trigger reboot by piping out 'b' to /proc/sysrq-trigger after enabling all the - functions of sysrq. This TTP detection can be a good indicator of possible suspicious - processes running on the Linux host since this command is not a common way to reboot - a system. +description: The following analytic detects the execution of the SysReq hack to reboot + a Linux system host. It leverages Endpoint Detection and Response (EDR) data to + identify processes executing the command to pipe 'b' to /proc/sysrq-trigger. This + activity is significant as it is an uncommon method to reboot a system and was observed + in the Awfulshred malware wiper. If confirmed malicious, this technique could indicate + the presence of suspicious processes and potential system compromise, leading to + unauthorized reboots and disruption of services. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test2/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test2/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_unix_shell_enable_all_sysrq_functions.yml b/detections/endpoint/linux_unix_shell_enable_all_sysrq_functions.yml index ea5df8e816..6f248fd7e4 100644 --- a/detections/endpoint/linux_unix_shell_enable_all_sysrq_functions.yml +++ b/detections/endpoint/linux_unix_shell_enable_all_sysrq_functions.yml @@ -1,17 +1,18 @@ name: Linux Unix Shell Enable All SysRq Functions id: e7a96937-3b58-4962-8dce-538e4763cf15 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for possible execution of SysReq hack to enable - all functions of kernel system requests of the Linux system host. This technique - was seen in AwfulShred malware wiper to reboot the compromised host by using the - linux magic sysreq key. This kernel configuration can be triggered by piping out - bitmask '1' to /proc/sys/kernel/sysrq. This TTP detection can be a good indicator - of possible suspicious processes running on the Linux host since this command is - not so common shell commandline. +description: The following analytic detects the execution of a command to enable all + SysRq functions on a Linux system, a technique associated with the AwfulShred malware. + It leverages Endpoint Detection and Response (EDR) data to identify processes executing + the command to pipe bitmask '1' to /proc/sys/kernel/sysrq. This activity is significant + as it can indicate an attempt to manipulate kernel system requests, which is uncommon + and potentially malicious. If confirmed, this could allow an attacker to reboot + the system or perform other critical actions, leading to system instability or further + compromise. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test2/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/awfulshred/test2/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/detections/endpoint/linux_visudo_utility_execution.yml b/detections/endpoint/linux_visudo_utility_execution.yml index e3b26645f6..106f4f8587 100644 --- a/detections/endpoint/linux_visudo_utility_execution.yml +++ b/detections/endpoint/linux_visudo_utility_execution.yml @@ -1,17 +1,18 @@ name: Linux Visudo Utility Execution id: 08c41040-624c-11ec-a71f-acde48001122 -version: 1 -date: '2021-12-21' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to looks for suspicious commandline that add entry to - /etc/sudoers by using visudo utility tool in linux platform. This technique may - abuse by adversaries, malware author and red teamers to gain elevated privilege - to targeted or compromised host. /etc/sudoers file controls who can run what commands - as what users on what machines and can also control special things such as whether - you need a password for particular commands. The file is composed of aliases (basically - variables) and user specifications (which control who can run what). +description: The following analytic detects the execution of the 'visudo' utility + to modify the /etc/sudoers file on a Linux system. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process execution logs. This activity + is significant because unauthorized changes to the /etc/sudoers file can grant elevated + privileges to users, potentially allowing adversaries to execute commands as root. + If confirmed malicious, this could lead to full system compromise, privilege escalation, + and persistent unauthorized access, severely impacting the security posture of the + affected host. data_source: - Sysmon for Linux EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/visudo/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/visudo/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/loading_of_dynwrapx_module.yml b/detections/endpoint/loading_of_dynwrapx_module.yml index 22176b4a25..2e3c85aa3e 100644 --- a/detections/endpoint/loading_of_dynwrapx_module.yml +++ b/detections/endpoint/loading_of_dynwrapx_module.yml @@ -1,18 +1,18 @@ name: Loading Of Dynwrapx Module id: eac5e8ba-4857-11ec-9371-acde48001122 -version: 1 -date: '2021-11-18' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: DynamicWrapperX is an ActiveX component that can be used in a script - to call Windows API functions, but it requires the dynwrapx.dll to be installed - and registered. With that, registering or loading dynwrapx.dll to a host is highly - suspicious. In most instances when it is used maliciously, the best way to triage - is to review parallel processes and pivot on the process_guid. Review the registry - for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious - module loads of dynwrapx.dll. This detection will return and identify the processes - that invoke vbs/wscript/cscript. +description: The following analytic detects the loading of the dynwrapx.dll module, + which is associated with the DynamicWrapperX ActiveX component. This detection leverages + Sysmon EventCode 7 to identify processes that load or register dynwrapx.dll. This + activity is significant because DynamicWrapperX can be used to call Windows API + functions in scripts, making it a potential tool for malicious actions. If confirmed + malicious, this could allow an attacker to execute arbitrary code, escalate privileges, + or maintain persistence on the host. Immediate investigation of parallel processes + and registry modifications is recommended. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 (ImageLoaded = "*\\dynwrapx.dll" OR OriginalFileName @@ -72,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_dynwrapx/sysmon_dynwraper.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_dynwrapx/sysmon_dynwraper.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/local_account_discovery_with_net.yml b/detections/endpoint/local_account_discovery_with_net.yml index 4763b43fe4..11f6fcf8f6 100644 --- a/detections/endpoint/local_account_discovery_with_net.yml +++ b/detections/endpoint/local_account_discovery_with_net.yml @@ -1,14 +1,18 @@ name: Local Account Discovery with Net id: 5d0d4830-0133-11ec-bae3-acde48001122 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `net.exe` or `net1.exe` with - command-line arguments utilized to query for local users. The two arguments `user` - and 'users', return a list of all local users. Red Teams and adversaries alike use - net.exe to enumerate users for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `net.exe` or `net1.exe` + with command-line arguments `user` or `users` to query local user accounts. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant as it indicates potential + reconnaissance efforts by adversaries to enumerate local users, which is a common + step in situational awareness and Active Directory discovery. If confirmed malicious, + this behavior could lead to further attacks, including privilege escalation and + lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -56,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/local_account_discovery_with_wmic.yml b/detections/endpoint/local_account_discovery_with_wmic.yml index c0016b5537..b00c30fc36 100644 --- a/detections/endpoint/local_account_discovery_with_wmic.yml +++ b/detections/endpoint/local_account_discovery_with_wmic.yml @@ -1,14 +1,18 @@ name: Local Account Discovery With Wmic id: 4902d7aa-0134-11ec-9d65-acde48001122 -version: 2 -date: '2021-09-16' +version: 3 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `wmic.exe` with command-line - arguments utilized to query for local users. The argument `useraccount` is used - to leverage WMI to return a list of all local users. Red Teams and adversaries alike - use net.exe to enumerate users for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `wmic.exe` with command-line + arguments used to query local user accounts, specifically the `useraccount` argument. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process execution logs that include command-line details. This activity is significant + as it indicates potential reconnaissance efforts by adversaries to enumerate local + users, which is a common step in situational awareness and Active Directory discovery. + If confirmed malicious, this behavior could lead to further targeted attacks, privilege + escalation, or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -54,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.001/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/log4shell_cve_2021_44228_exploitation.yml b/detections/endpoint/log4shell_cve_2021_44228_exploitation.yml index 78fc5aa558..d58be5a40a 100644 --- a/detections/endpoint/log4shell_cve_2021_44228_exploitation.yml +++ b/detections/endpoint/log4shell_cve_2021_44228_exploitation.yml @@ -1,23 +1,19 @@ name: Log4Shell CVE-2021-44228 Exploitation id: 9be30d80-3a39-4df9-9102-64a467b24eac -version: 3 -date: '2022-09-09' +version: 4 +date: '2024-05-26' author: Jose Hernandez, Splunk status: production type: Correlation -description: This correlation find exploitation of Log4Shell CVE-2021-44228 against - systems using detections from Splunk Security Content Analytic Story. It does this - by calculating the distinct count of MITRE ATT&CK tactics from Log4Shell detections - fired. If the count is larger than 2 or more distinct MITRE ATT&CK tactics we assume - high problability of exploitation. The Analytic story breaks down into 3 major phases - of a Log4Shell exploitation, specifically> Initial Payload delivery eg. `${jndi:ldap://PAYLOAD_INJECTED}` - Call back to malicious LDAP server eg. Exploit.class Post Exploitation Activity/Lateral - Movement using Powershell or similar T1562.001 Each of these phases fall into different - MITRE ATT&CK Tactics (Initial Access, Execution, Command And Control), by looking - into 2 or more phases showing up in detections triggerd is how this correlation - search finds exploitation. If we get a notable from this correlation search the - best way to triage it is by investigating the affected systems against Log4Shell - exploitation using Splunk SOAR playbooks. +description: The following analytic identifies potential exploitation of Log4Shell + CVE-2021-44228 by correlating multiple MITRE ATT&CK tactics detected in risk events. + It leverages Splunk's risk data model to calculate the distinct count of MITRE ATT&CK + tactics from Log4Shell-related detections. This activity is significant because + it indicates a high probability of exploitation if two or more distinct tactics + are observed. If confirmed malicious, this activity could lead to initial payload + delivery, callback to a malicious server, and post-exploitation activities, potentially + resulting in unauthorized access, lateral movement, and further compromise of the + affected systems. data_source: [] search: '| 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) @@ -75,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/suspicious_behaviour/log4shell_exploitation/log4shell_correlation.txt + - data: + https://raw.githubusercontent.com/splunk/attack_data/master/datasets/suspicious_behaviour/log4shell_exploitation/log4shell_correlation.txt source: log4shell sourcetype: stash diff --git a/detections/endpoint/logon_script_event_trigger_execution.yml b/detections/endpoint/logon_script_event_trigger_execution.yml index c4a9010289..91c271f74f 100644 --- a/detections/endpoint/logon_script_event_trigger_execution.yml +++ b/detections/endpoint/logon_script_event_trigger_execution.yml @@ -1,14 +1,18 @@ name: Logon Script Event Trigger Execution id: 4c38c264-1f74-11ec-b5fa-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious modification of registry entry - to persist and gain privilege escalation upon booting up of compromised host. This - technique was seen in several APT and malware where it modify UserInitMprLogonScript - registry entry to its malicious payload to be executed upon boot up of the machine. +description: The following analytic detects the modification of the UserInitMprLogonScript + registry entry, which is often used by attackers to establish persistence and gain + privilege escalation upon system boot. It leverages data from the Endpoint.Registry + data model, focusing on changes to the specified registry path. This activity is + significant because it is a common technique used by APT groups and malware to ensure + their payloads execute automatically when the system starts. If confirmed malicious, + this could allow attackers to maintain persistent access and potentially escalate + their privileges on the compromised host. data_source: - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime @@ -63,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1037.001/logonscript_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1037.001/logonscript_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/lolbas_with_network_traffic.yml b/detections/endpoint/lolbas_with_network_traffic.yml index ba3455eddc..d60a07c41e 100644 --- a/detections/endpoint/lolbas_with_network_traffic.yml +++ b/detections/endpoint/lolbas_with_network_traffic.yml @@ -1,15 +1,18 @@ name: LOLBAS With Network Traffic id: 2820f032-19eb-497e-8642-25b04a880359 -version: 1 -date: '2021-12-09' +version: 2 +date: '2024-05-11' author: Steven Dick status: production type: TTP -description: The following analytic identifies LOLBAS with network traffic. When adversaries - abuse LOLBAS they are often used to download malicious code or executables. The - LOLBAS project documents Windows native binaries that can be abused by threat actors - to perform tasks like downloading malicious code. Looking for these process can - help defenders identify lateral movement, command-and-control, or exfiltration activies. +description: The following analytic identifies the use of Living Off the Land Binaries + and Scripts (LOLBAS) with network traffic. It leverages data from the Network Traffic + data model to detect when native Windows binaries, often abused by adversaries, + initiate network connections. This activity is significant as LOLBAS are frequently + used to download malicious payloads, enabling lateral movement, command-and-control, + or data exfiltration. If confirmed malicious, this behavior could allow attackers + to execute arbitrary code, escalate privileges, or maintain persistence within the + environment, posing a severe threat to organizational security. data_source: - Sysmon EventID 3 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,7 +88,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/lolbas_with_network_traffic/lolbas_with_network_traffic.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/lolbas_with_network_traffic/lolbas_with_network_traffic.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/malicious_inprocserver32_modification.yml b/detections/endpoint/malicious_inprocserver32_modification.yml index 0af57baf31..602e7ee42d 100644 --- a/detections/endpoint/malicious_inprocserver32_modification.yml +++ b/detections/endpoint/malicious_inprocserver32_modification.yml @@ -1,22 +1,17 @@ name: Malicious InProcServer32 Modification id: 127c8d08-25ff-11ec-9223-acde48001122 -version: 1 -date: '2021-10-05' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a process modifying the registry with - a known malicious CLSID under InProcServer32. Most COM classes are registered with - the operating system and are identified by a GUID that represents the Class Identifier - (CLSID) within the registry (usually under HKLM\\Software\\Classes\\CLSID or HKCU\\Software\\Classes\\CLSID). Behind - the implementation of a COM class is the server (some binary) that is referenced - within registry keys under the CLSID. The LocalServer32 key represents a path to - an executable (exe) implementation, and the InprocServer32 key represents a path - to a dynamic link library (DLL) implementation (Bohops). During triage, review parallel - processes for suspicious activity. Pivot on the process GUID to see the full timeline - of events. Analyze the value and look for file modifications. Being this is looking - for inprocserver32, a DLL found in the value will most likely be loaded by a parallel - process. +description: The following analytic detects a process modifying the registry with + a known malicious CLSID under InProcServer32. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on registry modifications within the HKLM or + HKCU Software Classes CLSID paths. This activity is significant as it may indicate + an attempt to load a malicious DLL, potentially leading to code execution. If confirmed + malicious, this could allow an attacker to persist in the environment, execute arbitrary + code, or escalate privileges, posing a severe threat to system integrity and security. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -87,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/malicious_powershell_process___encoded_command.yml b/detections/endpoint/malicious_powershell_process___encoded_command.yml index 56b2022684..92ea9118aa 100644 --- a/detections/endpoint/malicious_powershell_process___encoded_command.yml +++ b/detections/endpoint/malicious_powershell_process___encoded_command.yml @@ -1,32 +1,27 @@ name: Malicious PowerShell Process - Encoded Command id: c4db14d9-7909-48b4-a054-aa14d89dbb19 -version: 7 -date: '2022-01-18' +version: 8 +date: '2024-05-19' author: David Dorsey, Michael Haag, Splunk status: production type: Hunting -description: 'The following analytic identifies the use of the EncodedCommand PowerShell - parameter. This is typically used by Administrators to run complex scripts, but - commonly used by adversaries to hide their code. - - The analytic identifies all variations of EncodedCommand, as PowerShell allows the - ability to shorten the parameter. For example enc, enco, encod and so forth. In - addition, through our research it was identified that PowerShell will interpret - different command switch types beyond the hyphen. We have added endash, emdash, - horizontal bar, and forward slash. - - During triage, review parallel events to determine legitimacy. Tune as needed based - on admin scripts in use. - - Alternatively, may use regex per matching here https://regexr.com/662ov.' +description: 'The following analytic detects the use of the EncodedCommand parameter + in PowerShell processes. It leverages Endpoint Detection and Response (EDR) data + to identify variations of the EncodedCommand parameter, including shortened forms + and different command switch types. This activity is significant because adversaries + often use encoded commands to obfuscate malicious scripts, making detection harder. + If confirmed malicious, this behavior could allow attackers to execute hidden code, + potentially leading to unauthorized access, privilege escalation, or persistent + threats within the environment. Review parallel events to determine legitimacy and + tune based on known administrative scripts.' data_source: - Sysmon EventID 1 search: "| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_powershell` by Processes.user Processes.process_name Processes.process Processes.parent_process_name Processes.original_file_name Processes.dest Processes.process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | where match(process,\"(?i)[\\-|\\/|\u2013 - |\u2014|\u2015]e(nc*o*d*e*d*c*o*m*m*a*n*d*)*\\s+[^-]\") | `malicious_powershell_process___encoded_command_filter`" + | `security_content_ctime(lastTime)` | where match(process,\"(?i)[\\-|\\/|– |—|―]e(nc*o*d*e*d*c*o*m*m*a*n*d*)*\\\ + s+[^-]\") | `malicious_powershell_process___encoded_command_filter`" how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -84,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/mimikatz_passtheticket_commandline_parameters.yml b/detections/endpoint/mimikatz_passtheticket_commandline_parameters.yml index 1e9ed53316..b2a5e25b11 100644 --- a/detections/endpoint/mimikatz_passtheticket_commandline_parameters.yml +++ b/detections/endpoint/mimikatz_passtheticket_commandline_parameters.yml @@ -1,16 +1,18 @@ name: Mimikatz PassTheTicket CommandLine Parameters id: 13bbd574-83ac-11ec-99d4-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-30' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic looks for the use of Mimikatz command line parameters - leveraged to execute pass the ticket attacks. Red teams and adversaries alike may - use the pass the ticket technique using stolen Kerberos tickets to move laterally - within an environment, bypassing normal system access controls. Defenders should - be aware that adversaries may customize the source code of Mimikatz and modify the - command line parameters. This would effectively bypass this analytic. +description: The following analytic detects the use of Mimikatz command line parameters + associated with pass-the-ticket attacks. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on specific command-line patterns related to + Kerberos ticket manipulation. This activity is significant because pass-the-ticket + attacks allow adversaries to move laterally within an environment using stolen Kerberos + tickets, bypassing normal access controls. If confirmed malicious, this could enable + attackers to escalate privileges, access sensitive information, and maintain persistence + within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/mimikatz/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/mimikatz/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/mmc_lolbas_execution_process_spawn.yml b/detections/endpoint/mmc_lolbas_execution_process_spawn.yml index dc728ce0f4..300a40f2d2 100644 --- a/detections/endpoint/mmc_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/mmc_lolbas_execution_process_spawn.yml @@ -1,17 +1,18 @@ name: Mmc LOLBAS Execution Process Spawn id: f6601940-4c74-11ec-b9b7-3e22fbd008af -version: 1 -date: '2021-11-23' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP description: The following analytic identifies `mmc.exe` spawning a LOLBAS execution - process. When adversaries execute code on remote endpoints abusing the DCOM protocol - and the MMC20 COM object, the executed command is spawned as a child processs of - `mmc.exe`. The LOLBAS project documents Windows native binaries that can be abused - by threat actors to perform tasks like executing malicious code. Looking for child - processes of mmc.exe that are part of the LOLBAS project can help defenders identify - lateral movement activity. + process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process creation events where `mmc.exe` is the parent process. This activity + is significant because adversaries can abuse the DCOM protocol and MMC20 COM object + to execute malicious code, using Windows native binaries documented by the LOLBAS + project. If confirmed malicious, this behavior could indicate lateral movement, + allowing attackers to execute code remotely, potentially leading to further compromise + and persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/lateral_movement_lolbas/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/lateral_movement_lolbas/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/modification_of_wallpaper.yml b/detections/endpoint/modification_of_wallpaper.yml index b7f50e63ec..d82dc62ae6 100644 --- a/detections/endpoint/modification_of_wallpaper.yml +++ b/detections/endpoint/modification_of_wallpaper.yml @@ -1,23 +1,28 @@ name: Modification Of Wallpaper id: accb0712-c381-11eb-8e5b-acde48001122 -version: 1 -date: '2021-06-02' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies suspicious modification of registry to deface - or change the wallpaper of a compromised machines as part of its payload. This technique - was commonly seen in ransomware like REVIL where it create a bitmap file contain - a note that the machine was compromised and make it as a wallpaper. +description: The following analytic detects the modification of registry keys related + to the desktop wallpaper settings. It leverages Sysmon EventCode 13 to identify + changes to the "Control Panel\\Desktop\\Wallpaper" and "Control Panel\\Desktop\\WallpaperStyle" + registry keys, especially when the modifying process is not explorer.exe or involves + suspicious file paths like temp or public directories. This activity is significant + as it can indicate ransomware behavior, such as the REVIL ransomware, which changes + the wallpaper to display a ransom note. If confirmed malicious, this could signify + a compromised machine and the presence of ransomware, leading to potential data + encryption and extortion. data_source: - Sysmon EventID 13 -search: '`sysmon` EventCode =13 (TargetObject IN ("*\\Control Panel\\Desktop\\Wallpaper","*\\Control Panel\\Desktop\\WallpaperStyle") AND Image != "*\\explorer.exe") - OR (TargetObject IN ("*\\Control Panel\\Desktop\\Wallpaper","*\\Control Panel\\Desktop\\WallpaperStyle") AND Details IN ("*\\temp\\*", "*\\users\\public\\*")) - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Image TargetObject Details Computer process_guid process_id user_id - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `modification_of_wallpaper_filter`' +search: '`sysmon` EventCode =13 (TargetObject IN ("*\\Control Panel\\Desktop\\Wallpaper","*\\Control + Panel\\Desktop\\WallpaperStyle") AND Image != "*\\explorer.exe") OR (TargetObject + IN ("*\\Control Panel\\Desktop\\Wallpaper","*\\Control Panel\\Desktop\\WallpaperStyle") + AND Details IN ("*\\temp\\*", "*\\users\\public\\*")) | stats count min(_time) as + firstTime max(_time) as lastTime by EventCode Image TargetObject Details Computer + process_guid process_id user_id | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `modification_of_wallpaper_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Image, TargetObject registry key, registry Details from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. @@ -65,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/modify_acl_permission_to_files_or_folder.yml b/detections/endpoint/modify_acl_permission_to_files_or_folder.yml index 14fefa4508..3e43502335 100644 --- a/detections/endpoint/modify_acl_permission_to_files_or_folder.yml +++ b/detections/endpoint/modify_acl_permission_to_files_or_folder.yml @@ -1,16 +1,17 @@ name: Modify ACL permission To Files Or Folder id: 7e8458cc-acca-11eb-9e3f-acde48001122 -version: 2 -date: '2022-03-17' +version: 3 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic identifies suspicious modification of ACL permission to - a files or folder to make it available to everyone. This technique may be used by - the adversary to evade ACLs or protected files access. This changes is commonly - configured by the file or directory owner with appropriate permission. This behavior - is a good indicator if this command seen on a machine utilized by an account with - no permission to do so. +description: The following analytic detects the modification of ACL permissions to + files or folders, making them accessible to everyone. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on processes like "cacls.exe," "icacls.exe," + and "xcacls.exe" with specific command-line arguments. This activity is significant + as it may indicate an adversary attempting to evade ACLs or access protected files. + If confirmed malicious, this could allow unauthorized access to sensitive data, + potentially leading to data breaches or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -64,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/monitor_registry_keys_for_print_monitors.yml b/detections/endpoint/monitor_registry_keys_for_print_monitors.yml index 9018fb8e1c..ad8a2096e8 100644 --- a/detections/endpoint/monitor_registry_keys_for_print_monitors.yml +++ b/detections/endpoint/monitor_registry_keys_for_print_monitors.yml @@ -1,23 +1,26 @@ name: Monitor Registry Keys for Print Monitors id: f5f6af30-7ba7-4295-bfe9-07de87c01bbc -version: 5 -date: '2023-04-27' +version: 6 +date: '2024-05-29' author: Steven Dick, Bhavin Patel, Teoderick Contreras, Splunk status: production type: TTP -description: This search looks for registry activity associated with modifications - to the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors`. In this - scenario, an attacker can load an arbitrary .dll into the print-monitor registry - by giving the full path name to the after.dll. The system will execute the .dll - with elevated (SYSTEM) permissions and will persist after reboot. +description: The following analytic detects modifications to the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors`. + It leverages data from the Endpoint.Registry data model, focusing on events where + the registry path is modified. This activity is significant because attackers can + exploit this registry key to load arbitrary .dll files, which will execute with + elevated SYSTEM permissions and persist after a reboot. If confirmed malicious, + this could allow attackers to maintain persistence, execute code with high privileges, + and potentially compromise the entire system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.action=modified AND Registry.registry_path="*CurrentControlSet\\Control\\Print\\Monitors*") - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `monitor_registry_keys_for_print_monitors_filter`' + BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `monitor_registry_keys_for_print_monitors_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -59,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.010/atomic_red_team/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.010/atomic_red_team/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/ms_exchange_mailbox_replication_service_writing_active_server_pages.yml b/detections/endpoint/ms_exchange_mailbox_replication_service_writing_active_server_pages.yml index eff8fec884..288feba20e 100644 --- a/detections/endpoint/ms_exchange_mailbox_replication_service_writing_active_server_pages.yml +++ b/detections/endpoint/ms_exchange_mailbox_replication_service_writing_active_server_pages.yml @@ -1,31 +1,18 @@ name: MS Exchange Mailbox Replication service writing Active Server Pages id: 985f322c-57a5-11ec-b9ac-acde48001122 -version: 1 -date: '2023-07-10' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: experimental type: TTP -description: 'The following query identifies suspicious .aspx created in 3 paths identified - by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM - group and recently disclosed vulnerablity named ProxyShell. Paths include: `\HttpProxy\owa\auth\`, - `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. The analytic is limited - to process name MSExchangeMailboxReplication.exe, which typically does not write - .aspx files to disk. Upon triage, the suspicious .aspx file will likely look obvious - on the surface. inspect the contents for script code inside. Identify additional - log sources, IIS included, to review source and other potential exploitation. It - is often the case that a particular threat is only applicable to a specific subset - of systems in your environment. Typically analytics to detect those threats are - written without the benefit of being able to only target those systems as well. - Writing analytics against all systems when those behaviors are limited to identifiable - subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability - on Microsoft Exchange Servers. With asset information, a hunter can limit their - analytics to systems that have been identified as Exchange servers. A hunter may - start with the theory that the exchange server is communicating with new systems - that it has not previously. If this theory is run against all publicly facing systems, - the amount of noise it will generate will likely render this theory untenable. However, - using the asset information to limit this analytic to just the Exchange servers - will reduce the noise allowing the hunter to focus only on the systems where this - behavioral change is relevant.' +description: 'The following analytic identifies the creation of suspicious .aspx files + in specific directories associated with Exchange exploitation by the HAFNIUM group + and the ProxyShell vulnerability. It detects this activity by monitoring the MSExchangeMailboxReplication.exe + process, which typically does not write .aspx files. This behavior is significant + as it may indicate an active exploitation attempt on Exchange servers. If confirmed + malicious, attackers could gain unauthorized access, execute arbitrary code, or + maintain persistence within the environment. Immediate investigation and remediation + are crucial to prevent further compromise.' data_source: - Sysmon EventID 1 - Sysmon EventID 11 diff --git a/detections/endpoint/ms_scripting_process_loading_ldap_module.yml b/detections/endpoint/ms_scripting_process_loading_ldap_module.yml index f65000e124..750a86f48a 100644 --- a/detections/endpoint/ms_scripting_process_loading_ldap_module.yml +++ b/detections/endpoint/ms_scripting_process_loading_ldap_module.yml @@ -1,24 +1,24 @@ name: MS Scripting Process Loading Ldap Module id: 0b0c40dc-14a6-11ec-b267-acde48001122 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a suspicious MS scripting process such as wscript.exe - or cscript.exe that loading ldap module to process ldap query. This behavior was - seen in FIN7 implant where it uses javascript to execute ldap query to parse host - information that will send to its C2 server. this anomaly detections is a good initial - step to hunt further a suspicious ldap query or ldap related events to the host - that may give you good information regarding ldap or AD information processing or - might be a attacker. +description: The following analytic detects the execution of MS scripting processes + (wscript.exe or cscript.exe) loading LDAP-related modules (Wldap32.dll, adsldp.dll, + adsldpc.dll). It leverages Sysmon EventCode 7 to identify these specific DLL loads. + This activity is significant as it may indicate an attempt to query LDAP for host + information, a behavior observed in FIN7 implants. If confirmed malicious, this + could allow attackers to gather detailed Active Directory information, potentially + leading to further exploitation or data exfiltration. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode =7 Image IN ("*\\wscript.exe", "*\\cscript.exe") ImageLoaded IN ("*\\Wldap32.dll", "*\\adsldp.dll", "*\\adsldpc.dll") | stats min(_time) as firstTime max(_time) as lastTime count by Image EventCode process_name ProcessId ProcessGuid - Computer ImageLoaded | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `ms_scripting_process_loading_ldap_module_filter`' + Computer ImageLoaded | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `ms_scripting_process_loading_ldap_module_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -61,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/ms_scripting_process_loading_wmi_module.yml b/detections/endpoint/ms_scripting_process_loading_wmi_module.yml index a0fc29d1ec..719ef1f264 100644 --- a/detections/endpoint/ms_scripting_process_loading_wmi_module.yml +++ b/detections/endpoint/ms_scripting_process_loading_wmi_module.yml @@ -1,17 +1,18 @@ name: MS Scripting Process Loading WMI Module id: 2eba3d36-14a6-11ec-a682-acde48001122 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a suspicious MS scripting process such as wscript.exe - or cscript.exe that loading wmi module to process wmi query. This behavior was seen - in FIN7 implant where it uses javascript to execute wmi query to parse host information - that will send to its C2 server. this anomaly detections is a good initial step - to hunt further a suspicious wmi query or wmi related events to the host that may - give you good information regarding process that are commonly using wmi query or - modules or might be an attacker using this technique. +description: The following analytic detects the loading of WMI modules by Microsoft + scripting processes like wscript.exe or cscript.exe. It leverages Sysmon EventCode + 7 to identify instances where these scripting engines load specific WMI-related + DLLs. This activity is significant because it can indicate the presence of malware, + such as the FIN7 implant, which uses JavaScript to execute WMI queries for gathering + host information to send to a C2 server. If confirmed malicious, this behavior could + allow attackers to collect sensitive system information and maintain persistence + within the environment. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode =7 Image IN ("*\\wscript.exe", "*\\cscript.exe") ImageLoaded @@ -62,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_js_2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/msbuild_suspicious_spawned_by_script_process.yml b/detections/endpoint/msbuild_suspicious_spawned_by_script_process.yml index 642f7139e4..8d752de08a 100644 --- a/detections/endpoint/msbuild_suspicious_spawned_by_script_process.yml +++ b/detections/endpoint/msbuild_suspicious_spawned_by_script_process.yml @@ -1,16 +1,19 @@ name: MSBuild Suspicious Spawned By Script Process id: 213b3148-24ea-11ec-93a2-acde48001122 -version: 1 -date: '2021-10-04' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious child process of MSBuild spawned - by Windows Script Host - cscript or wscript. This behavior or event are commonly - seen and used by malware or adversaries to execute malicious msbuild process using - malicious script in the compromised host. During triage, review parallel processes - and identify any file modifications. MSBuild may load a script from the same path - without having command-line arguments. +description: The following analytic detects the suspicious spawning of MSBuild.exe + by Windows Script Host processes (cscript.exe or wscript.exe). This behavior is + often associated with malware or adversaries executing malicious MSBuild processes + via scripts on compromised hosts. The detection leverages Endpoint Detection and + Response (EDR) telemetry, focusing on process creation events where MSBuild is a + child of script hosts. This activity is significant as it may indicate an attempt + to execute malicious code. If confirmed malicious, it could lead to unauthorized + code execution, potentially compromising the host and allowing further malicious + activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -70,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/regsvr32_silent/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/regsvr32_silent/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/mshta_spawning_rundll32_or_regsvr32_process.yml b/detections/endpoint/mshta_spawning_rundll32_or_regsvr32_process.yml index eb0948dbcc..c4779b8195 100644 --- a/detections/endpoint/mshta_spawning_rundll32_or_regsvr32_process.yml +++ b/detections/endpoint/mshta_spawning_rundll32_or_regsvr32_process.yml @@ -1,22 +1,25 @@ name: Mshta spawning Rundll32 OR Regsvr32 Process id: 4aa5d062-e893-11eb-9eb2-acde48001122 -version: 2 -date: '2021-07-19' +version: 3 +date: '2024-05-09' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious mshta.exe process that spawn rundll32 - or regsvr32 child process. This technique was seen in several malware nowadays like - trickbot to load its initial .dll stage loader to execute and download the the actual - trickbot payload. +description: The following analytic detects a suspicious mshta.exe process spawning + rundll32 or regsvr32 child processes. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process GUID, process name, and parent process + fields. This activity is significant as it is a known technique used by malware + like Trickbot to load malicious DLLs and execute payloads. If confirmed malicious, + this behavior could allow attackers to execute arbitrary code, escalate privileges, + or download additional malware, posing a severe threat to the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name - = "mshta.exe" `process_rundll32` OR `process_regsvr32` by Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.process Processes.process_id Processes.process_guid - Processes.user Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` | `mshta_spawning_rundll32_or_regsvr32_process_filter`' + = "mshta.exe" `process_rundll32` OR `process_regsvr32` by Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.process_guid Processes.user Processes.dest | `drop_dm_object_name("Processes")` + | `security_content_ctime(firstTime)` |`security_content_ctime(lastTime)` | `mshta_spawning_rundll32_or_regsvr32_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/spear_phish/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/spear_phish/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/mshtml_module_load_in_office_product.yml b/detections/endpoint/mshtml_module_load_in_office_product.yml index e6ab8c4753..b54ab9b15c 100644 --- a/detections/endpoint/mshtml_module_load_in_office_product.yml +++ b/detections/endpoint/mshtml_module_load_in_office_product.yml @@ -1,26 +1,30 @@ name: MSHTML Module Load in Office Product id: 5f1c168e-118b-11ec-84ff-acde48001122 -version: 3 -date: '2024-03-14' +version: 4 +date: '2024-05-14' author: Michael Haag, Mauricio Velazco, Splunk status: production type: TTP -description: This detection identifies the loading of the mshtml.dll module into - an Office product. This behavior is associated with CVE-2021-40444, where a - malicious document loads ActiveX, thereby activating the MSHTML component. The - vulnerability is found within the MSHTML component itself. During triage, it is important to identify concurrent - processes and document any file modifications for further analysis. +description: The following analytic detects the loading of the mshtml.dll module into + an Office product, which is indicative of CVE-2021-40444 exploitation. It leverages + Sysmon EventID 7 to monitor image loads by specific Office processes. This activity + is significant because it can indicate an attempt to exploit a vulnerability in + the MSHTML component via a malicious document. If confirmed malicious, this could + allow an attacker to execute arbitrary code, potentially leading to system compromise, + data exfiltration, or further network penetration. data_source: - Sysmon EventID 7 -search: '`sysmon` EventID=7 process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","wordpad.exe","wordview.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", "msaccess.exe","Graph.exe","winproj.exe") loaded_file_path IN ("*\\mshtml.dll", "*\\Microsoft.mshtml.dll","*\\IE.Interop.MSHTML.dll","*\\MshtmlDac.dll","*\\MshtmlDed.dll","*\\MshtmlDer.dll") - | stats count min(_time) as firstTime max(_time) as lastTime by user_id, dest, process_name, loaded_file, loaded_file_path, original_file_name, process_guid - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `mshtml_module_load_in_office_product_filter`' +search: '`sysmon` EventID=7 process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","wordpad.exe","wordview.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", + "msaccess.exe","Graph.exe","winproj.exe") loaded_file_path IN ("*\\mshtml.dll", + "*\\Microsoft.mshtml.dll","*\\IE.Interop.MSHTML.dll","*\\MshtmlDac.dll","*\\MshtmlDed.dll","*\\MshtmlDer.dll") + | stats count min(_time) as firstTime max(_time) as lastTime by user_id, dest, process_name, + loaded_file, loaded_file_path, original_file_name, process_guid | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `mshtml_module_load_in_office_product_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process names and image loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: Limited false positives will be present, however, tune as necessary. Some applications may legitimately load mshtml.dll. +known_false_positives: Limited false positives will be present, however, tune as necessary. + Some applications may legitimately load mshtml.dll. references: - https://app.any.run/tasks/36c14029-9df8-439c-bba0-45f2643b0c70/ - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444 @@ -36,7 +40,8 @@ tags: cve: - CVE-2021-40444 impact: 80 - message: An instance of $process_name$ was identified on endpoint $dest$ loading mshtml.dll. + message: An instance of $process_name$ was identified on endpoint $dest$ loading + mshtml.dll. mitre_attack_id: - T1566 - T1566.001 @@ -65,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_mshtml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_mshtml.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/msi_module_loaded_by_non_system_binary.yml b/detections/endpoint/msi_module_loaded_by_non_system_binary.yml index 9800835334..9e694af832 100644 --- a/detections/endpoint/msi_module_loaded_by_non_system_binary.yml +++ b/detections/endpoint/msi_module_loaded_by_non_system_binary.yml @@ -1,28 +1,17 @@ name: MSI Module Loaded by Non-System Binary id: ccb98a66-5851-11ec-b91c-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following hunting analytic identifies `msi.dll` being loaded by - a binary not located in `system32`, `syswow64`, `winsxs` or `windows` paths. This - behavior is most recently related to InstallerFileTakeOver, or CVE-2021-41379, and - DLL side-loading. CVE-2021-41379 requires a binary to be dropped and `msi.dll` to - be loaded by it. To Successful exploitation of this issue happens in four parts - - - 1. Generation of an MSI that will trigger bad behavior. - - 1. Preparing a directory for MSI installation. - - 1. Inducing an error state. - - 1. Racing to introduce a junction and a symlink to trick msiexec.exe to modify the - attacker specified file. - - In addition, `msi.dll` has been abused in DLL side-loading attacks by being loaded - by non-system binaries.' +description: 'The following analytic detects the loading of `msi.dll` by a binary + not located in `system32`, `syswow64`, `winsxs`, or `windows` directories. This + is identified using Sysmon EventCode 7, which logs DLL loads, and filters out legitimate + system paths. This activity is significant as it may indicate exploitation of CVE-2021-41379 + or DLL side-loading attacks, both of which can lead to unauthorized system modifications. + If confirmed malicious, this could allow an attacker to execute arbitrary code, + escalate privileges, or persist within the environment.' data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 ImageLoaded="*\\msi.dll" NOT (Image IN ("*\\System32\\*","*\\syswow64\\*","*\\windows\\*", @@ -75,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/msi_module_load/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/msi_module_load/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/msmpeng_application_dll_side_loading.yml b/detections/endpoint/msmpeng_application_dll_side_loading.yml index 3e0e233627..54cfc12b83 100644 --- a/detections/endpoint/msmpeng_application_dll_side_loading.yml +++ b/detections/endpoint/msmpeng_application_dll_side_loading.yml @@ -1,23 +1,26 @@ name: Msmpeng Application DLL Side Loading id: 8bb3f280-dd9b-11eb-84d5-acde48001122 -version: 3 -date: '2023-03-15' +version: 4 +date: '2024-05-16' author: Teoderick Contreras, Splunk, Sanjay Govind status: production type: TTP -description: This search is to detect a suspicious creation of msmpeng.exe or mpsvc.dll - in non default windows defender folder. This technique was seen - with revil ransomware in Kaseya Supply chain. The approach is to drop an old version - of msmpeng.exe to load the actual payload name as mspvc.dll which will load the - revil ransomware to the compromise machine +description: The following analytic detects the suspicious creation of msmpeng.exe + or mpsvc.dll in non-default Windows Defender folders. It leverages the Endpoint.Filesystem + datamodel to identify instances where these files are created outside their expected + directories. This activity is significant because it is associated with the REvil + ransomware, which uses DLL side-loading to execute malicious payloads. If confirmed + malicious, this could lead to ransomware deployment, resulting in data encryption, + system compromise, and potential data loss or extortion. data_source: - Sysmon EventID 1 search: '|tstats `security_content_summariesonly` values(Filesystem.file_path) as file_path count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem - where (Filesystem.file_name = "msmpeng.exe" OR Filesystem.file_name = "mpsvc.dll") AND NOT - (Filesystem.file_path IN ("*\\Program Files\\windows defender\\*","*\\WinSxS\\*defender-service*","*\\WinSxS\\Temp\\*defender-service*")) by Filesystem.file_create_time - Filesystem.process_id Filesystem.file_name Filesystem.user Filesystem.dest | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `msmpeng_application_dll_side_loading_filter`' + where (Filesystem.file_name = "msmpeng.exe" OR Filesystem.file_name = "mpsvc.dll") AND + NOT (Filesystem.file_path IN ("*\\Program Files\\windows defender\\*","*\\WinSxS\\*defender-service*","*\\WinSxS\\Temp\\*defender-service*")) + by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name Filesystem.user + Filesystem.dest | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `msmpeng_application_dll_side_loading_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. @@ -31,7 +34,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious creation of msmpeng.exe or mpsvc.dll in non default windows defender folder on host - $dest$ + message: Suspicious creation of msmpeng.exe or mpsvc.dll in non default windows + defender folder on host - $dest$ mitre_attack_id: - T1574.002 - T1574 @@ -56,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets//malware/revil/msmpeng_side/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets//malware/revil/msmpeng_side/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/net_profiler_uac_bypass.yml b/detections/endpoint/net_profiler_uac_bypass.yml index 92c34a9386..ea5b0dbdc2 100644 --- a/detections/endpoint/net_profiler_uac_bypass.yml +++ b/detections/endpoint/net_profiler_uac_bypass.yml @@ -1,16 +1,18 @@ name: NET Profiler UAC bypass id: 0252ca80-e30d-11eb-8aa3-acde48001122 -version: 2 -date: '2022-02-18' +version: 3 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect modification of registry to bypass UAC windows - feature. This technique is to add a payload dll path on .NET COR file path that - will be loaded by mmc.exe as soon it was executed. This detection rely on monitoring - the registry key and values in the detection area. It may happened that windows - update some dll related to mmc.exe and add dll path in this registry. In this case - filtering is needed. +description: The following analytic detects modifications to the registry aimed at + bypassing the User Account Control (UAC) feature in Windows. It identifies changes + to the .NET COR_PROFILER_PATH registry key, which can be exploited to load a malicious + DLL via mmc.exe. This detection leverages data from the Endpoint.Registry datamodel, + focusing on specific registry paths and values. Monitoring this activity is crucial + as it can indicate an attempt to escalate privileges or persist within the environment. + If confirmed malicious, this could allow an attacker to execute arbitrary code with + elevated privileges, compromising system integrity. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -58,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/network_connection_discovery_with_net.yml b/detections/endpoint/network_connection_discovery_with_net.yml index 1c64bee970..22ce817b64 100644 --- a/detections/endpoint/network_connection_discovery_with_net.yml +++ b/detections/endpoint/network_connection_discovery_with_net.yml @@ -1,14 +1,18 @@ name: Network Connection Discovery With Net id: 640337e5-6e41-4b7f-af06-9d9eab5e1e2d -version: 1 -date: '2021-09-10' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `net.exe` with command-line - arguments utilized to get a listing of network connections on a compromised system. - Red Teams and adversaries alike may use net.exe for situational awareness and Active - Directory Discovery. +description: The following analytic identifies the execution of `net.exe` or `net1.exe` + with command-line arguments used to list network connections on a compromised system. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process names and command-line executions. This activity is significant as it indicates + potential network reconnaissance by adversaries or Red Teams, aiming to gather situational + awareness and Active Directory information. If confirmed malicious, this behavior + could allow attackers to map the network, identify critical assets, and plan further + attacks, potentially leading to data exfiltration or lateral movement. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/network_connection_discovery_with_netstat.yml b/detections/endpoint/network_connection_discovery_with_netstat.yml index e6cf1a1672..450173c2df 100644 --- a/detections/endpoint/network_connection_discovery_with_netstat.yml +++ b/detections/endpoint/network_connection_discovery_with_netstat.yml @@ -1,14 +1,17 @@ name: Network Connection Discovery With Netstat id: 2cf5cc25-f39a-436d-a790-4857e5995ede -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `netstat.exe` with command-line - arguments utilized to get a listing of network connections on a compromised system. - Red Teams and adversaries alike may use netstat.exe for situational awareness and - Active Directory Discovery. +description: The following analytic detects the execution of `netstat.exe` with command-line + arguments to list network connections on a system. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, command-line executions, + and parent processes. This activity is significant as both Red Teams and adversaries + use `netstat.exe` for situational awareness and Active Directory discovery. If confirmed + malicious, this behavior could allow attackers to map network connections, identify + critical systems, and plan further lateral movement or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1049/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/network_discovery_using_route_windows_app.yml b/detections/endpoint/network_discovery_using_route_windows_app.yml index b9c8b0a8fa..8663d4e1c5 100644 --- a/detections/endpoint/network_discovery_using_route_windows_app.yml +++ b/detections/endpoint/network_discovery_using_route_windows_app.yml @@ -1,14 +1,18 @@ name: Network Discovery Using Route Windows App id: dd83407e-439f-11ec-ab8e-acde48001122 -version: 2 -date: '2024-02-14' +version: 3 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic look for a spawned process of route.exe windows application. - Adversaries and red teams alike abuse this application the recon or do a network - discovery on a target host. but one possible false positive might be an automated - tool used by a system administator or a powershell script in amazon ec2 config services. +description: The following analytic detects the execution of the `route.exe` Windows + application, commonly used for network discovery. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process creation events. This activity + is significant because adversaries often use `route.exe` to map network routes and + identify potential targets within a network. If confirmed malicious, this behavior + could allow attackers to gain insights into network topology, facilitating lateral + movement and further exploitation. Note that false positives may occur due to legitimate + administrative tasks or automated scripts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/network_share_discovery_via_dir_command.yml b/detections/endpoint/network_share_discovery_via_dir_command.yml index 95da75461b..7be5739254 100644 --- a/detections/endpoint/network_share_discovery_via_dir_command.yml +++ b/detections/endpoint/network_share_discovery_via_dir_command.yml @@ -1,30 +1,31 @@ name: Network Share Discovery Via Dir Command id: dc1457d0-1d9b-422e-b5a7-db46c184d9aa -version: 1 -date: '2023-05-23' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Windows Event Log Security 5140 -description: The following analytic identifies object access on Windows administrative SMB shares (Admin$, IPC$, C$). - This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others - to stage service binaries before creating and starting a Windows service on remote - endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral - movement and remote code execution. The IcedID malware family also implements - this behavior to try to infect other machines in the infected network. -search: '`wineventlog_security` EventCode=5140 ShareName IN("\\\\*\\ADMIN$","\\\\*\\C$","*\\\\*\\IPC$") AccessMask= 0x1 - | stats min(_time) as firstTime max(_time) as lastTime count by ShareName IpAddress ObjectType SubjectUserName SubjectDomainName IpPort AccessMask Computer - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects access to Windows administrative SMB shares + (Admin$, IPC$, C$) using the 'dir' command. It leverages Windows Security Event + Logs with EventCode 5140 to identify this activity. This behavior is significant + as it is commonly used by tools like PsExec/PaExec for staging binaries before creating + and starting services on remote endpoints, a technique often employed by adversaries + for lateral movement and remote code execution. If confirmed malicious, this activity + could allow attackers to propagate malware, such as IcedID, across the network, + leading to widespread infection and potential data breaches. +search: '`wineventlog_security` EventCode=5140 ShareName IN("\\\\*\\ADMIN$","\\\\*\\C$","*\\\\*\\IPC$") + AccessMask= 0x1 | stats min(_time) as firstTime max(_time) as lastTime count by + ShareName IpAddress ObjectType SubjectUserName SubjectDomainName IpPort AccessMask + Computer | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `network_share_discovery_via_dir_command_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5140 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. -known_false_positives: System Administrators may use looks like net.exe or "dir commandline" for troubleshooting - or administrations tasks. However, this will typically come only from certain users - and certain systems that can be added to an allow list. +known_false_positives: System Administrators may use looks like net.exe or "dir commandline" + for troubleshooting or administrations tasks. However, this will typically come + only from certain users and certain systems that can be added to an allow list. references: - https://thedfirreport.com/2023/05/22/icedid-macro-ends-in-nokoyawa-ransomware/ tags: @@ -51,7 +52,7 @@ tags: risk_score: 25 required_fields: - _time - - ShareName + - ShareName - IpAddress - ObjectType - SubjectUserName @@ -63,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/net_share_discovery_via_dir/smb_access_security_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/net_share_discovery_via_dir/smb_access_security_xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/network_traffic_to_active_directory_web_services_protocol.yml b/detections/endpoint/network_traffic_to_active_directory_web_services_protocol.yml index b39cd2557b..f3dc6a139b 100644 --- a/detections/endpoint/network_traffic_to_active_directory_web_services_protocol.yml +++ b/detections/endpoint/network_traffic_to_active_directory_web_services_protocol.yml @@ -1,16 +1,23 @@ name: Network Traffic to Active Directory Web Services Protocol id: 68a0056c-34cb-455f-b03d-df935ea62c4f -version: 2 -date: '2024-03-14' +version: 3 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: Hunting data_source: - Sysmon EventID 3 -description: The following analytic identifies network traffic to Active Directory - Web Services Protocol. This protocol is used to manage Active Directory. The analytic is meant to be tuned and filtered to the specific environment. It will assist defenders in identifying suspicious processes accessing port 9389. -search: '| tstats count from datamodel=Network_Traffic where All_Traffic.dest_port=9389 by All_Traffic.src_ip, All_Traffic.dest_ip, All_Traffic.app, All_Traffic.user, All_Traffic.dest_port - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Traffic")` | `network_traffic_to_active_directory_web_services_protocol_filter`' +description: The following analytic identifies network traffic directed to the Active + Directory Web Services Protocol (ADWS) on port 9389. It leverages network traffic + logs, focusing on source and destination IP addresses, application names, and destination + ports. This activity is significant as ADWS is used to manage Active Directory, + and unauthorized access could indicate malicious intent. If confirmed malicious, + an attacker could manipulate Active Directory, potentially leading to privilege + escalation, unauthorized access, or persistent control over the environment. +search: '| tstats count from datamodel=Network_Traffic where All_Traffic.dest_port=9389 + by All_Traffic.src_ip, All_Traffic.dest_ip, All_Traffic.app, All_Traffic.user, All_Traffic.dest_port + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Traffic")` + | `network_traffic_to_active_directory_web_services_protocol_filter`' how_to_implement: The detection is based on data that originates from network traffic logs. The logs must contain the source and destination IP addresses, the application name, and the destination port. The logs must be processed using the appropriate @@ -18,8 +25,10 @@ how_to_implement: The detection is based on data that originates from network tr The logs must also be mapped to the `Network_Traffic` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives should be limited as the destination port - is specific to Active Directory Web Services Protocol, however we recommend utilizing this analytic to hunt for non-standard processes querying the ADWS port. Filter by App or dest_ip to AD servers and remove known proceses querying ADWS. +known_false_positives: False positives should be limited as the destination port is + specific to Active Directory Web Services Protocol, however we recommend utilizing + this analytic to hunt for non-standard processes querying the ADWS port. Filter + by App or dest_ip to AD servers and remove known proceses querying ADWS. references: - https://github.com/FalconForceTeam/SOAPHound tags: @@ -29,7 +38,8 @@ tags: atomic_guid: [] confidence: 50 impact: 20 - message: Network traffic to Active Directory Web Services Protocol was identified on $dest_ip$ by $src_ip$. + message: Network traffic to Active Directory Web Services Protocol was identified + on $dest_ip$ by $src_ip$. mitre_attack_id: - T1087.002 - T1069.001 @@ -62,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/soaphound/sysmon_soaphound.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/soaphound/sysmon_soaphound.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/nishang_powershelltcponeline.yml b/detections/endpoint/nishang_powershelltcponeline.yml index 940d98dd76..0bfd311939 100644 --- a/detections/endpoint/nishang_powershelltcponeline.yml +++ b/detections/endpoint/nishang_powershelltcponeline.yml @@ -1,16 +1,17 @@ name: Nishang PowershellTCPOneLine id: 1a382c6c-7c2e-11eb-ac69-acde48001122 -version: 2 -date: '2021-03-03' +version: 3 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: This query detects the Nishang Invoke-PowerShellTCPOneLine utility that - spawns a call back to a remote Command And Control server. This is a powershell - oneliner. In addition, this will capture on the command-line additional utilities - used by Nishang. Triage the endpoint and identify any parallel processes that look - suspicious. Review the reputation of the remote IP or domain contacted by the powershell - process. +description: The following analytic detects the use of the Nishang Invoke-PowerShellTCPOneLine + utility, which initiates a callback to a remote Command and Control (C2) server. + It leverages Endpoint Detection and Response (EDR) data, focusing on PowerShell + processes that include specific .NET classes like Net.Sockets.TCPClient and System.Text.ASCIIEncoding. + This activity is significant as it indicates potential remote control or data exfiltration + attempts by an attacker. If confirmed malicious, this could lead to unauthorized + remote access, data theft, or further compromise of the affected system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/nltest_domain_trust_discovery.yml b/detections/endpoint/nltest_domain_trust_discovery.yml index e48d1ba8e2..ac75839a79 100644 --- a/detections/endpoint/nltest_domain_trust_discovery.yml +++ b/detections/endpoint/nltest_domain_trust_discovery.yml @@ -1,15 +1,18 @@ name: NLTest Domain Trust Discovery id: c3e05466-5f22-11eb-ae93-0242ac130002 -version: 2 -date: '2022-04-18' +version: 3 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: This search looks for the execution of `nltest.exe` with command-line - arguments utilized to query for Domain Trust information. Two arguments `/domain - trusts`, returns a list of trusted domains, and `/all_trusts`, returns all trusted - domains. Red Teams and adversaries alike use NLTest.exe to enumerate the current - domain to assist with further understanding where to pivot next. +description: The following analytic identifies the execution of `nltest.exe` with + command-line arguments `/domain_trusts` or `/all_trusts` to query Domain Trust information. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process execution logs and command-line arguments. This activity is significant + as it indicates potential reconnaissance efforts by adversaries to understand domain + trust relationships, which can inform their lateral movement strategies. If confirmed + malicious, this activity could enable attackers to map out trusted domains, facilitating + further compromise and pivoting within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1482/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/non_chrome_process_accessing_chrome_default_dir.yml b/detections/endpoint/non_chrome_process_accessing_chrome_default_dir.yml index 75b6c5a6df..464c1c598c 100644 --- a/detections/endpoint/non_chrome_process_accessing_chrome_default_dir.yml +++ b/detections/endpoint/non_chrome_process_accessing_chrome_default_dir.yml @@ -1,25 +1,25 @@ name: Non Chrome Process Accessing Chrome Default Dir id: 81263de4-160a-11ec-944f-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect an anomaly event of a non-chrome process accessing - the files in chrome user default folder. This folder contains all the sqlite database - of the chrome browser related to users login, history, cookies and etc. Most of - the RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database - to collect information on the compromised host. This SACL Event (4663) need to be - enabled to tthe firefox profile directory to be eable to use this. Since you monitoring - this access to the folder, we observed noise that needs to be filter out and hence - added sqlite db browser and explorer .exe to make this detection more stable. +description: The following analytic detects a non-Chrome process accessing files in + the Chrome user default folder. It leverages Windows Security Event logs, specifically + event code 4663, to identify unauthorized access attempts. This activity is significant + because the Chrome default folder contains sensitive user data such as login credentials, + browsing history, and cookies. If confirmed malicious, this behavior could indicate + an attempt to exfiltrate sensitive information, often associated with RATs, trojans, + and advanced persistent threats like FIN7. Such access could lead to data theft + and further compromise of the affected system. data_source: - Windows Event Log Security 4663 search: '`wineventlog_security` EventCode=4663 NOT (ProcessName IN ("*\\chrome.exe", "*\\explorer.exe", "*sql*")) ObjectName="*\\Google\\Chrome\\User Data\\Default*" | stats count min(_time) as firstTime max(_time) as lastTime by ObjectName ObjectType - ProcessName AccessMask EventCode dest | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `non_chrome_process_accessing_chrome_default_dir_filter`' + ProcessName AccessMask EventCode dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `non_chrome_process_accessing_chrome_default_dir_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." @@ -71,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/non_chrome_process_accessing_chrome_default_dir/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/non_chrome_process_accessing_chrome_default_dir/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/non_firefox_process_access_firefox_profile_dir.yml b/detections/endpoint/non_firefox_process_access_firefox_profile_dir.yml index 005d99e2ec..0bf0bb5353 100644 --- a/detections/endpoint/non_firefox_process_access_firefox_profile_dir.yml +++ b/detections/endpoint/non_firefox_process_access_firefox_profile_dir.yml @@ -1,25 +1,24 @@ name: Non Firefox Process Access Firefox Profile Dir id: e6fc13b0-1609-11ec-b533-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect an anomaly event of a non-firefox process accessing - the files in the profile folder. This folder contains all the sqlite database of - the firefox browser related to users login, history, cookies and etc. Most of the - RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database - to collect information on the compromised host. This SACL Event (4663) needs to - be enabled to the firefox profile directory to use this. Since this is monitoring - the access to the folder, we have obsevered noise and hence added `sqlite db browser` - and `explorer.exe` to make this detection more stable. +description: The following analytic detects non-Firefox processes accessing the Firefox + profile directory, which contains sensitive user data such as login credentials, + browsing history, and cookies. It leverages Windows Security Event logs, specifically + event code 4663, to monitor access attempts. This activity is significant because + it may indicate attempts by malware, such as RATs or trojans, to harvest user information. + If confirmed malicious, this behavior could lead to data exfiltration, unauthorized + access to user accounts, and further compromise of the affected system. data_source: - Windows Event Log Security 4663 search: '`wineventlog_security` EventCode=4663 NOT (ProcessName IN ("*\\firefox.exe", "*\\explorer.exe", "*sql*")) ObjectName="*\\AppData\\Roaming\\Mozilla\\Firefox\\Profiles*" | stats count min(_time) as firstTime max(_time) as lastTime by ObjectName ObjectType - ProcessName AccessMask EventCode dest | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `non_firefox_process_access_firefox_profile_dir_filter`' + ProcessName AccessMask EventCode dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `non_firefox_process_access_firefox_profile_dir_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." @@ -72,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/non_chrome_process_accessing_chrome_default_dir/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/non_chrome_process_accessing_chrome_default_dir/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/notepad_with_no_command_line_arguments.yml b/detections/endpoint/notepad_with_no_command_line_arguments.yml index 81d8c576b2..419918270a 100644 --- a/detections/endpoint/notepad_with_no_command_line_arguments.yml +++ b/detections/endpoint/notepad_with_no_command_line_arguments.yml @@ -1,19 +1,20 @@ name: Notepad with no Command Line Arguments id: 5adbc5f1-9a2f-41c1-a810-f37e015f8179 -version: 1 -date: '2023-02-22' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk type: TTP status: production data_source: - Sysmon EventID 1 -description: The following analytic identifies behavior related to default SliverC2 - framework where it will inject into Notepad.exe and spawn Notepad.exe with no command - line arguments. In testing, this is a common procedure for SliverC2 usage, however - may be modified or changed. From Microsoft, "The Sideload, SpawnDll, and Execute-Assembly - commands spawn and inject into notepad.exe by default. The following query finds - process creation events where the same process creates and injects into notepad.exe - within 10 seconds." +description: The following analytic identifies instances where Notepad.exe is launched + without any command line arguments, a behavior commonly associated with the SliverC2 + framework. This detection leverages process creation events from Endpoint Detection + and Response (EDR) agents, focusing on processes initiated by Notepad.exe within + a short time frame. This activity is significant as it may indicate an attempt to + inject malicious code into Notepad.exe, a known tactic for evading detection. If + confirmed malicious, this could allow an attacker to execute arbitrary code, potentially + leading to system compromise and unauthorized access. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.process_name=notepad.exe AND Processes.action!="blocked" by host _time span=1h Processes.process_id Processes.process_name @@ -80,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/notepad_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/notepad_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/ntdsutil_export_ntds.yml b/detections/endpoint/ntdsutil_export_ntds.yml index 985c2743c1..34a70d201c 100644 --- a/detections/endpoint/ntdsutil_export_ntds.yml +++ b/detections/endpoint/ntdsutil_export_ntds.yml @@ -1,21 +1,17 @@ name: Ntdsutil Export NTDS id: da63bc76-61ae-11eb-ae93-0242ac130002 -version: 1 -date: '2021-01-28' +version: 2 +date: '2024-05-30' author: Michael Haag, Patrick Bareiss, Splunk status: production type: TTP -description: 'Monitor for signs that Ntdsutil is being used to Extract Active Directory - database - NTDS.dit, typically used for offline password cracking. It may be used - in normal circumstances with no command line arguments or shorthand variations of - more common arguments. Ntdsutil.exe is typically seen run on a Windows Server. Typical - command used to dump ntds.dit - - ntdsutil "ac i ntds" "ifm" "create full C:\Temp" q q - - This technique uses "Install from Media" (IFM), which will extract a copy of the - Active Directory database. A successful export of the Active Directory database - will yield a file modification named ntds.dit to the destination.' +description: 'The following analytic detects the use of Ntdsutil to export the Active + Directory database (NTDS.dit). It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line arguments. This activity + is significant because exporting NTDS.dit can be a precursor to offline password + cracking, posing a severe security risk. If confirmed malicious, an attacker could + gain access to sensitive credentials, potentially leading to unauthorized access + and privilege escalation within the network.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_application_drop_executable.yml b/detections/endpoint/office_application_drop_executable.yml index 2bfb827a22..4991080650 100644 --- a/detections/endpoint/office_application_drop_executable.yml +++ b/detections/endpoint/office_application_drop_executable.yml @@ -1,16 +1,18 @@ name: Office Application Drop Executable id: 73ce70c4-146d-11ec-9184-acde48001122 -version: 4 -date: '2023-02-15' +version: 5 +date: '2024-05-14' author: Teoderick Contreras, Michael Haag, Splunk, TheLawsOfChaos, Github status: production type: TTP -description: This search is to detect a suspicious MS office application that drops - or creates executables or scripts in a Windows Operating System. This behavior is - commonly seen in spear phishing office attachment where it drop malicious files - or script to compromised the host. It might be some normal macro may drop script - or tools as part of automation but still this behavior is reallly suspicious and - not commonly seen in normal office application +description: The following analytic detects Microsoft Office applications dropping + or creating executables or scripts on a Windows OS. It leverages process creation + and file system events from the Endpoint data model to identify Office applications + like Word or Excel generating files with extensions such as .exe, .dll, or .ps1. + This behavior is significant as it is often associated with spear-phishing attacks + where malicious files are dropped to compromise the host. If confirmed malicious, + this activity could lead to code execution, privilege escalation, or persistent + access, posing a severe threat to the environment. data_source: - Sysmon EventID 1 - Sysmon EventID 11 @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_application_spawn_regsvr32_process.yml b/detections/endpoint/office_application_spawn_regsvr32_process.yml index d1dbe0c653..bbf6fa1519 100644 --- a/detections/endpoint/office_application_spawn_regsvr32_process.yml +++ b/detections/endpoint/office_application_spawn_regsvr32_process.yml @@ -1,14 +1,18 @@ name: Office Application Spawn Regsvr32 process id: 2d9fc90c-f11f-11eb-9300-acde48001122 -version: 4 -date: '2023-02-15' +version: 5 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: this detection was designed to identifies suspicious spawned process - of known MS office application due to macro or malicious code. this technique can - be seen in so many malware like IcedID that used MS office as its weapon or attack - vector to initially infect the machines. +description: The following analytic identifies instances where an Office application + spawns a Regsvr32 process, which is often indicative of macro execution or malicious + code. This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process creation events where the parent process is a known Office application. + This activity is significant because it is a common technique used by malware, such + as IcedID, to initiate infections. If confirmed malicious, this behavior could lead + to code execution, allowing attackers to gain control over the affected system and + potentially escalate privileges. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/phish_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/phish_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_application_spawn_rundll32_process.yml b/detections/endpoint/office_application_spawn_rundll32_process.yml index e4d5ebefd0..8c30efb8d2 100644 --- a/detections/endpoint/office_application_spawn_rundll32_process.yml +++ b/detections/endpoint/office_application_spawn_rundll32_process.yml @@ -1,14 +1,17 @@ name: Office Application Spawn rundll32 process id: 958751e4-9c5f-11eb-b103-acde48001122 -version: 4 -date: '2023-02-15' +version: 5 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: TTP -description: This detection was designed to identify suspicious spawned processes - of known MS office applications due to macro or malicious code. this technique can - be seen in so many malware like trickbot that used MS office as its weapon or attack - vector to initially infect the machines. +description: The following analytic identifies instances where an Office application + spawns a rundll32 process, which is often indicative of macro execution or malicious + code. This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process creation events where the parent process is a known Office application. + This activity is significant because it is a common technique used by malware, such + as Trickbot, to initiate infections. If confirmed malicious, this behavior could + lead to code execution, further system compromise, and potential data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_document_creating_schedule_task.yml b/detections/endpoint/office_document_creating_schedule_task.yml index f3b023ecc9..bf7281830a 100644 --- a/detections/endpoint/office_document_creating_schedule_task.yml +++ b/detections/endpoint/office_document_creating_schedule_task.yml @@ -1,31 +1,23 @@ name: Office Document Creating Schedule Task id: cc8b7b74-9d0f-11eb-8342-acde48001122 -version: 6 -date: '2024-03-14' +version: 7 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects a potentially malicious office document that creates - a scheduled task entry either through a macro VBA API or by loading taskschd.dll. This - technique has been observed in numerous instances of malicious macro malware aiming to establish persistence - or beaconing through task schedule entries. The analytic will return the first and - last time the task was registered, as well as details such as the `Command` to be executed, - `Task Name`, `Author`, `Enabled` status, and whether it is `Hidden`. schtasks.exe - is natively located in `C:\Windows\system32` and `C:\Windows\syswow64`. The DLL(s) - `taskschd.dll` are loaded when schtasks.exe or TaskService is initiated. If this DLL is found loaded by another process, it may indicate that a scheduled task is being registered - within that process's context in memory. During triage, determine the source of the scheduled - task. Was it schtasks.exe or via TaskService? Review the job created and the command - to be executed. Capture any artifacts on disk for further review. Identify any parallel - processes within the same timeframe to pinpoint the source.' +description: The following analytic detects an Office document creating a scheduled + task, either through a macro VBA API or by loading `taskschd.dll`. This detection + leverages Sysmon EventCode 7 to identify when Office applications load the `taskschd.dll` + file. This activity is significant as it is a common technique used by malicious + macro malware to establish persistence or initiate beaconing. If confirmed malicious, + this could allow an attacker to maintain persistence, execute arbitrary commands, + or schedule future malicious activities, posing a significant threat to the environment. data_source: - Sysmon EventID 7 -search: '`sysmon` EventCode=7 process_name IN ("WINWORD.EXE", "EXCEL.EXE", - "POWERPNT.EXE","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", - "msaccess.exe") loaded_file_path = "*\\taskschd.dll" - | stats min(_time) as firstTime - max(_time) as lastTime count by user_id, dest, process_name,loaded_file, loaded_file_path, original_file_name, process_guid - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`sysmon` EventCode=7 process_name IN ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", + "msaccess.exe") loaded_file_path = "*\\taskschd.dll" | stats min(_time) as firstTime + max(_time) as lastTime count by user_id, dest, process_name,loaded_file, loaded_file_path, + original_file_name, process_guid | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `office_document_creating_schedule_task_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. @@ -45,8 +37,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: An Office document was identified creating a scheduled task on $dest$. Investigate - further. + message: An Office document was identified creating a scheduled task on $dest$. + Investigate further. mitre_attack_id: - T1566 - T1566.001 @@ -74,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_document_executing_macro_code.yml b/detections/endpoint/office_document_executing_macro_code.yml index 6c7ca46330..41a3287902 100644 --- a/detections/endpoint/office_document_executing_macro_code.yml +++ b/detections/endpoint/office_document_executing_macro_code.yml @@ -1,25 +1,24 @@ name: Office Document Executing Macro Code id: b12c89bc-9d06-11eb-a592-acde48001122 -version: 5 -date: '2024-03-17' +version: 6 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This detection is designed to identify suspicious office documents - that utilize macro code. Macro code is known to be a prevalent weaponization - or attack vector for threat actors. This malicious macro code can be embedded in an office - document as an attachment, potentially executing a malicious payload, downloading malware, - or other malicious components. It is a good practice to disable macros by default - to prevent the automatic execution of macro code when opening or closing office document - files. +description: The following analytic identifies office documents executing macro code. + It leverages Sysmon EventCode 7 to detect when processes like WINWORD.EXE or EXCEL.EXE + load specific DLLs associated with macros (e.g., VBE7.DLL). This activity is significant + because macros are a common attack vector for delivering malicious payloads, such + as malware. If confirmed malicious, this could lead to unauthorized code execution, + data exfiltration, or further compromise of the system. Disabling macros by default + is recommended to mitigate this risk. data_source: - Sysmon EventID 7 -search: '`sysmon` EventCode=7 process_name IN ("WINWORD.EXE", "EXCEL.EXE", - "POWERPNT.EXE","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe") +search: '`sysmon` EventCode=7 process_name IN ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe") loaded_file_path IN ("*\\VBE7INTL.DLL","*\\VBE7.DLL", "*\\VBEUI.DLL") | stats min(_time) - as firstTime max(_time) as lastTime values(loaded_file) as loaded_file count - by dest EventCode process_name process_guid | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `office_document_executing_macro_code_filter`' + as firstTime max(_time) as lastTime values(loaded_file) as loaded_file count by + dest EventCode process_name process_guid | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `office_document_executing_macro_code_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. @@ -78,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_document_spawned_child_process_to_download.yml b/detections/endpoint/office_document_spawned_child_process_to_download.yml index 84ef9f520a..f359bb1535 100644 --- a/detections/endpoint/office_document_spawned_child_process_to_download.yml +++ b/detections/endpoint/office_document_spawned_child_process_to_download.yml @@ -1,14 +1,18 @@ name: Office Document Spawned Child Process To Download id: 6fed27d2-9ec7-11eb-8fe4-aa665a019aa3 -version: 6 -date: '2023-07-11' +version: 7 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect potential malicious office document executing - lolbin child process to download payload or other malware. Since most of the attacker - abused the capability of office document to execute living on land application to - blend it to the normal noise in the infected machine to cover its track. +description: The following analytic identifies Office applications spawning child + processes to download content via HTTP/HTTPS. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where Office applications + like Word or Excel initiate network connections, excluding common browsers. This + activity is significant as it often indicates the use of malicious documents to + execute living-off-the-land binaries (LOLBins) for payload delivery. If confirmed + malicious, this behavior could lead to unauthorized code execution, data exfiltration, + or further malware deployment, posing a severe threat to the organization's security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/datasets2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawn_cmd_process.yml b/detections/endpoint/office_product_spawn_cmd_process.yml index 9bce73fe2d..eefddc7ecd 100644 --- a/detections/endpoint/office_product_spawn_cmd_process.yml +++ b/detections/endpoint/office_product_spawn_cmd_process.yml @@ -1,15 +1,18 @@ name: Office Product Spawn CMD Process id: b8b19420-e892-11eb-9244-acde48001122 -version: 5 -date: '2023-07-11' +version: 6 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP -description: this search is to detect a suspicious office product process that spawn - cmd child process. This is commonly seen in a ms office product having macro to - execute shell command to download or execute malicious lolbin relative to its malicious - code. This is seen in trickbot spear phishing doc where it execute shell cmd to - run mshta payload. +description: The following analytic detects an Office product spawning a CMD process, + which is indicative of a macro executing shell commands to download or run malicious + code. This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process and parent process names. This activity is significant as it + often signals the execution of malicious payloads, such as those seen in Trickbot + spear-phishing campaigns. If confirmed malicious, this behavior could lead to unauthorized + code execution, potentially compromising the system and allowing further malicious + activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -18,10 +21,11 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime = "powerpnt.exe" OR Processes.parent_process_name= "onenote.exe" OR Processes.parent_process_name = "onenotem.exe" OR Processes.parent_process_name = "onenoteviewer.exe" OR Processes.parent_process_name = "onenoteim.exe" OR Processes.parent_process_name = "msaccess.exe" OR Processes.parent_process_name="Graph.exe" - OR Processes.parent_process_name="winproj.exe") `process_cmd` by Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.process Processes.process_id Processes.process_guid - Processes.user Processes.dest Processes.original_file_name | `drop_dm_object_name("Processes")` - | `security_content_ctime(firstTime)` |`security_content_ctime(lastTime)` | `office_product_spawn_cmd_process_filter`' + OR Processes.parent_process_name="winproj.exe") `process_cmd` by Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.process_guid Processes.user Processes.dest Processes.original_file_name + | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` |`security_content_ctime(lastTime)` + | `office_product_spawn_cmd_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -90,6 +94,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/spear_phish/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/spear_phish/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawning_bitsadmin.yml b/detections/endpoint/office_product_spawning_bitsadmin.yml index 7d36a38e8d..ec0b2821fe 100644 --- a/detections/endpoint/office_product_spawning_bitsadmin.yml +++ b/detections/endpoint/office_product_spawning_bitsadmin.yml @@ -1,30 +1,28 @@ name: Office Product Spawning BITSAdmin id: e8c591f4-a6d7-11eb-8cf7-acde48001122 -version: 5 -date: '2023-07-11' +version: 6 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by different - malware families (including TA551, IcedID). This detection identifies any Windows - Office Product spawning `bitsadmin.exe`. In malicious instances, the command-line - of `bitsadmin.exe` will contain a URL to a remote destination or similar command-line - arguments as transfer, Download, priority, Foreground. In addition, Threat Research - has released a detections identifying suspicious use of `bitsadmin.exe`. In this - instance, we narrow our detection down to the Office suite as a parent process. - During triage, review all file modifications. Capture and analyze any artifacts - on disk. The Office Product, or `bitsadmin.exe` will have reached out to a remote - destination, capture and block the IPs or domain. Review additional parallel processes - for further activity. +description: The following analytic detects any Windows Office Product spawning `bitsadmin.exe`, + a behavior often associated with malware families like TA551 and IcedID. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + and parent process relationships. This activity is significant because `bitsadmin.exe` + is commonly used for malicious file transfers, potentially indicating a malware + infection. If confirmed malicious, this activity could allow attackers to download + additional payloads, escalate privileges, or establish persistence, leading to further + compromise of the affected system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", "msaccess.exe", "Graph.exe","winproj.exe") `process_bitsadmin` by Processes.dest - Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.original_file_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `office_product_spawning_bitsadmin_filter`' + Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` + | `office_product_spawning_bitsadmin_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -81,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawning_certutil.yml b/detections/endpoint/office_product_spawning_certutil.yml index 920b784cf8..4f69c47264 100644 --- a/detections/endpoint/office_product_spawning_certutil.yml +++ b/detections/endpoint/office_product_spawning_certutil.yml @@ -1,29 +1,27 @@ name: Office Product Spawning CertUtil id: 6925fe72-a6d5-11eb-9e17-acde48001122 -version: 5 -date: '2023-07-11' +version: 6 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by different - malware families (including TA551, IcedID). This detection identifies any Windows - Office Product spawning `certutil.exe`. In malicious instances, the command-line - of `certutil.exe` will contain a URL to a remote destination. In addition, Threat - Research has released a detections identifying suspicious use of `certutil.exe`. - In this instance, we narrow our detection down to the Office suite as a parent process. - During triage, review all file modifications. Capture and analyze any artifacts - on disk. The Office Product, or `certutil.exe` will have reached out to a remote - destination, capture and block the IPs or domain. Review additional parallel processes - for further activity. +description: The following analytic detects any Windows Office Product spawning `certutil.exe`, + a behavior often associated with malware families like TA551 and IcedID. This detection + leverages Endpoint Detection and Response (EDR) data, focusing on process relationships + and command-line executions. The significance lies in the fact that `certutil.exe` + is frequently used for downloading malicious payloads from remote URLs. If confirmed + malicious, this activity could lead to unauthorized code execution, data exfiltration, + or further system compromise. Immediate investigation and containment are crucial + to prevent potential damage. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe", - "Graph.exe","winproj.exe") `process_certutil` by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `office_product_spawning_certutil_filter`' + "Graph.exe","winproj.exe") `process_certutil` by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.original_file_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `office_product_spawning_certutil_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -83,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawning_mshta.yml b/detections/endpoint/office_product_spawning_mshta.yml index 86f5981bab..77be35a956 100644 --- a/detections/endpoint/office_product_spawning_mshta.yml +++ b/detections/endpoint/office_product_spawning_mshta.yml @@ -1,28 +1,26 @@ name: Office Product Spawning MSHTA id: 6078fa20-a6d2-11eb-b662-acde48001122 -version: 4 -date: '2023-07-11' +version: 5 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by different - malware families (including TA551, IcedID). This detection identifies any Windows - Office Product spawning `mshta.exe`. In malicious instances, the command-line of - `mshta.exe` will contain the `hta` file locally, or a URL to the remote destination. - In addition, Threat Research has released a detections identifying suspicious use - of `mshta.exe`. In this instance, we narrow our detection down to the Office suite - as a parent process. During triage, review all file modifications. Capture and analyze - any artifacts on disk. The Office Product, or `mshta.exe` will have reached out - to a remote destination, capture and block the IPs or domain. Review additional - parallel processes for further activity. +description: The following analytic identifies instances where a Microsoft Office + product spawns `mshta.exe`. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where the parent + process is an Office application. This activity is significant because it is a common + technique used by malware families like TA551 and IcedID to execute malicious scripts + or payloads. If confirmed malicious, this behavior could allow attackers to execute + arbitrary code, potentially leading to data exfiltration, system compromise, or + further malware deployment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe", "onenote.exe","onenotem.exe", - "msaccess.exe","Graph.exe","winproj.exe") `process_mshta` by Processes.dest Processes.user Processes.parent_process_name - Processes.parent_process Processes.process_name Processes.original_file_name Processes.process - Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + "msaccess.exe","Graph.exe","winproj.exe") `process_mshta` by Processes.dest Processes.user + Processes.parent_process_name Processes.parent_process Processes.process_name Processes.original_file_name + Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `office_product_spawning_mshta_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -82,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawning_rundll32_with_no_dll.yml b/detections/endpoint/office_product_spawning_rundll32_with_no_dll.yml index 90b3518b21..b0350eb750 100644 --- a/detections/endpoint/office_product_spawning_rundll32_with_no_dll.yml +++ b/detections/endpoint/office_product_spawning_rundll32_with_no_dll.yml @@ -1,29 +1,28 @@ name: Office Product Spawning Rundll32 with no DLL id: c661f6be-a38c-11eb-be57-acde48001122 -version: 5 -date: '2023-07-11' +version: 6 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by IcedID - malware family. This detection identifies any Windows Office Product spawning `rundll32.exe` - without a `.dll` file extension. In malicious instances, the command-line of `rundll32.exe` - will look like `rundll32 ..\oepddl.igk2,DllRegisterServer`. In addition, Threat - Research has released a detection identifying the use of `DllRegisterServer` on - the command-line of `rundll32.exe`. In this instance, we narrow our detection down - to the Office suite as a parent process. During triage, review all file modifications. - Capture and analyze the `DLL` that was dropped to disk. The Office Product will - have reached out to a remote destination, capture and block the IPs or domain. Review - additional parallel processes for further activity. +description: The following analytic detects any Windows Office Product spawning `rundll32.exe` + without a `.dll` file extension. This behavior is identified using Endpoint Detection + and Response (EDR) telemetry, focusing on process and parent process relationships. + This activity is significant as it is a known tactic of the IcedID malware family, + which can lead to unauthorized code execution. If confirmed malicious, this could + allow attackers to execute arbitrary code, potentially leading to data exfiltration, + system compromise, or further malware deployment. Immediate investigation and containment + are recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe", "msaccess.exe", "Graph.exe","winproj.exe") `process_rundll32` (Processes.process!=*.dll*) - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `office_product_spawning_rundll32_with_no_dll_filter`' + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` + | `office_product_spawning_rundll32_with_no_dll_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -83,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_icedid.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_icedid.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_spawning_wmic.yml b/detections/endpoint/office_product_spawning_wmic.yml index 465da61574..e6be1c2d40 100644 --- a/detections/endpoint/office_product_spawning_wmic.yml +++ b/detections/endpoint/office_product_spawning_wmic.yml @@ -1,29 +1,27 @@ name: Office Product Spawning Wmic id: ffc236d6-a6c9-11eb-95f1-acde48001122 -version: 6 -date: '2023-07-11' +version: 7 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by Ursnif - malware family. This detection identifies any Windows Office Product spawning `wmic.exe`. - In malicious instances, the command-line of `wmic.exe` will contain `wmic process - call create`. In addition, Threat Research has released a detection identifying - the use of `wmic process call create` on the command-line of `wmic.exe`. In this - instance, we narrow our detection down to the Office suite as a parent process. - During triage, review all file modifications. Capture and analyze any artifacts - on disk. The Office Product, or `wmic.exe` will have reached out to a remote destination, - capture and block the IPs or domain. Review additional parallel processes for further - activity. +description: The following analytic detects any Windows Office Product spawning `wmic.exe`, + specifically when the command-line of `wmic.exe` contains `wmic process call create`. + This behavior is identified using data from Endpoint Detection and Response (EDR) + agents, focusing on process and parent process relationships. This activity is significant + as it is commonly associated with the Ursnif malware family, indicating potential + malicious activity. If confirmed malicious, this could allow an attacker to execute + arbitrary commands, leading to further system compromise, data exfiltration, or + lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe", - "Graph.exe","winproj.exe") `process_wmic` by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `office_product_spawning_wmic_filter`' + "Graph.exe","winproj.exe") `process_wmic` by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.original_file_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `office_product_spawning_wmic_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -83,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_macros.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_product_writing_cab_or_inf.yml b/detections/endpoint/office_product_writing_cab_or_inf.yml index c776deb2b5..b72c3790b4 100644 --- a/detections/endpoint/office_product_writing_cab_or_inf.yml +++ b/detections/endpoint/office_product_writing_cab_or_inf.yml @@ -1,14 +1,17 @@ name: Office Product Writing cab or inf id: f48cd1d4-125a-11ec-a447-acde48001122 -version: 4 -date: '2023-02-15' +version: 5 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies behavior related to CVE-2021-40444. - Whereas the malicious document will load ActiveX and download the remote payload - (.inf, .cab). During triage, review parallel processes and further activity on endpoint - to identify additional patterns. Retrieve the file modifications and analyze further. +description: The following analytic detects Office products writing .cab or .inf files, + indicative of CVE-2021-40444 exploitation. It leverages the Endpoint.Processes and + Endpoint.Filesystem data models to identify Office applications creating these file + types. This activity is significant as it may signal an attempt to load malicious + ActiveX controls and download remote payloads, a known attack vector. If confirmed + malicious, this could lead to remote code execution, allowing attackers to gain + control over the affected system and potentially compromise sensitive data. data_source: - Sysmon EventID 1 - Sysmon EventID 11 @@ -77,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_cabinf.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_cabinf.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/office_spawning_control.yml b/detections/endpoint/office_spawning_control.yml index c44032083c..0ea96e2f34 100644 --- a/detections/endpoint/office_spawning_control.yml +++ b/detections/endpoint/office_spawning_control.yml @@ -1,26 +1,27 @@ name: Office Spawning Control id: 053e027c-10c7-11ec-8437-acde48001122 -version: 4 -date: '2023-11-07' +version: 5 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies control.exe spawning from an office - product. This detection identifies any Windows Office Product spawning `control.exe`. - In malicious instances, the command-line of `control.exe` will contain a file path - to a .cpl or .inf, related to CVE-2021-40444. In this instance, we narrow our detection - down to the Office suite as a parent process. During triage, review all file modifications. - Capture and analyze any artifacts on disk. review parallel and child processes to - identify further suspicious behavior +description: The following analytic identifies instances where `control.exe` is spawned + by a Microsoft Office product. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process and parent process relationships. This activity + is significant because it can indicate exploitation attempts related to CVE-2021-40444, + where `control.exe` is used to execute malicious .cpl or .inf files. If confirmed + malicious, this behavior could allow an attacker to execute arbitrary code, potentially + leading to system compromise, data exfiltration, or further lateral movement within + the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","mspub.exe","visio.exe","wordpad.exe","wordview.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe") - Processes.process_name=control.exe by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| - `office_spawning_control_filter`' + Processes.process_name=control.exe by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)`| `office_spawning_control_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -87,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_control.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_control.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/outbound_network_connection_from_java_using_default_ports.yml b/detections/endpoint/outbound_network_connection_from_java_using_default_ports.yml index 709f6e4fb7..40b85044fc 100644 --- a/detections/endpoint/outbound_network_connection_from_java_using_default_ports.yml +++ b/detections/endpoint/outbound_network_connection_from_java_using_default_ports.yml @@ -1,17 +1,17 @@ name: Outbound Network Connection from Java Using Default Ports id: d2c14d28-5c47-11ec-9892-acde48001122 -version: 2 -date: '2022-06-28' +version: 3 +date: '2024-05-26' author: Mauricio Velazco, Lou Stella, Splunk status: production type: TTP -description: A required step while exploiting the CVE-2021-44228-Log4j vulnerability - is that the victim server will perform outbound connections to attacker-controlled - infrastructure. This is required as part of the JNDI lookup as well as for retrieving - the second stage .class payload. The following analytic identifies the Java process - reaching out to default ports used by the LDAP and RMI protocols. This behavior - could represent successfull exploitation. Note that adversaries can easily decide - to use arbitrary ports for these protocols and potentially bypass this detection. +description: The following analytic detects outbound network connections from Java + processes to default ports used by LDAP and RMI protocols, which may indicate exploitation + of the CVE-2021-44228-Log4j vulnerability. This detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process and network traffic logs. + Monitoring this activity is crucial as it can signify an attacker’s attempt to perform + JNDI lookups and retrieve malicious payloads. If confirmed malicious, this activity + could lead to remote code execution and further compromise of the affected server. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -77,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/outbound_java/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/outbound_java/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/overwriting_accessibility_binaries.yml b/detections/endpoint/overwriting_accessibility_binaries.yml index 6f31e5cbb8..ce700f1d5c 100644 --- a/detections/endpoint/overwriting_accessibility_binaries.yml +++ b/detections/endpoint/overwriting_accessibility_binaries.yml @@ -1,14 +1,18 @@ name: Overwriting Accessibility Binaries id: 13c2f6c3-10c5-4deb-9ba1-7c4460ebe4ae -version: 4 -date: '2023-04-14' +version: 5 +date: '2024-05-25' author: David Dorsey, Splunk status: production type: TTP -description: Microsoft Windows contains accessibility features that can be launched - with a key combination before a user has logged in. An adversary can modify or replace - these programs so they can get a command prompt or backdoor without logging in to - the system. This search looks for modifications to these binaries. +description: The following analytic detects modifications to Windows accessibility + binaries such as sethc.exe, utilman.exe, osk.exe, Magnify.exe, Narrator.exe, DisplaySwitch.exe, + and AtBroker.exe. It leverages filesystem activity data from the Endpoint.Filesystem + data model to identify changes to these specific files. This activity is significant + because adversaries can exploit these binaries to gain unauthorized access or execute + commands without logging in. If confirmed malicious, this could allow attackers + to bypass authentication mechanisms, potentially leading to unauthorized system + access and further compromise of the environment. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -63,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.008/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.008/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/papercut_ng_suspicious_behavior_debug_log.yml b/detections/endpoint/papercut_ng_suspicious_behavior_debug_log.yml index 22119cc1aa..3419aa89a2 100644 --- a/detections/endpoint/papercut_ng_suspicious_behavior_debug_log.yml +++ b/detections/endpoint/papercut_ng_suspicious_behavior_debug_log.yml @@ -1,28 +1,38 @@ name: PaperCut NG Suspicious Behavior Debug Log id: 395163b8-689b-444b-86c7-9fe9ad624734 -version: 1 -date: '2023-05-15' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk status: experimental type: Hunting data_source: [] -description: The following hunting analytic is designed to monitor and detect potential exploitation attempts targeting a PaperCut NG server by analyzing its debug log data. By focusing on public IP addresses accessing the PaperCut NG instance, this analytic aims to identify unauthorized or suspicious access attempts. Furthermore, it searches for specific URIs that have been discovered in the proof of concept code, which are associated with known exploits or vulnerabilities. The analytic is focused on the user admin. Regex is used mainly because the log is not parsed by Splunk and there is no TA for this debug log. -search: '`papercutng` (loginType=Admin OR userName=admin) - | eval uri_match=if(match(_raw, "(?i)(\/app\?service=page\/SetupCompleted|\/app|\/app\?service=page\/PrinterList|\/app\?service=direct\/1\/PrinterList\/selectPrinter&sp=l1001|\/app\?service=direct\/1\/PrinterDetails\/printerOptionsTab\.tab)"), "URI matches", null()) - | eval ip_match=if(match(_raw, "(?i)((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))") AND NOT match(_raw, "(?i)(10\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))|(172\.(1[6-9]|2[0-9]|3[0-1])\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))|(192\.168\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))"), "IP matches", null()) - | where (isnotnull(uri_match) OR isnotnull(ip_match)) - | stats sparkline, count, values(uri_match) AS uri_match, values(ip_match) AS ip_match latest(_raw) - BY host, index, sourcetype | `papercut_ng_suspicious_behavior_debug_log_filter`' -how_to_implement: Debug logs must be enabled and shipped to Splunk in order to properly identify behavior with this analytic. -known_false_positives: False positives may be present, as this is based on the admin user accessing the Papercut NG instance from a public IP address. Filter as needed. +description: The following analytic identifies potential exploitation attempts on + a PaperCut NG server by analyzing its debug log data. It detects unauthorized or + suspicious access attempts from public IP addresses and searches for specific URIs + associated with known exploits. The detection leverages regex to parse unstructured + log data, focusing on admin login activities. This activity is significant as it + can indicate an active exploitation attempt on the server. If confirmed malicious, + attackers could gain unauthorized access, potentially leading to data breaches or + further compromise of the server. +search: '`papercutng` (loginType=Admin OR userName=admin) | eval uri_match=if(match(_raw, + "(?i)(\/app\?service=page\/SetupCompleted|\/app|\/app\?service=page\/PrinterList|\/app\?service=direct\/1\/PrinterList\/selectPrinter&sp=l1001|\/app\?service=direct\/1\/PrinterDetails\/printerOptionsTab\.tab)"), + "URI matches", null()) | eval ip_match=if(match(_raw, "(?i)((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))") + AND NOT match(_raw, "(?i)(10\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))|(172\.(1[6-9]|2[0-9]|3[0-1])\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))|(192\.168\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))"), + "IP matches", null()) | where (isnotnull(uri_match) OR isnotnull(ip_match)) | stats + sparkline, count, values(uri_match) AS uri_match, values(ip_match) AS ip_match latest(_raw) + BY host, index, sourcetype | `papercut_ng_suspicious_behavior_debug_log_filter`' +how_to_implement: Debug logs must be enabled and shipped to Splunk in order to properly + identify behavior with this analytic. +known_false_positives: False positives may be present, as this is based on the admin + user accessing the Papercut NG instance from a public IP address. Filter as needed. references: - - https://www.papercut.com/kb/Main/HowToCollectApplicationServerDebugLogs - - https://github.com/inodee/threathunting-spl/blob/master/hunt-queries/HAFNIUM.md - - https://www.cisa.gov/news-events/alerts/2023/05/11/cisa-and-fbi-release-joint-advisory-response-active-exploitation-papercut-vulnerability - - https://www.papercut.com/kb/Main/PO-1216-and-PO-1219 - - https://www.horizon3.ai/papercut-cve-2023-27350-deep-dive-and-indicators-of-compromise/ - - https://www.bleepingcomputer.com/news/security/hackers-actively-exploit-critical-rce-bug-in-papercut-servers/ - - https://www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software +- https://www.papercut.com/kb/Main/HowToCollectApplicationServerDebugLogs +- https://github.com/inodee/threathunting-spl/blob/master/hunt-queries/HAFNIUM.md +- https://www.cisa.gov/news-events/alerts/2023/05/11/cisa-and-fbi-release-joint-advisory-response-active-exploitation-papercut-vulnerability +- https://www.papercut.com/kb/Main/PO-1216-and-PO-1219 +- https://www.horizon3.ai/papercut-cve-2023-27350-deep-dive-and-indicators-of-compromise/ +- https://www.bleepingcomputer.com/news/security/hackers-actively-exploit-critical-rce-bug-in-papercut-servers/ +- https://www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software tags: analytic_story: - PaperCut MF NG Vulnerability @@ -30,7 +40,8 @@ tags: atomic_guid: [] confidence: 80 impact: 80 - message: Behavior related to exploitation of PaperCut NG has been identified on $host$. + message: Behavior related to exploitation of PaperCut NG has been identified on + $host$. mitre_attack_id: - T1190 - T1133 @@ -54,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/server.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/server.log source: papercutng sourcetype: papercutng diff --git a/detections/endpoint/petitpotam_network_share_access_request.yml b/detections/endpoint/petitpotam_network_share_access_request.yml index b9ca8f822a..2e05e72116 100644 --- a/detections/endpoint/petitpotam_network_share_access_request.yml +++ b/detections/endpoint/petitpotam_network_share_access_request.yml @@ -1,30 +1,24 @@ name: PetitPotam Network Share Access Request id: 95b8061a-0a67-11ec-85ec-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-26' author: Michael Haag, Mauricio Velazco, Splunk status: production type: TTP -description: 'The following analytic utilizes Windows Event Code 5145, "A network - share object was checked to see whether client can be granted desired access". During - our research into PetitPotam, CVE-2021-36942, we identified the ocurrence of this - event on the target host with specific values. - - To enable 5145 events via Group Policy - Computer Configuration->Polices->Windows - Settings->Security Settings->Advanced Audit Policy Configuration. Expand this node, - go to Object Access (Audit Polices->Object Access), then select the Setting Audit - Detailed File Share Audit - - It is possible this is not enabled by default and may need to be reviewed and enabled. - - - During triage, review parallel security events to identify further suspicious activity.' +description: 'The following analytic detects network share access requests indicative + of the PetitPotam attack (CVE-2021-36942). It leverages Windows Event Code 5145, + which logs attempts to access network share objects. This detection is significant + as PetitPotam can coerce authentication from domain controllers, potentially leading + to unauthorized access. If confirmed malicious, this activity could allow attackers + to escalate privileges or move laterally within the network, posing a severe security + risk. Ensure Event Code 5145 is enabled via Group Policy to utilize this analytic + effectively.' data_source: - Windows Event Log Security 5145 search: '`wineventlog_security` SubjectUserName="ANONYMOUS LOGON" EventCode=5145 RelativeTargetName=lsarpc | stats count min(_time) as firstTime max(_time) as lastTime by dest, SubjectUserSid, - ShareName, src, AccessMask, AccessReason | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `petitpotam_network_share_access_request_filter`' + ShareName, src, AccessMask, AccessReason | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `petitpotam_network_share_access_request_filter`' how_to_implement: Windows Event Code 5145 is required to utilize this analytic and it may not be enabled in most environments. known_false_positives: False positives have been limited when the Anonymous Logon @@ -67,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1187/petitpotam/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1187/petitpotam/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/petitpotam_suspicious_kerberos_tgt_request.yml b/detections/endpoint/petitpotam_suspicious_kerberos_tgt_request.yml index 89d5355da7..c8508e737c 100644 --- a/detections/endpoint/petitpotam_suspicious_kerberos_tgt_request.yml +++ b/detections/endpoint/petitpotam_suspicious_kerberos_tgt_request.yml @@ -1,25 +1,24 @@ name: PetitPotam Suspicious Kerberos TGT Request id: e3ef244e-0a67-11ec-abf2-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-30' author: Michael Haag, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifes Event Code 4768, A `Kerberos authentication - ticket (TGT) was requested`, successfull occurs. This behavior has been identified - to assist with detecting PetitPotam, CVE-2021-36942. Once an attacer obtains a computer - certificate by abusing Active Directory Certificate Services in combination with - PetitPotam, the next step would be to leverage the certificate for malicious purposes. - One way of doing this is to request a Kerberos Ticket Granting Ticket using a tool - like Rubeus. This request will generate a 4768 event with some unusual fields depending - on the environment. This analytic will require tuning, we recommend filtering Account_Name - to Domain Controllers for your environment. +description: The following analytic detects a suspicious Kerberos Ticket Granting + Ticket (TGT) request, identified by Event Code 4768. This detection leverages Windows + Security Event Logs to identify TGT requests with unusual fields, which may indicate + the use of tools like Rubeus following the exploitation of CVE-2021-36942 (PetitPotam). + This activity is significant as it can signal an attacker leveraging a compromised + certificate to request Kerberos tickets, potentially leading to unauthorized access. + If confirmed malicious, this could allow attackers to escalate privileges and persist + within the environment, posing a severe security risk. data_source: - Windows Event Log Security 4768 search: '`wineventlog_security` EventCode=4768 src!="::1" TargetUserName=*$ CertThumbprint!="" - | stats count min(_time) as firstTime max(_time) as lastTime by dest, TargetUserName, src, action - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `petitpotam_suspicious_kerberos_tgt_request_filter`' + | stats count min(_time) as firstTime max(_time) as lastTime by dest, TargetUserName, + src, action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `petitpotam_suspicious_kerberos_tgt_request_filter`' how_to_implement: The following analytic requires Event Code 4768. Ensure that it is logging no Domain Controllers and appearing in Splunk. known_false_positives: False positives are possible if the environment is using certificates @@ -61,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1187/petitpotam/windows-xml-1.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1187/petitpotam/windows-xml-1.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/ping_sleep_batch_command.yml b/detections/endpoint/ping_sleep_batch_command.yml index acf5c300a2..647878ca12 100644 --- a/detections/endpoint/ping_sleep_batch_command.yml +++ b/detections/endpoint/ping_sleep_batch_command.yml @@ -1,16 +1,18 @@ name: Ping Sleep Batch Command id: ce058d6c-79f2-11ec-b476-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic will identify the possible execution of ping sleep batch - commands. This technique was seen in several malware samples and is used to trigger - sleep times without explicitly calling sleep functions or commandlets. The goal - is to delay the execution of malicious code and bypass detection or sandbox analysis. - This detection can be a good indicator of a process delaying its execution for - malicious purposes. +description: The following analytic identifies the execution of ping sleep batch commands. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process and parent process command-line details. This activity is significant as + it indicates an attempt to delay malicious code execution, potentially evading detection + or sandbox analysis. If confirmed malicious, this technique allows attackers to + bypass security measures, making it harder to detect and analyze their activities, + thereby increasing the risk of prolonged unauthorized access and potential data + exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -78,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/ping_sleep/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/ping_sleep/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/possible_browser_pass_view_parameter.yml b/detections/endpoint/possible_browser_pass_view_parameter.yml index cf73e98b83..c2e79b5818 100644 --- a/detections/endpoint/possible_browser_pass_view_parameter.yml +++ b/detections/endpoint/possible_browser_pass_view_parameter.yml @@ -1,18 +1,18 @@ name: Possible Browser Pass View Parameter id: 8ba484e8-4b97-11ec-b19a-acde48001122 -version: 1 -date: '2021-11-22' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic will detect if a suspicious process contains a commandline - parameter related to a web browser credential dumper. This technique is used by - Remcos RAT malware which uses the Nirsoft webbrowserpassview.exe application to - dump web browser credentials. Remcos uses the "/stext" command line to dump the - credentials in text format. This Hunting query is a good indicator of hosts suffering - from possible Remcos RAT infection. Since the hunting query is based on the parameter - command and the possible path where it will save the text credential information, - it may catch normal tools that are using the same command and behavior. +description: The following analytic identifies processes with command-line parameters + associated with web browser credential dumping tools, specifically targeting behaviors + used by Remcos RAT malware. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on command-line executions and specific file paths. This + activity is significant as it indicates potential credential theft, a common tactic + in broader cyber-espionage campaigns. If confirmed malicious, attackers could gain + unauthorized access to sensitive web credentials, leading to further system compromise + and data breaches. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/web_browser_pass_view/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/web_browser_pass_view/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/possible_lateral_movement_powershell_spawn.yml b/detections/endpoint/possible_lateral_movement_powershell_spawn.yml index c6caf24a5b..6b3a5242d9 100644 --- a/detections/endpoint/possible_lateral_movement_powershell_spawn.yml +++ b/detections/endpoint/possible_lateral_movement_powershell_spawn.yml @@ -1,20 +1,18 @@ name: Possible Lateral Movement PowerShell Spawn id: cb909b3e-512b-11ec-aa31-3e22fbd008af -version: 2 -date: '2023-05-13' +version: 3 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: TTP -description: 'The following analytic is designed to identify possible lateral movement - attacks that involve the spawning of a PowerShell process as a child or grandchild - process of commonly abused processes. These processes include services.exe, wmiprsve.exe, - svchost.exe, wsmprovhost.exe, and mmc.exe. - - Such behavior is indicative of legitimate Windows features such as the Service Control - Manager, Windows Management Instrumentation, Task Scheduler, Windows Remote Management, - and the DCOM protocol being abused to start a process on a remote endpoint. This - behavior is often seen during lateral movement techniques where adversaries or red - teams abuse these services for lateral movement and remote code execution.' +description: 'The following analytic detects the spawning of a PowerShell process + as a child or grandchild of commonly abused processes like services.exe, wmiprsve.exe, + svchost.exe, wsmprovhost.exe, and mmc.exe. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process and parent process names, as well + as command-line executions. This activity is significant as it often indicates lateral + movement or remote code execution attempts by adversaries. If confirmed malicious, + this behavior could allow attackers to execute code remotely, escalate privileges, + or persist within the environment.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -22,10 +20,11 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime OR Processes.parent_process_name=services.exe OR Processes.parent_process_name=svchost.exe OR Processes.parent_process_name=wsmprovhost.exe OR Processes.parent_process_name=mmc.exe) (Processes.process_name=powershell.exe OR (Processes.process_name=cmd.exe AND Processes.process=*powershell.exe*) - OR Processes.process_name=pwsh.exe OR (Processes.process_name=cmd.exe AND Processes.process=*pwsh.exe*)) NOT (Processes.process IN ("*c:\windows\ccm\*")) - by Processes.dest Processes.user Processes.parent_process_name Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `possible_lateral_movement_powershell_spawn_filter`' + OR Processes.process_name=pwsh.exe OR (Processes.process_name=cmd.exe AND Processes.process=*pwsh.exe*)) + NOT (Processes.process IN ("*c:\windows\ccm\*")) by Processes.dest Processes.user + Processes.parent_process_name Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `possible_lateral_movement_powershell_spawn_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -91,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement_powershell/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement_powershell/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/potential_password_in_username.yml b/detections/endpoint/potential_password_in_username.yml index 123dadaad6..e9ec637a72 100644 --- a/detections/endpoint/potential_password_in_username.yml +++ b/detections/endpoint/potential_password_in_username.yml @@ -1,15 +1,18 @@ name: Potential password in username id: 5ced34b4-ab32-4bb0-8f22-3b8f186f0a38 -version: 1 -date: '2022-05-11' +version: 2 +date: '2024-05-11' author: Mikael Bjerkeland, Splunk status: production type: Hunting -description: This search identifies users who have entered their passwords in username - fields. This is done by looking for failed authentication attempts using usernames - with a length longer than 7 characters and a high Shannon entropy, and looks for - the next successful authentication attempt from the same source system to the same - destination system as the failed attempt. +description: The following analytic identifies instances where users may have mistakenly + entered their passwords in the username field during authentication attempts. It + detects this by analyzing failed authentication events with usernames longer than + 7 characters and high Shannon entropy, followed by a successful authentication from + the same source to the same destination. This activity is significant as it can + indicate potential security risks, such as password exposure. If confirmed malicious, + attackers could exploit this to gain unauthorized access, leading to potential data + breaches or further compromise of the system. data_source: - Linux Secure search: '| tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) @@ -73,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.001/password_in_username/linux_secure.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.001/password_in_username/linux_secure.log source: /var/log/secure sourcetype: linux_secure diff --git a/detections/endpoint/potentially_malicious_code_on_commandline.yml b/detections/endpoint/potentially_malicious_code_on_commandline.yml index a861336f50..1f8cb8a562 100644 --- a/detections/endpoint/potentially_malicious_code_on_commandline.yml +++ b/detections/endpoint/potentially_malicious_code_on_commandline.yml @@ -1,20 +1,19 @@ name: Potentially malicious code on commandline id: 9c53c446-757e-11ec-871d-acde48001122 -version: 1 -date: '2022-01-14' +version: 2 +date: '2024-05-12' author: Michael Hart, Splunk status: production type: Anomaly -description: The following analytic uses a pretrained machine learning text classifier - to detect potentially malicious commandlines. The model identifies unusual combinations - of keywords found in samples of commandlines where adversaries executed powershell - code, primarily for C2 communication. For example, adversaries will leverage IO - capabilities such as "streamreader" and "webclient", threading capabilties such - as "mutex" locks, programmatic constructs like "function" and "catch", and cryptographic - operations like "computehash". Although observing one of these keywords in a commandline - script is possible, combinations of keywords observed in attack data are not typically - found in normal usage of the commandline. The model will output a score where all - values above zero are suspicious, anything greater than one particularly so. +description: The following analytic detects potentially malicious command lines using + a pretrained machine learning text classifier. It identifies unusual keyword combinations + in command lines, such as "streamreader," "webclient," "mutex," "function," and + "computehash," which are often associated with adversarial PowerShell code execution + for C2 communication. This detection leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command lines longer than 200 characters. This + activity is significant as it can indicate an attempt to execute malicious scripts, + potentially leading to unauthorized code execution, data exfiltration, or further + system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -47,7 +46,8 @@ tags: asset_type: Endpoint confidence: 20 impact: 60 - message: Unusual command-line execution with command line length greater than 200 found on $dest$ with commandline value - [$process$] + message: Unusual command-line execution with command line length greater than 200 + found on $dest$ with commandline value - [$process$] mitre_attack_id: - T1059.003 observable: @@ -76,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/malicious_cmd_line_samples/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/malicious_cmd_line_samples/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_4104_hunting.yml b/detections/endpoint/powershell_4104_hunting.yml index a45ff1f00d..e02d365720 100644 --- a/detections/endpoint/powershell_4104_hunting.yml +++ b/detections/endpoint/powershell_4104_hunting.yml @@ -1,15 +1,18 @@ name: PowerShell 4104 Hunting id: d6f2b006-0041-11ec-8885-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: Hunting -description: The following Hunting analytic assists with identifying suspicious PowerShell - execution using Script Block Logging, or EventCode 4104. This analytic is not meant - to be ran hourly, but occasionally to identify malicious or suspicious PowerShell. - This analytic is a combination of work completed by Alex Teixeira and Splunk Threat - Research Team. +description: The following analytic identifies suspicious PowerShell execution using + Script Block Logging (EventCode 4104). It leverages specific patterns and keywords + within the ScriptBlockText field to detect potentially malicious activities. This + detection is significant for SOC analysts as PowerShell is commonly used by attackers + for various malicious purposes, including code execution, privilege escalation, + and persistence. If confirmed malicious, this activity could allow attackers to + execute arbitrary commands, exfiltrate data, or maintain long-term access to the + compromised system, posing a severe threat to the organization's security. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 | eval DoIt = if(match(ScriptBlockText,"(?i)(\$doit)"), @@ -96,6 +99,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell___connect_to_internet_with_hidden_window.yml b/detections/endpoint/powershell___connect_to_internet_with_hidden_window.yml index 02e44f1c10..9f971e9dbb 100644 --- a/detections/endpoint/powershell___connect_to_internet_with_hidden_window.yml +++ b/detections/endpoint/powershell___connect_to_internet_with_hidden_window.yml @@ -1,27 +1,27 @@ name: PowerShell - Connect To Internet With Hidden Window id: ee18ed37-0802-4268-9435-b3b91aaa18db -version: 8 -date: '2023-04-14' +version: 9 +date: '2024-05-12' author: David Dorsey, Michael Haag Splunk status: production type: Hunting -description: The following hunting analytic identifies PowerShell commands utilizing - the WindowStyle parameter to hide the window on the compromised endpoint. This combination - of command-line options is suspicious because it is overriding the default PowerShell - execution policy, attempts to hide its activity from the user, and connects to the - Internet. Removed in this version of the query is New-Object. The analytic identifies - all variations of WindowStyle, as PowerShell allows the ability to shorten the parameter. - For example w, win, windowsty and so forth. In addition, through our research it - was identified that PowerShell will interpret different command switch types beyond - the hyphen. We have added endash, emdash, horizontal bar, and forward slash. +description: The following analytic detects PowerShell commands using the WindowStyle + parameter to hide the window while connecting to the Internet. This behavior is + identified through Endpoint Detection and Response (EDR) telemetry, focusing on + command-line executions that include variations of the WindowStyle parameter. This + activity is significant because it attempts to bypass default PowerShell execution + policies and conceal its actions, which is often indicative of malicious intent. + If confirmed malicious, this could allow an attacker to execute commands stealthily, + potentially leading to unauthorized data exfiltration or further compromise of the + endpoint. data_source: - Sysmon EventID 1 search: "| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_powershell` by Processes.user Processes.process_name Processes.process Processes.parent_process_name Processes.original_file_name Processes.dest Processes.process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | where match(process,\"(?i)[\\-|\\/|\u2013 - |\u2014|\u2015]w(in*d*o*w*s*t*y*l*e*)*\\s+[^-]\") | `powershell___connect_to_internet_with_hidden_window_filter`" + | `security_content_ctime(lastTime)` | where match(process,\"(?i)[\\-|\\/|– |—|―]w(in*d*o*w*s*t*y*l*e*)*\\\ + s+[^-]\") | `powershell___connect_to_internet_with_hidden_window_filter`" how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -88,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/hidden_powershell/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/hidden_powershell/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_creating_thread_mutex.yml b/detections/endpoint/powershell_creating_thread_mutex.yml index d90ba567e9..a8d2094a2c 100644 --- a/detections/endpoint/powershell_creating_thread_mutex.yml +++ b/detections/endpoint/powershell_creating_thread_mutex.yml @@ -1,22 +1,24 @@ name: Powershell Creating Thread Mutex id: 637557ec-ca08-11eb-bd0a-acde48001122 -version: 3 -date: '2022-05-02' +version: 4 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104 that is using the `mutex` function. This function is commonly - seen in some obfuscated PowerShell scripts to make sure that only one instance of - there process is running on a compromise machine. During triage, review parallel - processes within the same timeframe. Review the full script block to identify other - related artifacts. +description: The following analytic detects the execution of PowerShell scripts using + the `mutex` function via EventCode 4104. This detection leverages PowerShell Script + Block Logging to identify scripts that create thread mutexes, a technique often + used in obfuscated scripts to ensure only one instance runs on a compromised machine. + This activity is significant as it may indicate the presence of sophisticated malware + or persistence mechanisms. If confirmed malicious, the attacker could maintain exclusive + control over a process, potentially leading to further exploitation or persistence + within the environment. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Threading.Mutex*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `powershell_creating_thread_mutex_filter`' + Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `powershell_creating_thread_mutex_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -63,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_domain_enumeration.yml b/detections/endpoint/powershell_domain_enumeration.yml index 5513991c3b..a1aff99a00 100644 --- a/detections/endpoint/powershell_domain_enumeration.yml +++ b/detections/endpoint/powershell_domain_enumeration.yml @@ -1,22 +1,18 @@ name: PowerShell Domain Enumeration id: e1866ce2-ca22-11eb-8e44-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies specific PowerShell modules typically used to enumerate - an organizations domain or users. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of PowerShell commands + used for domain enumeration, such as `get-netdomaintrust` and `get-adgroupmember`. + It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze + the full command sent to PowerShell. This activity is significant as it often indicates + reconnaissance efforts by an attacker to map out the domain structure and identify + key users and groups. If confirmed malicious, this behavior could lead to further + targeted attacks, privilege escalation, and unauthorized access to sensitive information + within the domain.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN (*get-netdomaintrust*, *get-netforesttrust*, @@ -73,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/enumeration.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/enumeration.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_enable_powershell_remoting.yml b/detections/endpoint/powershell_enable_powershell_remoting.yml index e40f86c31e..1fc3db9be9 100644 --- a/detections/endpoint/powershell_enable_powershell_remoting.yml +++ b/detections/endpoint/powershell_enable_powershell_remoting.yml @@ -1,22 +1,29 @@ name: PowerShell Enable PowerShell Remoting id: 40e3b299-19a5-4460-96e9-e1467f714f8e -version: 1 -date: '2023-03-22' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk type: Anomaly status: production -data_source: +data_source: - Powershell Script Block Logging 4104 -description: This analytic utilizes PowerShell Script Block Logging (EventCode 4104) to identify the use of Enable-PSRemoting cmdlet. This cmdlet allows users to enable PowerShell remoting on a local or remote computer, which allows other computers to run commands on the target computer. The ability to remotely execute commands can be abused by attackers to take control of compromised systems and pivot to other systems on the network. - By detecting the use of Enable-PSRemoting cmdlet via script block logging, this analytic can help organizations identify potential malicious activity related to attackers attempting to gain remote control of compromised systems. -search: '`powershell` EventCode=4104 ScriptBlockText="*Enable-PSRemoting*" - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `powershell_enable_powershell_remoting_filter`' +description: The following analytic detects the use of the Enable-PSRemoting cmdlet, + which allows PowerShell remoting on a local or remote computer. This detection leverages + PowerShell Script Block Logging (EventCode 4104) to identify when this cmdlet is + executed. Monitoring this activity is crucial as it can indicate an attacker enabling + remote command execution capabilities on a compromised system. If confirmed malicious, + this activity could allow an attacker to take control of the system remotely, execute + commands, and potentially pivot to other systems within the network, leading to + further compromise and lateral movement. +search: '`powershell` EventCode=4104 ScriptBlockText="*Enable-PSRemoting*" | stats + count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `powershell_enable_powershell_remoting_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: Note that false positives may occur due to the use of the Enable-PSRemoting cmdlet by legitimate users, such as system administrators. It is recommended to apply appropriate filters as needed to minimize the number of false positives. +known_false_positives: Note that false positives may occur due to the use of the Enable-PSRemoting + cmdlet by legitimate users, such as system administrators. It is recommended to + apply appropriate filters as needed to minimize the number of false positives. references: - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enable-psremoting?view=powershell-7.3 tags: @@ -48,6 +55,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/4104-psremoting-windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/4104-psremoting-windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_enable_smb1protocol_feature.yml b/detections/endpoint/powershell_enable_smb1protocol_feature.yml index fea7e6e90b..21aa4a6bf1 100644 --- a/detections/endpoint/powershell_enable_smb1protocol_feature.yml +++ b/detections/endpoint/powershell_enable_smb1protocol_feature.yml @@ -1,14 +1,17 @@ name: Powershell Enable SMB1Protocol Feature id: afed80b2-d34b-11eb-a952-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious enabling of smb1protocol through - `powershell.exe`. This technique was seen in some ransomware (like reddot) where - it enable smb share to do the lateral movement and encrypt other files within the - compromise network system. +description: The following analytic detects the enabling of the SMB1 protocol via + `powershell.exe`. It leverages PowerShell script block logging (EventCode 4104) + to identify the execution of the `Enable-WindowsOptionalFeature` cmdlet with the + `SMB1Protocol` parameter. This activity is significant because enabling SMB1 can + facilitate lateral movement and file encryption by ransomware, such as RedDot. If + confirmed malicious, this action could allow an attacker to propagate through the + network, encrypt files, and potentially disrupt business operations. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Enable-WindowsOptionalFeature*" @@ -55,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_execute_com_object.yml b/detections/endpoint/powershell_execute_com_object.yml index a43bcad0f1..97984f444a 100644 --- a/detections/endpoint/powershell_execute_com_object.yml +++ b/detections/endpoint/powershell_execute_com_object.yml @@ -1,21 +1,23 @@ name: Powershell Execute COM Object id: 65711630-f9bf-11eb-8d72-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-09' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a COM CLSID execution through powershell. This - technique was seen in several adversaries and malware like ransomware conti where - it has a feature to execute command using COM Object. This technique may use by - network operator at some cases but a good indicator if some application want to - gain privilege escalation or bypass uac. +description: The following analytic detects the execution of a COM CLSID through PowerShell. + It leverages EventCode 4104 and searches for specific script block text indicating + the creation of a COM object. This activity is significant as it is commonly used + by adversaries and malware, such as the Conti ransomware, to execute commands, potentially + for privilege escalation or bypassing User Account Control (UAC). If confirmed malicious, + this technique could allow attackers to gain elevated privileges or persist within + the environment, posing a significant security risk. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*CreateInstance([type]::GetTypeFromCLSID*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `powershell_execute_com_object_filter`' + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `powershell_execute_com_object_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -57,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/pwh_com_object/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/pwh_com_object/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml b/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml index c60b958daf..e6c8b33ec8 100644 --- a/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml +++ b/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml @@ -1,32 +1,24 @@ name: Powershell Fileless Process Injection via GetProcAddress id: a26d9db4-c883-11eb-9d75-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable no critical endpoints or all. - - - This analytic identifies `GetProcAddress` in the script block. This is not normal - to be used by most PowerShell scripts and is typically unsafe/malicious. Many attack - toolkits use GetProcAddress to obtain code execution. - - In use, `$var_gpa = $var_unsafe_native_methods.GetMethod(GetProcAddress` and later - referenced/executed elsewhere. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the use of `GetProcAddress` in PowerShell + script blocks, leveraging PowerShell Script Block Logging (EventCode=4104). This + method captures the full command sent to PowerShell, which is then logged in Windows + event logs. The presence of `GetProcAddress` is unusual for typical PowerShell scripts + and often indicates malicious activity, as many attack toolkits use it to achieve + code execution. If confirmed malicious, this activity could allow an attacker to + execute arbitrary code, potentially leading to system compromise. Analysts should + review parallel processes and the entire logged script block for further investigation.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText=*getprocaddress* | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode - ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `powershell_fileless_process_injection_via_getprocaddress_filter`' + ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `powershell_fileless_process_injection_via_getprocaddress_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -71,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml b/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml index 4b916dc355..cc9b1ab5e6 100644 --- a/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml +++ b/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml @@ -1,31 +1,24 @@ name: Powershell Fileless Script Contains Base64 Encoded Content id: 8acbc04c-c882-11eb-b060-acde48001122 -version: 3 -date: '2023-04-05' +version: 4 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies `FromBase64String` within the script block. A typical malicious - instance will include additional code. - - Command example - `[Byte[]]$var_code = [System.Convert]::FromBase64String(38uqIyMjQ6rG....` - - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of PowerShell scripts containing + Base64 encoded content, specifically identifying the use of `FromBase64String`. + It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze + the full command sent to PowerShell. This activity is significant as Base64 encoding + is often used by attackers to obfuscate malicious payloads, making it harder to + detect. If confirmed malicious, this could lead to code execution, allowing attackers + to run arbitrary commands and potentially compromise the system.' search: '`powershell` EventCode=4104 ScriptBlockText = "*frombase64string*" OR ScriptBlockText = "*gnirtS46esaBmorF*" | stats count min(_time) as firstTime max(_time) as lastTime - by EventCode ScriptBlockText Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `powershell_fileless_script_contains_base64_encoded_content_filter`' + by EventCode ScriptBlockText Computer UserID | rename Computer as dest |rename UserID + as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `powershell_fileless_script_contains_base64_encoded_content_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -74,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/frombase64string.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/frombase64string.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_get_localgroup_discovery_with_script_block_logging.yml b/detections/endpoint/powershell_get_localgroup_discovery_with_script_block_logging.yml index 38085da731..549f09229e 100644 --- a/detections/endpoint/powershell_get_localgroup_discovery_with_script_block_logging.yml +++ b/detections/endpoint/powershell_get_localgroup_discovery_with_script_block_logging.yml @@ -1,31 +1,24 @@ name: Powershell Get LocalGroup Discovery with Script Block Logging id: d7c6ad22-155c-11ec-bb64-acde48001122 -version: 2 -date: '2022-04-26' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies PowerShell cmdlet - `get-localgroup` being ran. Typically, - by itself, is not malicious but may raise suspicion based on time of day, endpoint - and username. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of the PowerShell cmdlet + `get-localgroup` using PowerShell Script Block Logging (EventCode=4104). This method + captures the full command sent to PowerShell, providing detailed visibility into + script execution. Monitoring this activity is significant as it can indicate an + attempt to enumerate local groups, which may be a precursor to privilege escalation + or lateral movement. If confirmed malicious, an attacker could gain insights into + group memberships, potentially leading to unauthorized access or privilege abuse. + Review parallel processes and the entire script block for comprehensive analysis.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-localgroup*" | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode - ScriptBlockText | rename Computer as dest, UserID as user - | `security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` - | `powershell_get_localgroup_discovery_with_script_block_logging_filter`' + ScriptBlockText | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + |`security_content_ctime(lastTime)` | `powershell_get_localgroup_discovery_with_script_block_logging_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -72,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getlocalgroup.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/getlocalgroup.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml index 9111604b76..cf32efd7e0 100644 --- a/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml +++ b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml @@ -1,21 +1,29 @@ name: PowerShell Invoke CIMMethod CIMSession id: 651ee958-a433-471c-b264-39725b788b83 -version: 1 -date: '2023-03-22' +version: 2 +date: '2024-05-31' author: Michael Haag, Splunk type: Anomaly status: production data_source: - Powershell Script Block Logging 4104 -description: This analytic identifies the use of the New-CIMSession cmdlet being created along with the Invoke-CIMMethod cmdlet being used within PowerShell. This particular behavior is similar to the usage of the Invoke-WMIMethod cmdlet, which is known for executing WMI commands on targets using NTLMv2 pass-the-hash authentication. The New-CIMSession cmdlet allows users to create a new CIM session object for a specified computer system, which can then be used to execute CIM operations remotely. Similarly, the Invoke-CIMMethod cmdlet is used to invoke a specified method on one or more CIM objects. Therefore, the combination of New-CIMSession and Invoke-CIMMethod cmdlets in PowerShell can potentially indicate malicious behavior, and this analytic can help detect such activity. +description: The following analytic detects the creation of a New-CIMSession cmdlet + followed by the use of the Invoke-CIMMethod cmdlet within PowerShell. It leverages + PowerShell Script Block Logging to identify these specific cmdlets in the ScriptBlockText + field. This activity is significant because it mirrors the behavior of the Invoke-WMIMethod + cmdlet, often used for remote code execution via NTLMv2 pass-the-hash authentication. + If confirmed malicious, this could allow an attacker to execute commands remotely, + potentially leading to unauthorized access and control over targeted systems. search: '`powershell` EventCode=4104 ScriptBlockText IN ("*invoke-CIMMethod*", "*New-CimSession*") - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `powershell_invoke_cimmethod_cimsession_filter`' + | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode + ScriptBlockText | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `powershell_invoke_cimmethod_cimsession_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: False positives may be present based on third-party applications or administrators using CIM. It is recommended to apply appropriate filters as needed to minimize the number of false positives. +known_false_positives: False positives may be present based on third-party applications + or administrators using CIM. It is recommended to apply appropriate filters as needed + to minimize the number of false positives. references: - https://learn.microsoft.com/en-us/powershell/module/cimcmdlets/invoke-cimmethod?view=powershell-7.3 tags: @@ -25,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: PowerShell was identified running a Invoke-CIMMethod Invoke-CIMSession on $Computer$. + message: PowerShell was identified running a Invoke-CIMMethod Invoke-CIMSession + on $Computer$. mitre_attack_id: - T1047 observable: @@ -47,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/4104-cimmethod-windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/4104-cimmethod-windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_load_module_in_meterpreter.yml b/detections/endpoint/powershell_load_module_in_meterpreter.yml index bb1f1d3b45..68dedb6a49 100644 --- a/detections/endpoint/powershell_load_module_in_meterpreter.yml +++ b/detections/endpoint/powershell_load_module_in_meterpreter.yml @@ -1,23 +1,18 @@ name: Powershell Load Module in Meterpreter id: d5905da5-d050-48db-9259-018d8f034fcf -version: 1 -date: '2022-11-22' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies "MSF.Powershell","MSF.Powershell.Meterpreter","MSF.Powershell.Meterpreter.Kiwi","MSF.Powershell.Meterpreter.Transport" - being used. This behavior is related to when a Meterpreter session is started and - the operator runs load_kiwi. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the execution of suspicious PowerShell + commands associated with Meterpreter modules, such as "MSF.Powershell" and "MSF.Powershell.Meterpreter". + It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze + the full command sent to PowerShell. This activity is significant as it indicates + potential post-exploitation actions, including credential dumping and persistence + mechanisms. If confirmed malicious, an attacker could gain extensive control over + the compromised system, escalate privileges, and maintain long-term access, posing + a severe threat to the environment.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN ("*MSF.Powershell*","*MSF.Powershell.Meterpreter*","*MSF.Powershell.Meterpreter.Kiwi*","*MSF.Powershell.Meterpreter.Transport*") @@ -66,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/metasploit/msf.powershell.powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/metasploit/msf.powershell.powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/powershell_loading_dotnet_into_memory_via_reflection.yml b/detections/endpoint/powershell_loading_dotnet_into_memory_via_reflection.yml index 644cadad0b..29948081ed 100644 --- a/detections/endpoint/powershell_loading_dotnet_into_memory_via_reflection.yml +++ b/detections/endpoint/powershell_loading_dotnet_into_memory_via_reflection.yml @@ -1,26 +1,20 @@ name: PowerShell Loading DotNET into Memory via Reflection id: 85bc3f30-ca28-11eb-bd21-acde48001122 -version: 3 -date: '2023-04-05' +version: 4 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable no critical endpoints or all. - - - This analytic identifies the use of PowerShell loading .net assembly via reflection. - This is commonly found in malicious PowerShell usage, including Empire and Cobalt - Strike. In addition, the `load(` value may be modifed by removing `(` and it will - identify more events to review. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the use of PowerShell to load .NET assemblies + into memory via reflection, a technique often used in malicious activities such + as those by Empire and Cobalt Strike. It leverages PowerShell Script Block Logging + (EventCode=4104) to capture and analyze the full command executed. This behavior + is significant as it can indicate advanced attack techniques aiming to execute code + in memory, bypassing traditional defenses. If confirmed malicious, this activity + could lead to unauthorized code execution, privilege escalation, and persistent + access within the environment.' search: '`powershell` EventCode=4104 ScriptBlockText IN ("*[system.reflection.assembly]::load(*","*[reflection.assembly]*", "*reflection.assembly*") | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText | `security_content_ctime(firstTime)` @@ -78,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/reflection.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/reflection.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_processing_stream_of_data.yml b/detections/endpoint/powershell_processing_stream_of_data.yml index 43cdb8188a..56184299fa 100644 --- a/detections/endpoint/powershell_processing_stream_of_data.yml +++ b/detections/endpoint/powershell_processing_stream_of_data.yml @@ -1,16 +1,17 @@ name: Powershell Processing Stream Of Data id: 0d718b52-c9f1-11eb-bc61-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104 that is processing compressed stream data. This is typically - found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files - that are stream flattened and will be deflated durnig execution. During triage, - review parallel processes within the same timeframe. Review the full script block - to identify other related artifacts. +description: The following analytic detects suspicious PowerShell script execution + involving compressed stream data processing, identified via EventCode 4104. It leverages + PowerShell Script Block Logging to flag scripts using `IO.Compression`, `IO.StreamReader`, + or decompression methods. This activity is significant as it often indicates obfuscated + PowerShell or embedded .NET/binary execution, which are common tactics for evading + detection. If confirmed malicious, this behavior could allow attackers to execute + hidden code, escalate privileges, or maintain persistence within the environment. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*IO.Compression.*" OR ScriptBlockText @@ -70,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/streamreader.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/streamreader.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_remote_services_add_trustedhost.yml b/detections/endpoint/powershell_remote_services_add_trustedhost.yml index 846180622b..c8f4b8d880 100644 --- a/detections/endpoint/powershell_remote_services_add_trustedhost.yml +++ b/detections/endpoint/powershell_remote_services_add_trustedhost.yml @@ -1,28 +1,30 @@ name: Powershell Remote Services Add TrustedHost id: bef21d24-297e-45e3-9b9a-c6ac45450474 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 - that contains command to add or modify the trustedhost configuration in Windows OS. - This behavior raises concerns due to the nature of modifications made to the 'TrustedHost' configuration, - which typically involves adjusting settings crucial for remote connections and security protocols. - Alterations in this area could potentially indicate attempts to manipulate trusted hosts or systems - for unauthorized remote access, a tactic commonly observed in various unauthorized access or compromise attempts. -search: '`powershell` EventCode=4104 ScriptBlockText = "*WSMan:\\localhost\\Client\\TrustedHosts*" ScriptBlockText IN ("* -Value *", "* -Concatenate *") - | rename Computer as dest, UserID as user - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of a PowerShell script that + modifies the 'TrustedHosts' configuration via EventCode 4104. It leverages PowerShell + Script Block Logging to identify commands targeting WSMan settings, specifically + those altering or concatenating trusted hosts. This activity is significant as it + can indicate attempts to manipulate remote connection settings, potentially allowing + unauthorized remote access. If confirmed malicious, this could enable attackers + to establish persistent remote connections, bypass security protocols, and gain + unauthorized access to sensitive systems and data. +search: '`powershell` EventCode=4104 ScriptBlockText = "*WSMan:\\localhost\\Client\\TrustedHosts*" + ScriptBlockText IN ("* -Value *", "* -Concatenate *") | rename Computer as dest, + UserID as user | stats count min(_time) as firstTime max(_time) as lastTime by EventCode + ScriptBlockText dest user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_remote_services_add_trustedhost_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: user and network administrator may used this function to add trusted host. +known_false_positives: user and network administrator may used this function to add + trusted host. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.darkgate tags: @@ -60,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/wsman_trustedhost/wsman_pwh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/wsman_trustedhost/wsman_pwh.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/powershell_remote_thread_to_known_windows_process.yml b/detections/endpoint/powershell_remote_thread_to_known_windows_process.yml index 40509da7c7..292b8a1164 100644 --- a/detections/endpoint/powershell_remote_thread_to_known_windows_process.yml +++ b/detections/endpoint/powershell_remote_thread_to_known_windows_process.yml @@ -1,15 +1,18 @@ name: Powershell Remote Thread To Known Windows Process id: ec102cb2-a0f5-11eb-9b38-acde48001122 -version: 2 -date: '2022-08-25' +version: 3 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: this search is designed to detect suspicious powershell process that - tries to inject code and to known/critical windows process and execute it using - CreateRemoteThread. This technique is seen in several malware like trickbot and - offensive tooling like cobaltstrike where it load a shellcode to svchost.exe to - execute reverse shell to c2 and download another payload +description: The following analytic detects suspicious PowerShell processes attempting + to inject code into critical Windows processes using CreateRemoteThread. It leverages + Sysmon EventCode 8 to identify instances where PowerShell spawns threads in processes + like svchost.exe, csrss.exe, and others. This activity is significant as it is commonly + used by malware such as TrickBot and offensive tools like Cobalt Strike to execute + malicious payloads, establish reverse shells, or download additional malware. If + confirmed malicious, this behavior could lead to unauthorized code execution, privilege + escalation, and persistent access within the environment. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode = 8 parent_process_name IN ("powershell_ise.exe", "powershell.exe") @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_remove_windows_defender_directory.yml b/detections/endpoint/powershell_remove_windows_defender_directory.yml index e1cca5044e..eda9198315 100644 --- a/detections/endpoint/powershell_remove_windows_defender_directory.yml +++ b/detections/endpoint/powershell_remove_windows_defender_directory.yml @@ -1,21 +1,23 @@ name: Powershell Remove Windows Defender Directory id: adf47620-79fa-11ec-b248-acde48001122 -version: 3 -date: '2023-04-14' +version: 4 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will identify a suspicious PowerShell command used to delete - the Windows Defender folder. This technique was seen used by the WhisperGate malware - campaign where it used Nirsofts advancedrun.exe to gain administrative privileges - to then execute a PowerShell command to delete the Windows Defender folder. This - is a good indicator the offending process is trying corrupt a Windows Defender installation. +description: The following analytic detects a suspicious PowerShell command attempting + to delete the Windows Defender directory. It leverages PowerShell Script Block Logging + to identify commands containing "rmdir" and targeting the Windows Defender path. + This activity is significant as it may indicate an attempt to disable or corrupt + Windows Defender, a key security component. If confirmed malicious, this action + could allow an attacker to bypass endpoint protection, facilitating further malicious + activities without detection. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*rmdir *" AND ScriptBlockText = "*\\Microsoft\\Windows Defender*" | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `powershell_remove_windows_defender_directory_filter` ' + | `security_content_ctime(lastTime)` | `powershell_remove_windows_defender_directory_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -58,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_script_block_with_url_chain.yml b/detections/endpoint/powershell_script_block_with_url_chain.yml index 694e2e5e22..66e0a38616 100644 --- a/detections/endpoint/powershell_script_block_with_url_chain.yml +++ b/detections/endpoint/powershell_script_block_with_url_chain.yml @@ -1,27 +1,31 @@ name: PowerShell Script Block With URL Chain id: 4a3f2a7d-6402-4e64-a76a-869588ec3b57 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-30' author: Steven Dick status: production type: TTP -description: The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 that contains multiple URLs within a function or array. - This is typically found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are attempting to download 2nd stage payloads. - During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +description: The following analytic identifies suspicious PowerShell script execution + via EventCode 4104 that contains multiple URLs within a function or array. It leverages + PowerShell operational logs to detect script blocks with embedded URLs, often indicative + of obfuscated scripts or those attempting to download secondary payloads. This activity + is significant as it may signal an attempt to execute malicious code or download + additional malware. If confirmed malicious, this could lead to code execution, further + system compromise, or data exfiltration. Review parallel processes and the full + script block for additional context and related artifacts. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 ScriptBlockText IN ("*http:*","*https:*") - | regex ScriptBlockText="(\"?(https?:\/\/(?:www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()@:%_\+.~#?&\/=]*))\"?(?:,|\))?){2,}" +search: '`powershell` EventCode=4104 ScriptBlockText IN ("*http:*","*https:*") | regex + ScriptBlockText="(\"?(https?:\/\/(?:www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()@:%_\+.~#?&\/=]*))\"?(?:,|\))?){2,}" | rex max_match=20 field=ScriptBlockText "(?https?:\/\/(?:www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()@:%_\+.~#?&\/=]*))" - | eval Path = case(isnotnull(Path),Path,true(),"unknown") - | stats count min(_time) as firstTime max(_time) as lastTime list(ScriptBlockText) as command values(Path) as file_name values(UserID) as user values(url) as url dc(url) as url_count by ActivityID, Computer, EventCode - | rename Computer as dest, EventCode as signature_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `powershell_script_block_with_url_chain_filter`' -how_to_implement: The following analytic requires PowerShell operational logs - to be imported. Modify the powershell macro as needed to match the sourcetype or - add index. This analytic is specific to 4104, or PowerShell Script Block Logging. + | eval Path = case(isnotnull(Path),Path,true(),"unknown") | stats count min(_time) + as firstTime max(_time) as lastTime list(ScriptBlockText) as command values(Path) + as file_name values(UserID) as user values(url) as url dc(url) as url_count by ActivityID, + Computer, EventCode | rename Computer as dest, EventCode as signature_id | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `powershell_script_block_with_url_chain_filter`' +how_to_implement: The following analytic requires PowerShell operational logs to be + imported. Modify the powershell macro as needed to match the sourcetype or add index. + This analytic is specific to 4104, or PowerShell Script Block Logging. known_false_positives: Unknown, possible custom scripting. references: - https://www.mandiant.com/resources/blog/tracking-evolution-gootloader-operations @@ -33,10 +37,11 @@ tags: asset_type: Endpoint confidence: 80 impact: 100 - message: A suspicious powershell script used by $user$ on host $dest$ contains $url_count$ URLs in an array, this is commonly used for malware. + message: A suspicious powershell script used by $user$ on host $dest$ contains $url_count$ + URLs in an array, this is commonly used for malware. mitre_attack_id: - - T1059.001 - - T1105 + - T1059.001 + - T1105 observable: - name: dest type: Endpoint @@ -69,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/powershell_start_bitstransfer.yml b/detections/endpoint/powershell_start_bitstransfer.yml index b5bc61d649..f919c87e47 100644 --- a/detections/endpoint/powershell_start_bitstransfer.yml +++ b/detections/endpoint/powershell_start_bitstransfer.yml @@ -1,17 +1,18 @@ name: PowerShell Start-BitsTransfer id: 39e2605a-90d8-11eb-899e-acde48001122 -version: 2 -date: '2021-03-29' +version: 3 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: Start-BitsTransfer is the PowerShell "version" of BitsAdmin.exe. Similar - functionality is present. This technique variation is not as commonly used by adversaries, - but has been abused in the past. Lesser known uses include the ability to set the - `-TransferType` to `Upload` for exfiltration of files. In an instance where `Upload` - is used, it is highly possible files will be archived. During triage, review parallel - processes and process lineage. Capture any files on disk and review. For the remote - domain or IP, what is the reputation? +description: The following analytic detects the execution of the PowerShell command + `Start-BitsTransfer`, which can be used for file transfers, including potential + data exfiltration. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process creation events and command-line arguments. This activity + is significant because `Start-BitsTransfer` can be abused by adversaries to upload + sensitive files to remote locations, posing a risk of data loss. If confirmed malicious, + this could lead to unauthorized data exfiltration, compromising sensitive information + and potentially leading to further exploitation of the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1197/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_start_or_stop_service.yml b/detections/endpoint/powershell_start_or_stop_service.yml index 625f5eff19..abd5ec0598 100644 --- a/detections/endpoint/powershell_start_or_stop_service.yml +++ b/detections/endpoint/powershell_start_or_stop_service.yml @@ -1,26 +1,34 @@ name: PowerShell Start or Stop Service id: 04207f8a-e08d-4ee6-be26-1e0c4488b04a -version: 1 -date: '2023-03-24' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk type: Anomaly status: production -data_source: +data_source: - Powershell Script Block Logging 4104 -description: This analytic identifies the use of PowerShell's Start-Service or Stop-Service cmdlets on an endpoint. These cmdlets allow users to start or stop a specified Windows service. The ability to manipulate services can be leveraged by attackers to disable or stop critical services, which can cause system instability or disrupt business operations. - By detecting the use of Start-Service or Stop-Service cmdlets via PowerShell, this analytic can help organizations identify potential malicious activity related to attackers attempting to manipulate services on compromised systems. However, note that this behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats. -search: '`powershell` EventCode=4104 ScriptBlockText IN ("*start-service*", "*stop-service*") - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the use of PowerShell's Start-Service + or Stop-Service cmdlets on an endpoint. It leverages PowerShell Script Block Logging + to detect these commands. This activity is significant because attackers can manipulate + services to disable or stop critical functions, causing system instability or disrupting + business operations. If confirmed malicious, this behavior could allow attackers + to disable security services, evade detection, or disrupt essential services, leading + to potential system downtime and compromised security. +search: '`powershell` EventCode=4104 ScriptBlockText IN ("*start-service*", "*stop-service*") + | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode + ScriptBlockText | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_start_or_stop_service_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: This behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats. +known_false_positives: This behavior may be noisy, as these cmdlets are commonly used + by system administrators or other legitimate users to manage services. Therefore, + it is recommended not to enable this analytic as a direct notable or TTP. Instead, + it should be used as part of a broader set of security controls to detect and investigate + potential threats. references: - - https://learn-powershell.net/2012/01/15/startingstopping-and-restarting-remote-services-with-powershell/ - - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-service?view=powershell-7.3 +- https://learn-powershell.net/2012/01/15/startingstopping-and-restarting-remote-services-with-powershell/ +- https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-service?view=powershell-7.3 tags: analytic_story: - Active Directory Lateral Movement @@ -49,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/start_stop_service_windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/start_stop_service_windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_using_memory_as_backing_store.yml b/detections/endpoint/powershell_using_memory_as_backing_store.yml index 17d6e6d67f..af0da3f683 100644 --- a/detections/endpoint/powershell_using_memory_as_backing_store.yml +++ b/detections/endpoint/powershell_using_memory_as_backing_store.yml @@ -1,21 +1,25 @@ name: Powershell Using memory As Backing Store id: c396a0c4-c9f2-11eb-b4f5-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104 that is using memory stream as new object backstore. The malicious - PowerShell script will contain stream flate data and will be decompressed in memory - to run or drop the actual payload. During triage, review parallel processes within - the same timeframe. Review the full script block to identify other related artifacts. +description: The following analytic detects suspicious PowerShell script execution + using memory streams as a backing store, identified via EventCode 4104. It leverages + PowerShell Script Block Logging to capture scripts that create new objects with + memory streams, often used to decompress and execute payloads in memory. This activity + is significant as it indicates potential in-memory execution of malicious code, + bypassing traditional file-based detection. If confirmed malicious, this technique + could allow attackers to execute arbitrary code, maintain persistence, or escalate + privileges without leaving a trace on the disk. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = *New-Object* ScriptBlockText = *IO.MemoryStream* | stats count min(_time) as firstTime max(_time) as lastTime - by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `powershell_using_memory_as_backing_store_filter`' + by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename + UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `powershell_using_memory_as_backing_store_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/pwsh/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/pwsh/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/powershell_windows_defender_exclusion_commands.yml b/detections/endpoint/powershell_windows_defender_exclusion_commands.yml index dd67d66949..9edee81398 100644 --- a/detections/endpoint/powershell_windows_defender_exclusion_commands.yml +++ b/detections/endpoint/powershell_windows_defender_exclusion_commands.yml @@ -1,21 +1,23 @@ name: Powershell Windows Defender Exclusion Commands id: 907ac95c-4dd9-11ec-ba2c-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will detect a suspicious process commandline related to - windows defender exclusion feature. This command is abused by adversaries, malware - author and red teams to bypassed Windows Defender Anti-Virus product by excluding folder - path, file path, process, extensions and etc. from its real time or schedule scan - to execute their malicious code. This is a good indicator for defense evasion and - to look further for events after this behavior. +description: The following analytic detects the use of PowerShell commands to add + or set Windows Defender exclusions. It leverages EventCode 4104 to identify suspicious + `Add-MpPreference` or `Set-MpPreference` commands with exclusion parameters. This + activity is significant because adversaries often use it to bypass Windows Defender, + allowing malicious code to execute without detection. If confirmed malicious, this + behavior could enable attackers to evade antivirus defenses, maintain persistence, + and execute further malicious activities undetected. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 (ScriptBlockText = "*Add-MpPreference *" OR ScriptBlockText = - "*Set-MpPreference *") AND ScriptBlockText = "*-exclusion*" | stats count min(_time) as - firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` +search: '`powershell` EventCode=4104 (ScriptBlockText = "*Add-MpPreference *" OR ScriptBlockText + = "*Set-MpPreference *") AND ScriptBlockText = "*-exclusion*" | stats count min(_time) + as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID + | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_windows_defender_exclusion_commands_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -58,14 +60,15 @@ tags: required_fields: - _time - EventCode - - Message - - ComputerName - - User + - ScriptBlockText + - Computer + - UserID risk_score: 64 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/powershell_windows_defender_exclusion_commands/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/powershell_windows_defender_exclusion_commands/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/print_processor_registry_autostart.yml b/detections/endpoint/print_processor_registry_autostart.yml index 6f583234c7..1ed17ebb5e 100644 --- a/detections/endpoint/print_processor_registry_autostart.yml +++ b/detections/endpoint/print_processor_registry_autostart.yml @@ -1,15 +1,17 @@ name: Print Processor Registry Autostart id: 1f5b68aa-2037-11ec-898e-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: experimental type: TTP -description: This analytic is to detect a suspicious modification or new registry - entry regarding print processor. This registry is known to be abuse by turla or - other APT to gain persistence and privilege escalation to the compromised machine. - This is done by adding the malicious dll payload on the new created key in this - registry that will be executed as it restarted the spoolsv.exe process and services. +description: The following analytic detects suspicious modifications or new entries + in the Print Processor registry path. It leverages registry activity data from the + Endpoint data model to identify changes in the specified registry path. This activity + is significant because the Print Processor registry is known to be exploited by + APT groups like Turla for persistence and privilege escalation. If confirmed malicious, + this could allow an attacker to execute a malicious DLL payload by restarting the + spoolsv.exe process, leading to potential control over the compromised machine. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/1f5b68aa-2037-11ec-898e-acde48001122.txt + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/1f5b68aa-2037-11ec-898e-acde48001122.txt source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/print_spooler_adding_a_printer_driver.yml b/detections/endpoint/print_spooler_adding_a_printer_driver.yml index ab2dc907a5..3952fd8e68 100644 --- a/detections/endpoint/print_spooler_adding_a_printer_driver.yml +++ b/detections/endpoint/print_spooler_adding_a_printer_driver.yml @@ -1,22 +1,18 @@ name: Print Spooler Adding A Printer Driver id: 313681a2-da8e-11eb-adad-acde48001122 -version: 1 -date: '2021-07-01' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Michael Haag, Teoderick Contreras, Splunk status: production type: TTP -description: 'The following analytic identifies new printer drivers being load by - utilizing the Windows PrintService operational logs, EventCode 316. This was identified - during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. - - - Within the proof of concept code, the following event will occur - "Printer driver - 1234 for Windows x64 Version-3 was added or updated. Files:- UNIDRV.DLL, kernelbase.dll, - evil.dll. No user action is required." - - During triage, isolate the endpoint and review for source of exploitation. Capture - any additional file modification events and review the source of where the exploitation - began.' +description: 'The following analytic detects the addition of new printer drivers by + monitoring Windows PrintService operational logs, specifically EventCode 316. This + detection leverages log data to identify messages indicating the addition or update + of printer drivers, such as "kernelbase.dll" and "UNIDRV.DLL." This activity is + significant as it may indicate exploitation attempts related to vulnerabilities + like CVE-2021-34527 (PrintNightmare). If confirmed malicious, attackers could gain + code execution or escalate privileges, potentially compromising the affected system. + Immediate isolation and investigation of the endpoint are recommended.' data_source: - Windows Event Log Printservice 316 search: '`printservice` EventCode=316 category = "Adding a printer driver" Message @@ -65,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-printservice_operational.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-printservice_operational.log source: WinEventLog:Microsoft-Windows-PrintService/Operational sourcetype: WinEventLog diff --git a/detections/endpoint/print_spooler_failed_to_load_a_plug_in.yml b/detections/endpoint/print_spooler_failed_to_load_a_plug_in.yml index 17bc87f66c..335ac79e6e 100644 --- a/detections/endpoint/print_spooler_failed_to_load_a_plug_in.yml +++ b/detections/endpoint/print_spooler_failed_to_load_a_plug_in.yml @@ -1,22 +1,18 @@ name: Print Spooler Failed to Load a Plug-in id: 1adc9548-da7c-11eb-8f13-acde48001122 -version: 1 -date: '2021-07-01' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies driver load errors utilizing the Windows - PrintService Admin logs. This was identified during our testing of CVE-2021-34527 - previously (CVE-2021-1675) or PrintNightmare. - - Within the proof of concept code, the following error will occur - "The print spooler - failed to load a plug-in module C:\Windows\system32\spool\DRIVERS\x64\3\meterpreter.dll, - error code 0x45A. See the event user data for context information." - - The analytic is based on file path and failure to load the plug-in. - - During triage, isolate the endpoint and review for source of exploitation. Capture - any additional file modification events.' +description: 'The following analytic detects driver load errors in the Windows PrintService + Admin logs, specifically identifying issues related to CVE-2021-34527 (PrintNightmare). + It triggers on error messages indicating the print spooler failed to load a plug-in + module, such as "meterpreter.dll," with error code 0x45A. This detection method + leverages specific event codes and error messages. This activity is significant + as it may indicate an exploitation attempt of a known vulnerability. If confirmed + malicious, an attacker could gain unauthorized code execution on the affected system, + leading to potential system compromise.' data_source: - Windows Event Log Printservice 808 - Windows Event Log Printservice 4909 @@ -66,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-printservice_admin.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-printservice_admin.log source: WinEventLog:Microsoft-Windows-PrintService/Admin sourcetype: WinEventLog diff --git a/detections/endpoint/process_deleting_its_process_file_path.yml b/detections/endpoint/process_deleting_its_process_file_path.yml index c7fc573d18..7a5942249f 100644 --- a/detections/endpoint/process_deleting_its_process_file_path.yml +++ b/detections/endpoint/process_deleting_its_process_file_path.yml @@ -1,15 +1,18 @@ name: Process Deleting Its Process File Path id: f7eda4bc-871c-11eb-b110-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-27' author: Teoderick Contreras status: production type: TTP -description: This detection is to identify a suspicious process that tries to delete - the process file path related to its process. This technique is known to be defense - evasion once a certain condition of malware is satisfied or not. Clop ransomware - use this technique where it will try to delete its process file path using a .bat - command if the keyboard layout is not the layout it tries to infect. +description: The following analytic identifies a process attempting to delete its + own file path, a behavior often associated with defense evasion techniques. This + detection leverages Sysmon EventCode 1 logs, focusing on command lines executed + via cmd.exe that include deletion commands. This activity is significant as it may + indicate malware, such as Clop ransomware, trying to evade detection by removing + its executable file if certain conditions are met. If confirmed malicious, this + could allow the attacker to persist undetected, complicating incident response and + remediation efforts. data_source: - Sysmon EventID 1 search: '`sysmon` EventCode=1 CommandLine = "* /c *" CommandLine = "* del*" Image @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/process_execution_via_wmi.yml b/detections/endpoint/process_execution_via_wmi.yml index e61bb49661..7516cc6bb5 100644 --- a/detections/endpoint/process_execution_via_wmi.yml +++ b/detections/endpoint/process_execution_via_wmi.yml @@ -1,22 +1,28 @@ name: Process Execution via WMI id: 24869767-8579-485d-9a4f-d9ddfd8f0cac -version: 5 -date: '2020-03-16' +version: 6 +date: '2024-05-22' author: Rico Valdez, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies `WmiPrvSE.exe` spawning a process. - This typically occurs when a process is instantiated from a local or remote process - using `wmic.exe`. During triage, review parallel processes for suspicious behavior - or commands executed. Review the process and command-line spawning from `wmiprvse.exe`. - Contain and remediate the endpoint as necessary. +description: The following analytic detects the execution of a process by `WmiPrvSE.exe`, + indicating potential use of WMI (Windows Management Instrumentation) for process + creation. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process and parent process relationships. This activity is significant + as WMI can be used for lateral movement, remote code execution, or persistence by + attackers. If confirmed malicious, this could allow an attacker to execute arbitrary + commands or scripts, potentially leading to further compromise of the affected system + or network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=WmiPrvSE.exe NOT (Processes.process IN ("*\\dismhost.exe*")) - by Processes.dest Processes.user Processes.parent_process Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `process_execution_via_wmi_filter` ' + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=WmiPrvSE.exe + NOT (Processes.process IN ("*\\dismhost.exe*")) by Processes.dest Processes.user + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `process_execution_via_wmi_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -35,7 +41,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A remote instance execution of wmic.exe by WmiPrvSE.exe detected on host - $dest$ + message: A remote instance execution of wmic.exe by WmiPrvSE.exe detected on host + - $dest$ mitre_attack_id: - T1047 observable: @@ -63,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/process_writing_dynamicwrapperx.yml b/detections/endpoint/process_writing_dynamicwrapperx.yml index 5b5c591842..f73f8a86b5 100644 --- a/detections/endpoint/process_writing_dynamicwrapperx.yml +++ b/detections/endpoint/process_writing_dynamicwrapperx.yml @@ -1,18 +1,18 @@ name: Process Writing DynamicWrapperX id: b0a078e4-2601-11ec-9aec-acde48001122 -version: 1 -date: '2021-10-05' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: Hunting -description: DynamicWrapperX is an ActiveX component that can be used in a script - to call Windows API functions, but it requires the dynwrapx.dll to be installed - and registered. With that, a binary writing dynwrapx.dll to disk and registering - it into the registry is highly suspect. Why is it needed? In most malicious instances, - it will be written to disk at a non-standard location. During triage, review parallel - processes and pivot on the process_guid. Review the registry for any suspicious - modifications meant to load dynwrapx.dll. Identify any suspicious module loads of - dynwrapx.dll. This will identify the process that will invoke vbs/wscript/cscript. +description: The following analytic detects a process writing the dynwrapx.dll file + to disk and registering it in the registry. It leverages data from the Endpoint + datamodel, specifically monitoring process and filesystem events. This activity + is significant because DynamicWrapperX is an ActiveX component often used in scripts + to call Windows API functions, and its presence in non-standard locations is highly + suspicious. If confirmed malicious, this could allow an attacker to execute arbitrary + code, escalate privileges, or maintain persistence within the environment. Immediate + investigation of parallel processes and registry modifications is recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -82,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/processes_launching_netsh.yml b/detections/endpoint/processes_launching_netsh.yml index c7b0336c50..9d7abc4478 100644 --- a/detections/endpoint/processes_launching_netsh.yml +++ b/detections/endpoint/processes_launching_netsh.yml @@ -1,16 +1,18 @@ name: Processes launching netsh id: b89919ed-fe5f-492c-b139-95dbb162040e -version: 4 -date: '2021-09-16' +version: 5 +date: '2024-05-24' author: Michael Haag, Josef Kuepker, Splunk status: production type: Anomaly -description: This search looks for processes launching netsh.exe. Netsh is a command-line - scripting utility that allows you to, either locally or remotely, display or modify - the network configuration of a computer that is currently running. Netsh can be - used as a persistence proxy technique to execute a helper DLL when netsh.exe is - executed. In this search, we are looking for processes spawned by netsh.exe and - executing commands via the command line. +description: The following analytic identifies processes launching netsh.exe, a command-line + utility used to modify network configurations. It detects this activity by analyzing + data from Endpoint Detection and Response (EDR) agents, focusing on process GUIDs, + names, parent processes, and command-line executions. This behavior is significant + because netsh.exe can be exploited to execute malicious helper DLLs, serving as + a persistence mechanism. If confirmed malicious, an attacker could gain persistent + access, modify network settings, and potentially escalate privileges, posing a severe + threat to the network's integrity and security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/processes_tapping_keyboard_events.yml b/detections/endpoint/processes_tapping_keyboard_events.yml index 83d459c9d2..78f429cedd 100644 --- a/detections/endpoint/processes_tapping_keyboard_events.yml +++ b/detections/endpoint/processes_tapping_keyboard_events.yml @@ -1,20 +1,25 @@ name: Processes Tapping Keyboard Events id: 2a371608-331d-4034-ae2c-21dda8f1d0ec -version: 1 -date: '2019-01-25' +version: 2 +date: '2024-05-13' author: Jose Hernandez, Splunk status: experimental type: TTP -description: This search looks for processes in an MacOS system that is tapping keyboard - events in MacOS, and essentially monitoring all keystrokes made by a user. This - is a common technique used by RATs to log keystrokes from a victim, although it - can also be used by legitimate processes like Siri to react on human input +description: The following analytic detects processes on macOS systems that are tapping + keyboard events, potentially monitoring all keystrokes made by a user. It leverages + data from osquery results within the Alerts data model, focusing on specific process + names and command lines. This activity is significant as it is a common technique + used by Remote Access Trojans (RATs) to log keystrokes, posing a serious security + risk. If confirmed malicious, this could lead to unauthorized access to sensitive + information, including passwords and personal data, compromising the integrity and + confidentiality of the system. data_source: [] search: '| from datamodel Alerts.Alerts | search app=osquery:results name=pack_osx-attacks_Keyboard_Event_Taps | rename columns.cmdline as cmd, columns.name as process_name, columns.pid as process_id| dedup host,process_name | table host,process_name, cmd, process_id | `processes_tapping_keyboard_events_filter`' how_to_implement: In order to properly run this search, Splunk needs to ingest data - from your osquery deployed agents with the [osx-attacks.conf](https://github.com/facebook/osquery/blob/experimental/packs/osx-attacks.conf#L599) + from your osquery deployed agents with the + [osx-attacks.conf](https://github.com/facebook/osquery/blob/experimental/packs/osx-attacks.conf#L599) pack enabled. Also the [TA-OSquery](https://github.com/d1vious/TA-osquery) must be deployed across your indexers and universal forwarders in order to have the osquery data populate the Alerts data model. diff --git a/detections/endpoint/randomly_generated_scheduled_task_name.yml b/detections/endpoint/randomly_generated_scheduled_task_name.yml index ce1163e1f6..ecb46d821e 100644 --- a/detections/endpoint/randomly_generated_scheduled_task_name.yml +++ b/detections/endpoint/randomly_generated_scheduled_task_name.yml @@ -1,21 +1,18 @@ name: Randomly Generated Scheduled Task Name id: 9d22a780-5165-11ec-ad4f-3e22fbd008af -version: 1 -date: '2021-11-29' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: experimental type: Hunting -description: The following hunting analytic leverages Event ID 4698, `A scheduled - task was created`, to identify the creation of a Scheduled Task with a suspicious, - high entropy, Task Name. To achieve this, this analytic also leverages the `ut_shannon` - function from the URL ToolBox Splunk application. Red teams and adversaries alike - may abuse the Task Scheduler to create and start a remote Scheduled Task and obtain - remote code execution. To achieve this goal, tools like Impacket or Crapmapexec, - typically create a Scheduled Task with a random task name on the victim host. This - hunting analytic may help defenders identify Scheduled Tasks created as part of - a lateral movement attack. The entropy threshold `ut_shannon > 3` should be customized - by users. The Command field can be used to determine if the task has malicious intent - or not. +description: The following analytic detects the creation of a Scheduled Task with + a high entropy, randomly generated name, leveraging Event ID 4698. It uses the `ut_shannon` + function from the URL ToolBox Splunk application to measure the entropy of the Task + Name. This activity is significant as adversaries often use randomly named Scheduled + Tasks for lateral movement and remote code execution, employing tools like Impacket + or CrackMapExec. If confirmed malicious, this could allow attackers to execute arbitrary + code remotely, potentially leading to further compromise and persistence within + the network. data_source: - Windows Event Log Security 4698 search: ' `wineventlog_security` EventCode=4698 | xmlkv Message | lookup ut_shannon_lookup diff --git a/detections/endpoint/randomly_generated_windows_service_name.yml b/detections/endpoint/randomly_generated_windows_service_name.yml index de14a6bd39..24a5d97d46 100644 --- a/detections/endpoint/randomly_generated_windows_service_name.yml +++ b/detections/endpoint/randomly_generated_windows_service_name.yml @@ -1,27 +1,22 @@ name: Randomly Generated Windows Service Name id: 2032a95a-5165-11ec-a2c3-3e22fbd008af -version: 1 -date: '2021-11-29' +version: 2 +date: '2024-05-30' author: Mauricio Velazco, Splunk status: experimental type: Hunting -description: The following hunting analytic leverages Event ID 7045, `A new service - was installed in the system`, to identify the installation of a Windows Service - with a suspicious, high entropy, Service Name. To achieve this, this analytic also - leverages the `ut_shannon` function from the URL ToolBox Splunk application. Red - teams and adversaries alike may abuse the Service Control Manager to create and - start a remote Windows Service and obtain remote code execution. To achieve this - goal, some tools like Metasploit, Cobalt Strike and Impacket, typically create a - Windows Service with a random service name on the victim host. This hunting analytic - may help defenders identify Windows Services installed as part of a lateral movement - attack. The entropy threshold `ut_shannon > 3` should be customized by users. The - Service_File_Name field can be used to determine if the Windows Service has malicious - intent or not. +description: The following analytic detects the installation of a Windows Service + with a suspicious, high-entropy name, indicating potential malicious activity. It + leverages Event ID 7045 and the `ut_shannon` function from the URL ToolBox Splunk + application to identify services with random names. This behavior is significant + as adversaries often use randomly named services for lateral movement and remote + code execution. If confirmed malicious, this activity could allow attackers to execute + arbitrary code, escalate privileges, or maintain persistence within the environment. data_source: - Windows Event Log System 7045 search: ' `wineventlog_system` EventCode=7045 | lookup ut_shannon_lookup word as Service_Name | where ut_shannon > 3 | table EventCode ComputerName Service_Name ut_shannon Service_Start_Type - Service_Type Service_File_Name | `randomly_generated_windows_service_name_filter` ' + Service_Type Service_File_Name | `randomly_generated_windows_service_name_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. The Windows TA as well as the URL ToolBox application are also diff --git a/detections/endpoint/ransomware_notes_bulk_creation.yml b/detections/endpoint/ransomware_notes_bulk_creation.yml index 5a8198bfaf..662f35efe9 100644 --- a/detections/endpoint/ransomware_notes_bulk_creation.yml +++ b/detections/endpoint/ransomware_notes_bulk_creation.yml @@ -1,22 +1,24 @@ name: Ransomware Notes bulk creation id: eff7919a-8330-11eb-83f8-acde48001122 -version: 1 -date: '2021-03-12' +version: 2 +date: '2024-05-25' author: Teoderick Contreras status: production type: Anomaly -description: The following analytics identifies a big number of instance of ransomware - notes (filetype e.g .txt, .html, .hta) file creation to the infected machine. This - behavior is a good sensor if the ransomware note filename is quite new for security - industry or the ransomware note filename is not in your ransomware lookup table - list for monitoring. +description: The following analytic identifies the bulk creation of ransomware notes + (e.g., .txt, .html, .hta files) on an infected machine. It leverages Sysmon EventCode + 11 to detect multiple instances of these file types being created within a short + time frame. This activity is significant as it often indicates an active ransomware + attack, where the attacker is notifying the victim of the encryption. If confirmed + malicious, this behavior could lead to widespread data encryption, rendering critical + files inaccessible and potentially causing significant operational disruption. data_source: - Sysmon EventID 11 search: '`sysmon` EventCode=11 file_name IN ("*\.txt","*\.html","*\.hta") |bin _time span=10s | stats min(_time) as firstTime max(_time) as lastTime dc(TargetFilename) as unique_readme_path_count values(TargetFilename) as list_of_readme_path by Computer - Image file_name | rename Computer as dest | where unique_readme_path_count >= 15 | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `ransomware_notes_bulk_creation_filter`' + Image file_name | rename Computer as dest | where unique_readme_path_count >= 15 + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `ransomware_notes_bulk_creation_filter`' how_to_implement: You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which @@ -62,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml b/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml index 32bfad1a2d..eedc4ade5b 100644 --- a/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml +++ b/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml @@ -1,23 +1,25 @@ name: Recon AVProduct Through Pwh or WMI id: 28077620-c9f6-11eb-8785-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104 performing checks to identify anti-virus products installed on - the endpoint. This technique is commonly found in malware and APT events where the - adversary will map all running security applications or services. During triage, - review parallel processes within the same timeframe. Review the full script block - to identify other related artifacts. +description: The following analytic detects suspicious PowerShell script execution + via EventCode 4104, specifically targeting checks for installed anti-virus products + using WMI or PowerShell commands. This detection leverages PowerShell Script Block + Logging to identify scripts containing keywords like "SELECT," "WMIC," "AntiVirusProduct," + or "AntiSpywareProduct." This activity is significant as it is commonly used by + malware and APT actors to map running security applications or services, potentially + aiding in evasion techniques. If confirmed malicious, this could allow attackers + to disable or bypass security measures, leading to further compromise of the endpoint. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*SELECT*" OR ScriptBlockText = "*WMIC*") AND (ScriptBlockText = "*AntiVirusProduct*" OR ScriptBlockText = "*AntiSpywareProduct*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `recon_avproduct_through_pwh_or_wmi_filter`' + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `recon_avproduct_through_pwh_or_wmi_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1592/pwh_av_recon/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1592/pwh_av_recon/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/recon_using_wmi_class.yml b/detections/endpoint/recon_using_wmi_class.yml index 0d09ba0f58..c38b04e789 100644 --- a/detections/endpoint/recon_using_wmi_class.yml +++ b/detections/endpoint/recon_using_wmi_class.yml @@ -1,16 +1,18 @@ name: Recon Using WMI Class id: 018c1972-ca07-11eb-9473-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies suspicious PowerShell via EventCode - 4104, where WMI is performing an event query looking for running processes or running - services. This technique is commonly found where the adversary will identify services - and system information on the compromised machine. During triage, review parallel - processes within the same timeframe. Review the full script block to identify other - related artifacts. +description: The following analytic detects suspicious PowerShell activity via EventCode + 4104, where WMI performs event queries to gather information on running processes + or services. This detection leverages PowerShell Script Block Logging to identify + specific WMI queries targeting system information classes like Win32_Bios and Win32_OperatingSystem. + This activity is significant as it often indicates reconnaissance efforts by an + adversary to profile the compromised machine. If confirmed malicious, the attacker + could gain detailed system information, aiding in further exploitation or lateral + movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText= "*SELECT*" OR ScriptBlockText= @@ -19,8 +21,8 @@ search: '`powershell` EventCode=4104 (ScriptBlockText= "*SELECT*" OR ScriptBlock OR ScriptBlockText= "*Win32_PnPEntity*" OR ScriptBlockText= "*Win32_ShadowCopy*" OR ScriptBlockText= "*Win32_DiskDrive*" OR ScriptBlockText= "*Win32_PhysicalMemory*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `recon_using_wmi_class_filter`' + Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `recon_using_wmi_class_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -46,7 +48,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 75 - message: A suspicious powershell script contains host recon commands detected on host $dest$ + message: A suspicious powershell script contains host recon commands detected on + host $dest$ mitre_attack_id: - T1592 - T1059.001 @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/reconusingwmi.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/reconusingwmi.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/recursive_delete_of_directory_in_batch_cmd.yml b/detections/endpoint/recursive_delete_of_directory_in_batch_cmd.yml index 35b06a0e4a..efef3925a2 100644 --- a/detections/endpoint/recursive_delete_of_directory_in_batch_cmd.yml +++ b/detections/endpoint/recursive_delete_of_directory_in_batch_cmd.yml @@ -1,14 +1,18 @@ name: Recursive Delete of Directory In Batch CMD id: ba570b3a-d356-11eb-8358-acde48001122 -version: 3 -date: '2022-11-12' +version: 4 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious commandline designed to delete - files or directory recursive using batch command. This technique was seen in ransomware - (reddot) where it it tries to delete the files in recycle bin to impaire user from - recovering deleted files. +description: The following analytic detects the execution of a batch command designed + to recursively delete files or directories, a technique often used by ransomware + like Reddot to delete files in the recycle bin and prevent recovery. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions that include specific flags for recursive and quiet deletions. This activity + is significant as it indicates potential ransomware behavior aimed at data destruction. + If confirmed malicious, it could lead to significant data loss and hinder recovery + efforts, severely impacting business operations. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/registry_keys_used_for_persistence.yml b/detections/endpoint/registry_keys_used_for_persistence.yml index 473156374a..c627f41d35 100644 --- a/detections/endpoint/registry_keys_used_for_persistence.yml +++ b/detections/endpoint/registry_keys_used_for_persistence.yml @@ -1,17 +1,19 @@ name: Registry Keys Used For Persistence id: f5f6af30-7aa7-4295-bfe9-07fe87c01a4b -version: 9 -date: '2023-12-27' +version: 10 +date: '2024-05-25' author: Jose Hernandez, David Dorsey, Teoderick Contreras, Rod Soto, Splunk status: production type: TTP -description: The search looks for modifications or alterations made to registry keys - that have the potential to initiate the launch of an application or service during - system startup. By monitoring and detecting modifications in these registry keys, - we can identify suspicious or unauthorized changes that could be indicative of malicious - activity. This proactive approach helps in safeguarding the system's integrity and - security by promptly identifying and mitigating potential threats that aim to gain - persistence or execute malicious actions during the startup process. +description: The following analytic identifies modifications to registry keys commonly + used for persistence mechanisms. It leverages data from endpoint detection sources + like Sysmon or Carbon Black, focusing on specific registry paths known to initiate + applications or services during system startup. This activity is significant as + unauthorized changes to these keys can indicate attempts to maintain persistence + or execute malicious actions upon system boot. If confirmed malicious, this could + allow attackers to achieve persistent access, execute arbitrary code, or maintain + control over compromised systems, posing a severe threat to system integrity and + security. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -105,6 +107,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/registry_keys_used_for_privilege_escalation.yml b/detections/endpoint/registry_keys_used_for_privilege_escalation.yml index e38075bdc0..f04259902b 100644 --- a/detections/endpoint/registry_keys_used_for_privilege_escalation.yml +++ b/detections/endpoint/registry_keys_used_for_privilege_escalation.yml @@ -1,22 +1,27 @@ name: Registry Keys Used For Privilege Escalation id: c9f4b923-f8af-4155-b697-1354f5bcbc5e -version: 7 -date: '2023-04-27' +version: 8 +date: '2024-05-18' author: Steven Dick, David Dorsey, Teoderick Contreras, Splunk status: production type: TTP -description: This search looks for modifications to registry keys that can be used - to elevate privileges. The registry keys under "Image File Execution Options" are - used to intercept calls to an executable and can be used to attach malicious binaries - to benign system binaries. +description: The following analytic detects modifications to registry keys under "Image + File Execution Options" that can be used for privilege escalation. It leverages + data from the Endpoint.Registry data model, specifically monitoring changes to registry + paths and values like GlobalFlag and Debugger. This activity is significant because + attackers can use these modifications to intercept executable calls and attach malicious + binaries to legitimate system binaries. If confirmed malicious, this could allow + attackers to execute arbitrary code with elevated privileges, leading to potential + system compromise and persistent access. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE ((Registry.registry_path="*Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options*") AND (Registry.registry_value_name=GlobalFlag OR Registry.registry_value_name=Debugger)) - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `registry_keys_used_for_privilege_escalation_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -68,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.012/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.012/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/regsvr32_silent_and_install_param_dll_loading.yml b/detections/endpoint/regsvr32_silent_and_install_param_dll_loading.yml index 7be7483dda..9694429dc7 100644 --- a/detections/endpoint/regsvr32_silent_and_install_param_dll_loading.yml +++ b/detections/endpoint/regsvr32_silent_and_install_param_dll_loading.yml @@ -1,16 +1,17 @@ name: Regsvr32 Silent and Install Param Dll Loading id: f421c250-24e7-11ec-bc43-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a loading of dll using regsvr32 application - with silent parameter and dllinstall execution. This technique was seen in several - RAT malware similar to remcos, njrat and adversaries to load their malicious DLL - on the compromised machine. This TTP may executed by normal 3rd party application - so it is better to pivot by the parent process, parent command-line and command-line - of the file that execute this regsvr32. +description: The following analytic detects the loading of a DLL using the regsvr32 + application with the silent parameter and DLLInstall execution. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process command-line + arguments and parent process details. This activity is significant as it is commonly + used by RAT malware like Remcos and njRAT to load malicious DLLs on compromised + machines. If confirmed malicious, this technique could allow attackers to execute + arbitrary code, maintain persistence, and further compromise the system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -89,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/regsvr32_with_known_silent_switch_cmdline.yml b/detections/endpoint/regsvr32_with_known_silent_switch_cmdline.yml index 934fd284b6..fca732291a 100644 --- a/detections/endpoint/regsvr32_with_known_silent_switch_cmdline.yml +++ b/detections/endpoint/regsvr32_with_known_silent_switch_cmdline.yml @@ -1,18 +1,18 @@ name: Regsvr32 with Known Silent Switch Cmdline id: c9ef7dc4-eeaf-11eb-b2b6-acde48001122 -version: 2 -date: '2021-07-27' +version: 3 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies Regsvr32.exe utilizing the silent switch - to load DLLs. This technique has most recently been seen in IcedID campaigns to - load its initial dll that will download the 2nd stage loader that will download - and decrypt the config payload. The switch type may be either a hyphen `-` or forward - slash `/`. This behavior is typically found with `-s`, and it is possible there - are more switch types that may be used. \ During triage, review parallel processes - and capture any artifacts that may have landed on disk. Isolate and contain the - endpoint as necessary. +description: The following analytic detects the execution of Regsvr32.exe with the + silent switch to load DLLs. This behavior is identified using Endpoint Detection + and Response (EDR) telemetry, focusing on command-line executions containing the + `-s` or `/s` switches. This activity is significant as it is commonly used in malware + campaigns, such as IcedID, to stealthily load malicious DLLs. If confirmed malicious, + this could allow an attacker to execute arbitrary code, download additional payloads, + and potentially compromise the system further. Immediate investigation and endpoint + isolation are recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -90,6 +90,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remcos_client_registry_install_entry.yml b/detections/endpoint/remcos_client_registry_install_entry.yml index c43cf69ef2..a85fb22e64 100644 --- a/detections/endpoint/remcos_client_registry_install_entry.yml +++ b/detections/endpoint/remcos_client_registry_install_entry.yml @@ -1,12 +1,12 @@ name: Remcos client registry install entry id: f2a1615a-1d63-11ec-97d2-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-28' author: Steven Dick, Bhavin Patel, Rod Soto, Teoderick Contreras, Splunk status: production type: TTP description: |- - The following analytic detects the presence of a registry key related to the Remcos RAT agent on a host. This detection is made by a Splunk query to search for instances where the registry key "license" is found in the "Software\Remcos" path. This analytic combines information from two data models: Endpoint.Processes and Endpoint.Registry and retrieves process information such as user, process ID, process name, process path, destination, parent process name, parent process, and process GUID. This analytic also retrieves registry information such as registry path, registry key name, registry value name, registry value data, and process GUID. By joining the process GUID from the Endpoint.Processes data model with the process GUID from the Endpoint.Registry data model, the analytic identifies instances where the "license" registry key is found in the "Software\Remcos" path. This detection is important because it suggests that the host has been compromised by the Remcos RAT agent. Remcos is a well-known remote access Trojan that can be used by attackers to gain unauthorized access to systems and exfiltrate sensitive data. Identifying this behavior allows the SOC to take immediate action to remove the RAT agent and prevent further compromise. The impact of this attack can be severe, as the attacker can gain unauthorized access to the system, steal sensitive information, or use the compromised system as a launching point for further attacks. Next steps include using this analytic in conjunction with other security measures and threat intelligence to ensure accurate detection and response. + The following analytic detects the presence of a registry key associated with the Remcos RAT agent on a host. It leverages data from the Endpoint.Processes and Endpoint.Registry data models in Splunk, focusing on instances where the "license" key is found in the "Software\Remcos" path. This behavior is significant as it indicates potential compromise by the Remcos RAT, a remote access Trojan used for unauthorized access and data exfiltration. If confirmed malicious, the attacker could gain control over the system, steal sensitive information, or use the compromised host for further attacks. Immediate investigation and remediation are required. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -76,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remcos_rat_file_creation_in_remcos_folder.yml b/detections/endpoint/remcos_rat_file_creation_in_remcos_folder.yml index 14046accd6..ad7ea90bde 100644 --- a/detections/endpoint/remcos_rat_file_creation_in_remcos_folder.yml +++ b/detections/endpoint/remcos_rat_file_creation_in_remcos_folder.yml @@ -1,14 +1,17 @@ name: Remcos RAT File Creation in Remcos Folder id: 25ae862a-1ac3-11ec-94a1-acde48001122 -version: 2 -date: '2021-09-21' +version: 3 +date: '2024-05-24' author: Teoderick Contreras, Splunk, Sanjay Govind status: production type: TTP -description: This search is to detect file creation in remcos folder in appdata which - is the keylog and clipboard logs that will be send to its c2 server. This is really - a good TTP indicator that there is a remcos rat in the system that do keylogging, - clipboard grabbing and audio recording. +description: The following analytic detects the creation of files in the Remcos folder + within the AppData directory, specifically targeting keylog and clipboard log files. + It leverages the Endpoint.Filesystem data model to identify .dat files created in + paths containing "remcos." This activity is significant as it indicates the presence + of the Remcos RAT, which performs keylogging, clipboard capturing, and audio recording. + If confirmed malicious, this could lead to unauthorized data exfiltration and extensive + surveillance capabilities for the attacker. data_source: - Sysmon EventID 11 search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -53,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_desktop_process_running_on_system.yml b/detections/endpoint/remote_desktop_process_running_on_system.yml index 413ce0d513..b5a0af8292 100644 --- a/detections/endpoint/remote_desktop_process_running_on_system.yml +++ b/detections/endpoint/remote_desktop_process_running_on_system.yml @@ -1,21 +1,25 @@ name: Remote Desktop Process Running On System id: f5939373-8054-40ad-8c64-cec478a22a4a -version: 5 -date: '2020-07-21' +version: 6 +date: '2024-05-24' author: David Dorsey, Splunk status: experimental type: Hunting -description: This search looks for the remote desktop process mstsc.exe running on - systems upon which it doesn't typically run. This is accomplished by filtering out - all systems that are noted in the `common_rdp_source category` in the Assets and - Identity framework. +description: The following analytic detects the execution of the remote desktop process + (mstsc.exe) on systems where it is not typically run. This detection leverages data + from Endpoint Detection and Response (EDR) agents, filtering out systems categorized + as common RDP sources. This activity is significant because unauthorized use of + mstsc.exe can indicate lateral movement or unauthorized remote access attempts. + If confirmed malicious, this could allow an attacker to gain remote control of a + system, potentially leading to data exfiltration, privilege escalation, or further + network compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process=*mstsc.exe AND Processes.dest_category!=common_rdp_source by Processes.dest Processes.user Processes.process | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `drop_dm_object_name(Processes)` | `remote_desktop_process_running_on_system_filter` ' + | `drop_dm_object_name(Processes)` | `remote_desktop_process_running_on_system_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell.yml b/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell.yml index 3c5cb34a1b..6f3ea167d8 100644 --- a/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell.yml +++ b/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell.yml @@ -1,15 +1,19 @@ name: Remote Process Instantiation via DCOM and PowerShell id: d4f42098-4680-11ec-ad07-3e22fbd008af -version: 1 -date: '2021-11-15' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with arguments - utilized to start a process on a remote endpoint by abusing the DCOM protocol. Specifically, - this search looks for the abuse of ShellExecute and ExecuteShellCommand. Red Teams - and adversaries alike may abuse DCOM and `powershell.exe` for lateral movement and - remote code execution. +description: The following analytic detects the execution of `powershell.exe` with + arguments used to start a process on a remote endpoint by abusing the DCOM protocol, + specifically targeting ShellExecute and ExecuteShellCommand. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process names, parent + processes, and command-line executions. This activity is significant as it indicates + potential lateral movement and remote code execution attempts by adversaries. If + confirmed malicious, this could allow attackers to execute arbitrary code remotely, + escalate privileges, and move laterally within the network, posing a severe security + risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.003/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell_script_block.yml b/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell_script_block.yml index 6932626dc4..555aea074b 100644 --- a/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell_script_block.yml +++ b/detections/endpoint/remote_process_instantiation_via_dcom_and_powershell_script_block.yml @@ -1,15 +1,17 @@ name: Remote Process Instantiation via DCOM and PowerShell Script Block id: fa1c3040-4680-11ec-a618-3e22fbd008af -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of PowerShell with arguments utilized to start a process - on a remote endpoint by abusing the DCOM protocol. Specifically, this search looks - for the abuse of ShellExecute and ExecuteShellCommand. Red Teams and adversaries - alike may abuse DCOM for lateral movement and remote code execution. +description: The following analytic detects the execution of PowerShell commands that + initiate a process on a remote endpoint via the DCOM protocol. It leverages PowerShell + Script Block Logging (EventCode=4104) to identify the use of ShellExecute and ExecuteShellCommand. + This activity is significant as it may indicate lateral movement or remote code + execution attempts by adversaries. If confirmed malicious, this behavior could allow + attackers to execute arbitrary code on remote systems, potentially leading to further + compromise and persistence within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText="*Document.Application.ShellExecute*" @@ -18,7 +20,8 @@ search: '`powershell` EventCode=4104 (ScriptBlockText="*Document.Application.She | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `remote_process_instantiation_via_dcom_and_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions - can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + can be found + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: Administrators may leverage DCOM to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. references: @@ -30,8 +33,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 90 - message: A process was started on a remote endpoint from $Computer$ by abusing - WMI using PowerShell.exe + message: A process was started on a remote endpoint from $Computer$ by abusing WMI + using PowerShell.exe mitre_attack_id: - T1021 - T1021.003 @@ -55,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell.yml b/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell.yml index 454db8a909..9e728ff016 100644 --- a/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell.yml +++ b/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell.yml @@ -1,15 +1,18 @@ name: Remote Process Instantiation via WinRM and PowerShell id: ba24cda8-4716-11ec-8009-3e22fbd008af -version: 1 -date: '2021-11-16' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` with arguments - utilized to start a process on a remote endpoint by abusing the WinRM protocol. - Specifically, this search looks for the abuse of the `Invoke-Command` commandlet. - Red Teams and adversaries alike may abuse WinRM and `powershell.exe` for lateral - movement and remote code execution. +description: The following analytic detects the execution of `powershell.exe` with + arguments used to start a process on a remote endpoint via the WinRM protocol, specifically + targeting the `Invoke-Command` cmdlet. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions and process telemetry. + This activity is significant as it may indicate lateral movement or remote code + execution attempts by adversaries. If confirmed malicious, this could allow attackers + to execute arbitrary code on remote systems, potentially leading to further compromise + and lateral spread within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell_script_block.yml b/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell_script_block.yml index 052592536f..1feea35a2e 100644 --- a/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell_script_block.yml +++ b/detections/endpoint/remote_process_instantiation_via_winrm_and_powershell_script_block.yml @@ -1,15 +1,17 @@ name: Remote Process Instantiation via WinRM and PowerShell Script Block id: 7d4c618e-4716-11ec-951c-3e22fbd008af -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of PowerShell with arguments utilized to start a process - on a remote endpoint by abusing the WinRM protocol. Specifically, this search looks - for the abuse of the `Invoke-Command` commandlet. Red Teams and adversaries alike - may abuse WinRM for lateral movement and remote code execution. +description: The following analytic detects the execution of PowerShell commands that + use the `Invoke-Command` cmdlet to start a process on a remote endpoint via the + WinRM protocol. It leverages PowerShell Script Block Logging (EventCode=4104) to + identify such activities. This behavior is significant as it may indicate lateral + movement or remote code execution attempts by adversaries. If confirmed malicious, + this activity could allow attackers to execute arbitrary code on remote systems, + potentially leading to further compromise and persistence within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText="*Invoke-Command*" AND ScriptBlockText="*-ComputerName*") @@ -18,7 +20,8 @@ search: '`powershell` EventCode=4104 (ScriptBlockText="*Invoke-Command*" AND Scr | `remote_process_instantiation_via_winrm_and_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions - can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + can be found + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: Administrators may leverage WinRM and `Invoke-Command` to start a process on remote systems for system administration or automation use cases. This activity is usually limited to a small set of hosts or users. In certain environments, @@ -58,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_psh/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_winrm_and_winrs.yml b/detections/endpoint/remote_process_instantiation_via_winrm_and_winrs.yml index 6046cee8c8..0e1089703d 100644 --- a/detections/endpoint/remote_process_instantiation_via_winrm_and_winrs.yml +++ b/detections/endpoint/remote_process_instantiation_via_winrm_and_winrs.yml @@ -1,14 +1,18 @@ name: Remote Process Instantiation via WinRM and Winrs id: 0dd296a2-4338-11ec-ba02-3e22fbd008af -version: 1 -date: '2021-11-11' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `winrs.exe` with command-line - arguments utilized to start a process on a remote endpoint. Red Teams and adversaries - alike may abuse the WinRM protocol and this binary for lateral movement and remote - code execution. +description: The following analytic detects the execution of `winrs.exe` with command-line + arguments used to start a process on a remote endpoint. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions mapped to the `Processes` node of the `Endpoint` data model. This activity + is significant as it may indicate lateral movement or remote code execution attempts + by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary + code on remote systems, potentially leading to further compromise and lateral spread + within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell.yml b/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell.yml index 1813496fa8..66811ce7f8 100644 --- a/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell.yml +++ b/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell.yml @@ -1,14 +1,17 @@ name: Remote Process Instantiation via WMI and PowerShell id: 112638b4-4634-11ec-b9ab-3e22fbd008af -version: 1 -date: '2021-11-15' +version: 2 +date: '2024-05-17' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `powershell.exe` leveraging - the `Invoke-WmiMethod` commandlet complemented with arguments utilized to start - a process on a remote endpoint by abusing WMI. Red Teams and adversaries alike may - abuse WMI and `powershell.exe` for lateral movement and remote code execution. +description: The following analytic detects the execution of `powershell.exe` using + the `Invoke-WmiMethod` cmdlet to start a process on a remote endpoint via WMI. It + leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and process telemetry. This activity is significant as it indicates potential + lateral movement or remote code execution attempts by adversaries. If confirmed + malicious, this could allow attackers to execute arbitrary code on remote systems, + leading to further compromise and persistence within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell_script_block.yml b/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell_script_block.yml index 8d36d3b172..110e6db09a 100644 --- a/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell_script_block.yml +++ b/detections/endpoint/remote_process_instantiation_via_wmi_and_powershell_script_block.yml @@ -1,14 +1,18 @@ name: Remote Process Instantiation via WMI and PowerShell Script Block id: 2a048c14-4634-11ec-a618-3e22fbd008af -version: 2 -date: '2022-11-15' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Invoke-WmiMethod` commandlet with arguments utilized - to start a process on a remote endpoint by abusing WMI. Red Teams and adversaries - alike may abuse WMI and this commandlet for lateral movement and remote code execution. +description: The following analytic detects the execution of the `Invoke-WmiMethod` + commandlet with parameters used to start a process on a remote endpoint via WMI, + leveraging PowerShell Script Block Logging (EventCode=4104). This method identifies + specific script block text patterns associated with remote process instantiation. + This activity is significant as it may indicate lateral movement or remote code + execution attempts by adversaries. If confirmed malicious, this could allow attackers + to execute arbitrary code on remote systems, potentially leading to further compromise + and persistence within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText="*Invoke-WmiMethod*" AND (ScriptBlockText="*-CN*" @@ -18,7 +22,8 @@ search: '`powershell` EventCode=4104 ScriptBlockText="*Invoke-WmiMethod*" AND (S | `security_content_ctime(lastTime)` | `remote_process_instantiation_via_wmi_and_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions - can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + can be found + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: Administrators may leverage WWMI and powershell.exe to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -31,8 +36,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 90 - message: A process was started on a remote endpoint from $Computer$ by abusing - WMI using PowerShell.exe + message: A process was started on a remote endpoint from $Computer$ by abusing WMI + using PowerShell.exe mitre_attack_id: - T1047 observable: @@ -55,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement/wmi_remote_process_powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement/wmi_remote_process_powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/remote_system_discovery_with_adsisearcher.yml b/detections/endpoint/remote_system_discovery_with_adsisearcher.yml index 9562bb28e7..5887b1fb3b 100644 --- a/detections/endpoint/remote_system_discovery_with_adsisearcher.yml +++ b/detections/endpoint/remote_system_discovery_with_adsisearcher.yml @@ -1,20 +1,25 @@ name: Remote System Discovery with Adsisearcher id: 70803451-0047-4e12-9d63-77fa7eb8649c -version: 2 -date: '2022-06-29' +version: 3 +date: '2024-05-09' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the `[Adsisearcher]` type accelerator being used to query Active Directory - for domain computers. Red Teams and adversaries may leverage `[Adsisearcher]` to - enumerate domain computers for situational awareness and Active Directory Discovery. +description: The following analytic detects the use of the `[Adsisearcher]` type accelerator + in PowerShell scripts to query Active Directory for domain computers. It leverages + PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks + containing `adsisearcher` and `objectcategory=computer` with methods like `findAll()` + or `findOne()`. This activity is significant as it may indicate an attempt by adversaries + or Red Teams to perform Active Directory discovery and gain situational awareness. + If confirmed malicious, this could lead to further reconnaissance and potential + lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*adsisearcher*" AND ScriptBlockText = "*objectcategory=computer*" AND ScriptBlockText IN ("*findAll()*","*findOne()*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` | `remote_system_discovery_with_adsisearcher_filter`' + Computer UserID | rename Computer as dest |rename UserID as user | `security_content_ctime(firstTime)` + | `remote_system_discovery_with_adsisearcher_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -51,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/adsisearcher-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/adsisearcher-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_system_discovery_with_dsquery.yml b/detections/endpoint/remote_system_discovery_with_dsquery.yml index 1ba2b5cdf5..bf994244b3 100644 --- a/detections/endpoint/remote_system_discovery_with_dsquery.yml +++ b/detections/endpoint/remote_system_discovery_with_dsquery.yml @@ -1,15 +1,18 @@ name: Remote System Discovery with Dsquery id: 9fb562f4-42f8-4139-8e11-a82edf7ed718 -version: 1 -date: '2021-08-31' +version: 2 +date: '2024-05-13' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `dsquery.exe` with command-line - arguments utilized to discover remote systems. The `computer` argument returns a - list of all computers registered in the domain. Red Teams and adversaries alike - engage in remote system discovery for situational awareness and Active Directory - Discovery. +description: The following analytic detects the execution of `dsquery.exe` with the + `computer` argument, which is used to discover remote systems within a domain. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments. Remote system discovery is significant + as it indicates potential reconnaissance activities by adversaries or Red Teams + to map out network resources and Active Directory structures. If confirmed malicious, + this activity could lead to further exploitation, lateral movement, and unauthorized + access to critical systems within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_system_discovery_with_net.yml b/detections/endpoint/remote_system_discovery_with_net.yml index 1cb7a63c7d..d77e2c716b 100644 --- a/detections/endpoint/remote_system_discovery_with_net.yml +++ b/detections/endpoint/remote_system_discovery_with_net.yml @@ -1,15 +1,18 @@ name: Remote System Discovery with Net id: 9df16706-04a2-41e2-bbfe-9b38b34409d3 -version: 1 -date: '2021-08-30' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `net.exe` or `net1.exe` with - command-line arguments utilized to discover remote systems. The argument `domain - computers /domain` returns a list of all domain computers. Red Teams and adversaries - alike use net.exe to identify remote systems for situational awareness and Active - Directory Discovery. +description: The following analytic identifies the execution of `net.exe` or `net1.exe` + with command-line arguments used to discover remote systems, such as `domain computers + /domain`. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line arguments. This activity is significant + as it indicates potential reconnaissance efforts by adversaries or Red Teams to + map out networked systems and Active Directory structures. If confirmed malicious, + this behavior could lead to further network exploitation, privilege escalation, + or lateral movement within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_system_discovery_with_wmic.yml b/detections/endpoint/remote_system_discovery_with_wmic.yml index 30d203e423..5615606282 100644 --- a/detections/endpoint/remote_system_discovery_with_wmic.yml +++ b/detections/endpoint/remote_system_discovery_with_wmic.yml @@ -1,15 +1,18 @@ name: Remote System Discovery with Wmic id: d82eced3-b1dc-42ab-859e-a2fc98827359 -version: 1 -date: '2021-09-01' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `wmic.exe` with command-line - arguments utilized to discover remote systems. The arguments utilized in this command - return a list of all the systems registered in the domain. Red Teams and adversaries - alike may leverage WMI and wmic.exe to identify remote systems for situational awareness - and Active Directory Discovery. +description: The following analytic detects the execution of `wmic.exe` with specific + command-line arguments used to discover remote systems within a domain. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant as it indicates potential + reconnaissance efforts by adversaries to map out network resources and Active Directory + structures. If confirmed malicious, this behavior could allow attackers to gain + situational awareness, identify critical systems, and plan further attacks, potentially + leading to unauthorized access and data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/remote_wmi_command_attempt.yml b/detections/endpoint/remote_wmi_command_attempt.yml index b8b2f9308f..ce1fd3e8a3 100644 --- a/detections/endpoint/remote_wmi_command_attempt.yml +++ b/detections/endpoint/remote_wmi_command_attempt.yml @@ -1,15 +1,17 @@ name: Remote WMI Command Attempt id: 272df6de-61f1-4784-877c-1fbc3e2d0838 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-17' author: Rico Valdez, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies usage of `wmic.exe` spawning a local - or remote process, identified by the `node` switch. During triage, review parallel - processes for additional commands executed. Look for any file modifications before - and after `wmic.exe` execution. In addition, identify the remote endpoint and confirm - execution or file modifications. Contain and isolate the endpoint as needed. +description: The following analytic detects the execution of `wmic.exe` with the `node` + switch, indicating an attempt to spawn a local or remote process. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + creation events and command-line arguments. This activity is significant as it may + indicate lateral movement or remote code execution attempts by an attacker. If confirmed + malicious, the attacker could gain remote control over the targeted system, execute + arbitrary commands, and potentially escalate privileges or persist within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/resize_shadowstorage_volume.yml b/detections/endpoint/resize_shadowstorage_volume.yml index 6af005c6b2..1ac224b41a 100644 --- a/detections/endpoint/resize_shadowstorage_volume.yml +++ b/detections/endpoint/resize_shadowstorage_volume.yml @@ -1,16 +1,18 @@ name: Resize ShadowStorage volume id: bc760ca6-8336-11eb-bcbb-acde48001122 -version: 1 -date: '2021-03-12' +version: 2 +date: '2024-05-13' author: Teoderick Contreras status: production type: TTP -description: The following analytics identifies the resizing of shadowstorage by ransomware - malware to avoid the shadow volumes being made again. this technique is an alternative - by ransomware attacker than deleting the shadowstorage which is known alert in defensive - team. one example of ransomware that use this technique is CLOP ransomware where - it drops a .bat file that will resize the shadowstorage to minimum size as much - as possible +description: The following analytic identifies the resizing of shadow storage volumes, + a technique used by ransomware like CLOP to prevent the recreation of shadow volumes. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on command-line executions involving "vssadmin.exe" with parameters related + to resizing shadow storage. This activity is significant as it indicates an attempt + to hinder recovery efforts by manipulating shadow copies. If confirmed malicious, + this could lead to successful ransomware deployment, making data recovery difficult + and increasing the potential for data loss. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as cmdline @@ -76,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/revil_registry_entry.yml b/detections/endpoint/revil_registry_entry.yml index 95a4bd5255..82977a8971 100644 --- a/detections/endpoint/revil_registry_entry.yml +++ b/detections/endpoint/revil_registry_entry.yml @@ -1,15 +1,19 @@ name: Revil Registry Entry id: e3d3f57a-c381-11eb-9e35-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-24' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies suspicious modification in registry entry to - keep some malware data during its infection. This technique seen in several apt - implant, malware and ransomware like REVIL where it keep some information like the - random generated file extension it uses for all the encrypted files and ransomware - notes file name in the compromised host. +description: The following analytic identifies suspicious modifications in the registry + entry, specifically targeting paths used by malware like REVIL. It detects changes + in registry paths such as `SOFTWARE\\WOW6432Node\\Facebook_Assistant` and `SOFTWARE\\WOW6432Node\\BlackLivesMatter`. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on registry modifications linked to process GUIDs. This activity is significant + as it indicates potential malware persistence mechanisms, often used by advanced + persistent threats (APTs) and ransomware. If confirmed malicious, this could allow + attackers to maintain persistence, encrypt files, and store critical ransomware-related + information on compromised hosts. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -87,6 +91,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rubeus_command_line_parameters.yml b/detections/endpoint/rubeus_command_line_parameters.yml index 429a72145a..b091b3a554 100644 --- a/detections/endpoint/rubeus_command_line_parameters.yml +++ b/detections/endpoint/rubeus_command_line_parameters.yml @@ -1,19 +1,18 @@ name: Rubeus Command Line Parameters id: cca37478-8377-11ec-b59a-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -description: Rubeus is a C# toolset for raw Kerberos interaction and abuses. It is - heavily adapted from Benjamin Delpys Kekeo project and Vincent LE TOUXs MakeMeEnterpriseAdmin - project. This analytic looks for the use of Rubeus command line arguments utilized - in common Kerberos attacks like exporting and importing tickets, forging silver - and golden tickets, requesting a TGT or TGS, kerberoasting, password spraying, etc. - Red teams and adversaries alike use Rubeus for Kerberos attacks within Active Directory - networks. Defenders should be aware that adversaries may customize the source code - of Rubeus and modify the command line parameters. This would effectively bypass - this analytic. +description: The following analytic detects the use of Rubeus command line parameters, + a toolset for Kerberos attacks within Active Directory environments. It leverages + Endpoint Detection and Response (EDR) data to identify specific command-line arguments + associated with actions like ticket manipulation, kerberoasting, and password spraying. + This activity is significant as Rubeus is commonly used by adversaries to exploit + Kerberos for privilege escalation and lateral movement. If confirmed malicious, + this could lead to unauthorized access, persistence, and potential compromise of + sensitive information within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -90,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/rubeus/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/rubeus/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml b/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml index 4c93aff19c..4b8c89fca1 100644 --- a/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml +++ b/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml @@ -1,20 +1,18 @@ name: Rubeus Kerberos Ticket Exports Through Winlogon Access id: 5ed8c50a-8869-11ec-876f-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-27' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic looks for a process accessing the winlogon.exe - system process. The Splunk Threat Research team identified this behavior when using - the Rubeus tool to monitor for and export kerberos tickets from memory. Before being - able to export tickets. Rubeus will try to escalate privileges to SYSTEM by obtaining - a handle to winlogon.exe before trying to monitor for kerberos tickets. Exporting - tickets from memory is typically the first step for pass the ticket attacks. Red - teams and adversaries alike may use the pass the ticket technique using stolen Kerberos - tickets to move laterally within an environment, bypassing normal system access - controls. Defenders should be aware that adversaries may customize the source code - of Rubeus to potentially bypass this analytic. +description: The following analytic detects a process accessing the winlogon.exe system + process, indicative of the Rubeus tool attempting to export Kerberos tickets from + memory. This detection leverages Sysmon EventCode 10 logs, focusing on processes + obtaining a handle to winlogon.exe with specific access rights. This activity is + significant as it often precedes pass-the-ticket attacks, where adversaries use + stolen Kerberos tickets to move laterally within an environment. If confirmed malicious, + this could allow attackers to bypass normal access controls, escalate privileges, + and persist within the network, posing a severe security risk. data_source: - Sysmon EventID 10 search: ' `sysmon` EventCode=10 TargetImage=C:\\Windows\\system32\\winlogon.exe (GrantedAccess=0x1f3fff) @@ -73,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/rubeus/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550.003/rubeus/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/runas_execution_in_commandline.yml b/detections/endpoint/runas_execution_in_commandline.yml index 1c97c663ba..5325220d71 100644 --- a/detections/endpoint/runas_execution_in_commandline.yml +++ b/detections/endpoint/runas_execution_in_commandline.yml @@ -1,16 +1,18 @@ name: Runas Execution in CommandLine id: 4807e716-43a4-11ec-a0e7-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic look for a spawned runas.exe process with a administrator - user option parameter. This parameter was abused by adversaries, malware author - or even red teams to gain elevated privileges in target host. This is a good hunting - query to figure out privilege escalation tactics that may used for different stages - like lateral movement but take note that administrator may use this command in purpose - so its better to see other event context before and after this analytic. +description: The following analytic detects the execution of the runas.exe process + with administrator user options. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on command-line executions and process details. This activity + is significant as it may indicate an attempt to gain elevated privileges, a common + tactic in privilege escalation and lateral movement. If confirmed malicious, this + could allow an attacker to execute commands with higher privileges, potentially + leading to unauthorized access, data exfiltration, or further compromise of the + target host. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/vilsel/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_control_rundll_hunt.yml b/detections/endpoint/rundll32_control_rundll_hunt.yml index 9384003e18..48b89e8052 100644 --- a/detections/endpoint/rundll32_control_rundll_hunt.yml +++ b/detections/endpoint/rundll32_control_rundll_hunt.yml @@ -1,17 +1,18 @@ name: Rundll32 Control RunDLL Hunt id: c8e7ced0-10c5-11ec-8b03-acde48001122 -version: 1 -date: '2021-09-08' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting detection identifies rundll32.exe with `control_rundll` - within the command-line, loading a .cpl or another file type. Developed in relation - to CVE-2021-40444. Rundll32.exe can also be used to execute Control Panel Item files - (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. - Double-clicking a .cpl file also causes rundll32.exe to execute. \ This is written - to be a bit more broad by not including .cpl. \ During triage, review parallel processes - to identify any further suspicious behavior. +description: The following analytic identifies instances of rundll32.exe executing + with `Control_RunDLL` in the command line, which is indicative of loading a .cpl + or other file types. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs and command-line arguments. This + activity is significant as rundll32.exe can be exploited to execute malicious Control + Panel Item files, potentially linked to CVE-2021-40444. If confirmed malicious, + this could allow attackers to execute arbitrary code, escalate privileges, or maintain + persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -91,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_control_rundll_world_writable_directory.yml b/detections/endpoint/rundll32_control_rundll_world_writable_directory.yml index 51cfaa13f4..553eb513a4 100644 --- a/detections/endpoint/rundll32_control_rundll_world_writable_directory.yml +++ b/detections/endpoint/rundll32_control_rundll_world_writable_directory.yml @@ -1,18 +1,18 @@ name: Rundll32 Control RunDLL World Writable Directory id: 1adffe86-10c3-11ec-8ce6-acde48001122 -version: 1 -date: '2021-09-08' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies rundll32.exe with `control_rundll` - within the command-line, loading a .cpl or another file type from windows\temp, - programdata, or appdata. Developed in relation to CVE-2021-40444. Rundll32.exe can - also be used to execute Control Panel Item files (.cpl) through the undocumented - shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a - .cpl file also causes rundll32.exe to execute. This is written to be a bit more - broad by not including .cpl. The paths are specified, add more as needed. During - triage, review parallel processes to identify any further suspicious behavior. +description: The following analytic detects the execution of rundll32.exe with the + `Control_RunDLL` command, loading files from world-writable directories such as + windows\temp, programdata, or appdata. This detection leverages Endpoint Detection + and Response (EDR) telemetry, focusing on process command-line data and specific + directory paths. This activity is significant as it may indicate an attempt to exploit + CVE-2021-40444 or similar vulnerabilities, allowing attackers to execute arbitrary + code. If confirmed malicious, this could lead to unauthorized code execution, privilege + escalation, or persistent access within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -93,6 +93,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_create_remote_thread_to_a_process.yml b/detections/endpoint/rundll32_create_remote_thread_to_a_process.yml index ff39487b58..cfc70b8712 100644 --- a/detections/endpoint/rundll32_create_remote_thread_to_a_process.yml +++ b/detections/endpoint/rundll32_create_remote_thread_to_a_process.yml @@ -1,14 +1,17 @@ name: Rundll32 Create Remote Thread To A Process id: 2dbeee3a-f067-11eb-96c0-acde48001122 -version: 1 -date: '2021-07-29' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies the suspicious Remote Thread execution of rundll32.exe - to any process. This technique was seen in IcedID malware to execute its malicious - code in normal process for defense evasion and to steal sensitive information in - the compromised host. +description: The following analytic detects the creation of a remote thread by rundll32.exe + into another process. It leverages Sysmon EventCode 8 logs, specifically monitoring + SourceImage and TargetImage fields. This activity is significant as it is a common + technique used by malware, such as IcedID, to execute malicious code within legitimate + processes, aiding in defense evasion and data theft. If confirmed malicious, this + behavior could allow an attacker to execute arbitrary code, escalate privileges, + and exfiltrate sensitive information from the compromised host. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 SourceImage = "*\\rundll32.exe" TargetImage = "*.exe" @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_createremotethread_in_browser.yml b/detections/endpoint/rundll32_createremotethread_in_browser.yml index b8125e6c4a..dd4d0665e3 100644 --- a/detections/endpoint/rundll32_createremotethread_in_browser.yml +++ b/detections/endpoint/rundll32_createremotethread_in_browser.yml @@ -1,14 +1,18 @@ name: Rundll32 CreateRemoteThread In Browser id: f8a22586-ee2d-11eb-a193-acde48001122 -version: 1 -date: '2021-07-26' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies the suspicious Remote Thread execution of rundll32.exe - process to "firefox.exe" and "chrome.exe" browser. This technique was seen in IcedID - malware where it hooks the browser to parse banking information as user used the - targetted browser process. +description: The following analytic detects the suspicious creation of a remote thread + by rundll32.exe targeting browser processes such as firefox.exe, chrome.exe, iexplore.exe, + and microsoftedgecp.exe. This detection leverages Sysmon EventCode 8, focusing on + SourceImage and TargetImage fields to identify the behavior. This activity is significant + as it is commonly associated with malware like IcedID, which hooks browsers to steal + sensitive information such as banking details. If confirmed malicious, this could + allow attackers to intercept and exfiltrate sensitive user data, leading to potential + financial loss and privacy breaches. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 SourceImage = "*\\rundll32.exe" TargetImage IN ("*\\firefox.exe", @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_dnsquery.yml b/detections/endpoint/rundll32_dnsquery.yml index 0f5f1f30be..e0b2bb34a2 100644 --- a/detections/endpoint/rundll32_dnsquery.yml +++ b/detections/endpoint/rundll32_dnsquery.yml @@ -1,20 +1,25 @@ name: Rundll32 DNSQuery id: f1483f5e-ee29-11eb-9d23-acde48001122 -version: 2 -date: '2022-02-18' +version: 3 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious rundll32.exe process having a http - connection and do a dns query in some web domain. This technique was seen in IcedID - malware where the rundll32 that execute its payload will contact amazon.com to check - internet connect and to communicate to its C&C server to download config and other - file component. +description: The following analytic detects a suspicious `rundll32.exe` process making + HTTP connections and performing DNS queries to web domains. It leverages Sysmon + EventCode 22 logs to identify these activities. This behavior is significant as + it is commonly associated with IcedID malware, where `rundll32.exe` checks internet + connectivity and communicates with C&C servers to download configurations and other + components. If confirmed malicious, this activity could allow attackers to establish + persistence, download additional payloads, and exfiltrate sensitive data, posing + a severe threat to the network. data_source: - Sysmon EventID 22 search: '`sysmon` EventCode=22 process_name="rundll32.exe" | stats count min(_time) - as firstTime max(_time) as lastTime values(query) as query values(answer) as answer values(QueryResults) as query_results values(QueryStatus) as query_status by process_name process_guid Computer | rename Computer as dest - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `rundll32_dnsquery_filter`' + as firstTime max(_time) as lastTime values(query) as query values(answer) as answer + values(QueryResults) as query_results values(QueryStatus) as query_status by process_name + process_guid Computer | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `rundll32_dnsquery_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and eventcode = 22 dnsquery executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. @@ -29,7 +34,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 70 - message: rundll32 process $process_name$ made a DNS query for $query$ from host $dest$ + message: rundll32 process $process_name$ made a DNS query for $query$ from host + $dest$ mitre_attack_id: - T1218 - T1218.011 @@ -58,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_lockworkstation.yml b/detections/endpoint/rundll32_lockworkstation.yml index 625ed9df2b..72b774ccfa 100644 --- a/detections/endpoint/rundll32_lockworkstation.yml +++ b/detections/endpoint/rundll32_lockworkstation.yml @@ -1,14 +1,17 @@ name: Rundll32 LockWorkStation id: fa90f372-f91d-11eb-816c-acde48001122 -version: 2 -date: '2021-08-09' +version: 3 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This search is to detect a suspicious rundll32 commandline to lock the - workstation through command line. This technique was seen in CONTI leak tooling - and script as part of its defense evasion. This technique is not a common practice - to lock a screen and maybe a good indicator of compromise. +description: The following analytic detects the execution of the rundll32.exe command + with the user32.dll,LockWorkStation parameter, which is used to lock the workstation + via command line. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant as it is an uncommon method to lock a screen and has been observed + in CONTI ransomware tooling for defense evasion. If confirmed malicious, this technique + could indicate an attempt to evade detection and hinder incident response efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_process_creating_exe_dll_files.yml b/detections/endpoint/rundll32_process_creating_exe_dll_files.yml index 66aeabbbb0..57f71e63ee 100644 --- a/detections/endpoint/rundll32_process_creating_exe_dll_files.yml +++ b/detections/endpoint/rundll32_process_creating_exe_dll_files.yml @@ -1,22 +1,23 @@ name: Rundll32 Process Creating Exe Dll Files id: 6338266a-ee2a-11eb-bf68-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious rundll32 process that drops executable - (.exe or .dll) files. This behavior seen in rundll32 process of IcedID that tries - to drop copy of itself in temp folder or download executable drop it either appdata - or programdata as part of its execution. +description: The following analytic detects a rundll32 process creating executable + (.exe) or dynamic link library (.dll) files. It leverages Sysmon EventCode 11 to + identify instances where rundll32.exe generates these file types. This activity + is significant because rundll32 is often exploited by malware, such as IcedID, to + drop malicious payloads in directories like Temp, AppData, or ProgramData. If confirmed + malicious, this behavior could allow an attacker to execute arbitrary code, establish + persistence, or escalate privileges within the environment. data_source: - Sysmon EventID 11 -search: '`sysmon` EventCode=11 Image="*rundll32.exe" TargetFilename IN ("*.exe", "*.dll") - | stats count min(_time) as firstTime max(_time) as lastTime by Image TargetFilename Computer - | rename Computer as dest | rename TargetFilename as file_name - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `rundll32_process_creating_exe_dll_files_filter`' +search: '`sysmon` EventCode=11 Image="*rundll32.exe" TargetFilename IN ("*.exe", "*.dll") + | stats count min(_time) as firstTime max(_time) as lastTime by Image TargetFilename + Computer | rename Computer as dest | rename TargetFilename as file_name | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `rundll32_process_creating_exe_dll_files_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, TargetFilename, and eventcode 11 executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -60,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_shimcache_flush.yml b/detections/endpoint/rundll32_shimcache_flush.yml index 42d2172559..b942853036 100644 --- a/detections/endpoint/rundll32_shimcache_flush.yml +++ b/detections/endpoint/rundll32_shimcache_flush.yml @@ -1,15 +1,17 @@ name: Rundll32 Shimcache Flush id: a913718a-25b6-11ec-96d3-acde48001122 -version: 1 -date: '2021-10-05' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious rundll32 commandline to clear - shim cache. This technique is a anti-forensic technique to clear the cache taht - are one important artifacts in terms of digital forensic during attacks or incident. - This TTP is a good indicator that someone tries to evade some tools and clear foothold - on the machine. +description: The following analytic detects the execution of a suspicious rundll32 + command line used to clear the shim cache. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs and command-line arguments. + This activity is significant because clearing the shim cache is an anti-forensic + technique aimed at evading detection and removing forensic artifacts. If confirmed + malicious, this action could hinder incident response efforts, allowing an attacker + to cover their tracks and maintain persistence on the compromised machine. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/shimcache_flush/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/shimcache_flush/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml b/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml index c742b3a016..45e5287cbb 100644 --- a/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml +++ b/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml @@ -1,17 +1,18 @@ name: Rundll32 with no Command Line Arguments with Network id: 35307032-a12d-11eb-835f-acde48001122 -version: 4 -date: '2023-07-10' +version: 5 +date: '2024-05-21' author: Steven Dick, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe with no command line arguments - and performing a network connection. It is unusual for rundll32.exe to execute with - no command line arguments present. This particular behavior is common with malicious - software, including Cobalt Strike. During investigation, triage any network connections - and parallel processes. Identify any suspicious module loads related to credential - dumping or file writes. Rundll32.exe is natively found in C:\Windows\system32 and - C:\Windows\syswow64. +description: The following analytic detects the execution of rundll32.exe without + command line arguments, followed by a network connection. This behavior is identified + using Endpoint Detection and Response (EDR) telemetry and network traffic data. + It is significant because rundll32.exe typically requires arguments to function, + and its absence is often associated with malicious activity, such as Cobalt Strike. + If confirmed malicious, this activity could indicate an attempt to establish unauthorized + network connections, potentially leading to data exfiltration or further compromise + of the system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/rundll_loading_dll_by_ordinal.yml b/detections/endpoint/rundll_loading_dll_by_ordinal.yml index c67c2be719..0bb925c509 100644 --- a/detections/endpoint/rundll_loading_dll_by_ordinal.yml +++ b/detections/endpoint/rundll_loading_dll_by_ordinal.yml @@ -1,16 +1,17 @@ name: RunDLL Loading DLL By Ordinal id: 6c135f8d-5e60-454e-80b7-c56eed739833 -version: 6 -date: '2022-02-08' +version: 7 +date: '2024-05-20' author: Michael Haag, David Dorsey, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe loading an export function - by ordinal value. Adversaries may abuse rundll32.exe to proxy execution of malicious - code. Using rundll32.exe, vice executing directly, may avoid triggering security - tools that may not monitor execution of the rundll32.exe process because of allowlists - or false positives from normal operations. Utilizing ordinal values makes it a bit - more complicated for analysts to understand the behavior until the DLL is reviewed. +description: The following analytic detects rundll32.exe loading a DLL export function + by ordinal value. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process command-line executions. This behavior is significant because + adversaries may use rundll32.exe to execute malicious code while evading security + tools that do not monitor this process. If confirmed malicious, this activity could + allow attackers to execute arbitrary code, potentially leading to system compromise, + privilege escalation, or persistent access within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -81,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/ordinal_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/ordinal_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/ryuk_wake_on_lan_command.yml b/detections/endpoint/ryuk_wake_on_lan_command.yml index c932d6d394..9128468dea 100644 --- a/detections/endpoint/ryuk_wake_on_lan_command.yml +++ b/detections/endpoint/ryuk_wake_on_lan_command.yml @@ -1,19 +1,18 @@ name: Ryuk Wake on LAN Command id: 538d0152-7aaa-11eb-beaa-acde48001122 -version: 1 -date: '2021-03-01' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: This Splunk query identifies the use of Wake-on-LAN utilized by Ryuk - ransomware. The Ryuk Ransomware uses the Wake-on-Lan feature to turn on powered - off devices on a compromised network to have greater success encrypting them. This - is a high fidelity indicator of Ryuk ransomware executing on an endpoint. Upon triage, - isolate the endpoint. Additional file modification events will be within the users - profile (\appdata\roaming) and in public directories (users\public\). Review all - Scheduled Tasks on the isolated endpoint and across the fleet. Suspicious Scheduled - Tasks will include a path to a unknown binary and those endpoints should be isolated - until triaged. +description: The following analytic detects the use of Wake-on-LAN commands associated + with Ryuk ransomware. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on specific process and command-line activities. This behavior + is significant as Ryuk ransomware uses Wake-on-LAN to power on devices in a compromised + network, increasing its encryption success rate. If confirmed malicious, this activity + could lead to widespread ransomware encryption across multiple endpoints, causing + significant operational disruption and data loss. Immediate isolation and thorough + investigation of the affected endpoints are crucial to mitigate the impact. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.003/ryuk/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.003/ryuk/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/sam_database_file_access_attempt.yml b/detections/endpoint/sam_database_file_access_attempt.yml index 8d79d0659f..5f3e2f16c2 100644 --- a/detections/endpoint/sam_database_file_access_attempt.yml +++ b/detections/endpoint/sam_database_file_access_attempt.yml @@ -1,21 +1,24 @@ name: SAM Database File Access Attempt id: 57551656-ebdb-11eb-afdf-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-22' author: Michael Haag, Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic identifies access to SAM, SYSTEM or SECURITY databases' - within the file path of `windows\system32\config` using Windows Security EventCode - 4663. This particular behavior is related to credential access, an attempt to either - use a Shadow Copy or recent CVE-2021-36934 to access the SAM database. The Security - Account Manager (SAM) is a database file in Windows XP, Windows Vista, Windows 7, - 8.1 and 10 that stores users' passwords. +description: The following analytic detects attempts to access the SAM, SYSTEM, or + SECURITY database files within the `windows\system32\config` directory using Windows + Security EventCode 4663. This detection leverages Windows Security Event logs to + identify unauthorized access attempts. Monitoring this activity is crucial as it + indicates potential credential access attempts, possibly exploiting vulnerabilities + like CVE-2021-36934. If confirmed malicious, an attacker could extract user passwords, + leading to unauthorized access, privilege escalation, and further compromise of + the system. data_source: - Windows Event Log Security 4663 search: '`wineventlog_security` (EventCode=4663) ProcessName!=*\\dllhost.exe ObjectName IN ("*\\Windows\\System32\\config\\SAM*","*\\Windows\\System32\\config\\SYSTEM*","*\\Windows\\System32\\config\\SECURITY*") - | stats values(AccessList) count by ProcessName ObjectName dest src_user | rename ProcessName as process_name | `sam_database_file_access_attempt_filter`' + | stats values(AccessList) count by ProcessName ObjectName dest src_user | rename + ProcessName as process_name | `sam_database_file_access_attempt_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." @@ -39,7 +42,8 @@ tags: cve: - CVE-2021-36934 impact: 80 - message: The following process $process_name$ accessed the object $ObjectName$ attempting to gain access to credentials on $dest$ by user $src_user$. + message: The following process $process_name$ accessed the object $ObjectName$ attempting + to gain access to credentials on $dest$ by user $src_user$. mitre_attack_id: - T1003.002 - T1003 @@ -75,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/serioussam/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.002/serioussam/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/schcache_change_by_app_connect_and_create_adsi_object.yml b/detections/endpoint/schcache_change_by_app_connect_and_create_adsi_object.yml index d9ef5048db..3f1fd31caf 100644 --- a/detections/endpoint/schcache_change_by_app_connect_and_create_adsi_object.yml +++ b/detections/endpoint/schcache_change_by_app_connect_and_create_adsi_object.yml @@ -1,19 +1,18 @@ name: SchCache Change By App Connect And Create ADSI Object id: 991eb510-0fc6-11ec-82d3-acde48001122 -version: 1 -date: '2021-09-07' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect an application try to connect and create ADSI - Object to do LDAP query. Every time an application connects to the directory and - attempts to create an ADSI object, the Active Directory Schema is checked for changes. - If it has changed since the last connection, the schema is downloaded and stored - in a cache on the local computer either in %LOCALAPPDATA%\Microsoft\Windows\SchCache - or %systemroot%\SchCache. We found this a good anomaly use case to detect suspicious - application like blackmatter ransomware that use ADS object api to execute ldap - query. having a good list of ldap or normal AD query tool used within the network - is a good start to reduce the noise. +description: The following analytic detects an application attempting to connect and + create an ADSI object to perform an LDAP query. It leverages Sysmon EventCode 11 + to identify changes in the Active Directory Schema cache files located in %LOCALAPPDATA%\Microsoft\Windows\SchCache + or %systemroot%\SchCache. This activity is significant as it can indicate the presence + of suspicious applications, such as ransomware, using ADSI object APIs for LDAP + queries. If confirmed malicious, this behavior could allow attackers to gather sensitive + directory information, potentially leading to further exploitation or lateral movement + within the network. data_source: - Sysmon EventID 11 search: '`sysmon` EventCode=11 TargetFilename = "*\\Windows\\SchCache\\*" TargetFilename @@ -62,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/blackmatter_schcache/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/blackmatter_schcache/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/schedule_task_with_http_command_arguments.yml b/detections/endpoint/schedule_task_with_http_command_arguments.yml index 2cddac2431..aaded3e025 100644 --- a/detections/endpoint/schedule_task_with_http_command_arguments.yml +++ b/detections/endpoint/schedule_task_with_http_command_arguments.yml @@ -1,17 +1,18 @@ name: Schedule Task with HTTP Command Arguments id: 523c2684-a101-11eb-916b-acde48001122 -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects the registration of suspicious tasks on Windows using the Windows Security EventCode 4698, "A scheduled task was created." It specifically looks for tasks registered through schtasks.exe or TaskService that have command arguments containing the string "HTTP." This behavior is often associated with malware or attacks that utilize Living off the Land binaries (lolbins) to download additional files or payloads to the compromised machine. - - The search returns information about the task, such as the task name, command, author, enabled status, hidden status, and arguments. Upon triage, it is important to identify the source of the scheduled task, whether it was registered through schtasks.exe or TaskService. Review the details of the created task and the command to be executed. Capture relevant artifacts on disk and examine them. Additionally, identify any parallel processes occurring within the same timeframe to determine the source of the attack. - - Implementing this analytic requires ingesting logs with information about task schedules, specifically Windows Security Log EventCode 4698, from your endpoints. It is recommended to tune and filter known instances of task schedules used in your environment to minimize false positives. - - Detecting the registration of suspicious tasks with HTTP command arguments is valuable for a SOC as it indicates potential malicious activity or an attempt to establish persistence on the system. If a true positive is found, further investigation is warranted to analyze the nature and purpose of the scheduled task, identify any downloaded files or payloads, and mitigate the associated risks. The impact of a true positive can vary but may include data exfiltration, malware propagation, or unauthorized access to sensitive information. +description: The following analytic detects the creation of scheduled tasks on Windows + systems that include HTTP command arguments, using Windows Security EventCode 4698. + It identifies tasks registered via schtasks.exe or TaskService with HTTP in their + command arguments. This behavior is significant as it often indicates malware activity + or the use of Living off the Land binaries (lolbins) to download additional payloads. + If confirmed malicious, this activity could lead to data exfiltration, malware propagation, + or unauthorized access to sensitive information, necessitating immediate investigation + and mitigation. data_source: - Windows Event Log Security 4698 search: '`wineventlog_security` EventCode=4698 | xmlkv Message| search Arguments IN @@ -60,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/tasksched/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/tasksched/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog diff --git a/detections/endpoint/schedule_task_with_rundll32_command_trigger.yml b/detections/endpoint/schedule_task_with_rundll32_command_trigger.yml index 65b615af4d..a399bddb7a 100644 --- a/detections/endpoint/schedule_task_with_rundll32_command_trigger.yml +++ b/detections/endpoint/schedule_task_with_rundll32_command_trigger.yml @@ -1,17 +1,18 @@ name: Schedule Task with Rundll32 Command Trigger id: 75b00fd8-a0ff-11eb-8b31-acde48001122 -version: 1 -date: '2021-04-19' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects the creation of suspicious tasks in Windows, specifically tasks using the rundll32 command. It's implemented using Windows Security EventCode 4698 for A scheduled task was created, and looks for tasks executed either via schtasks.exe or TaskService. This behavior is worth identifying as it is commonly used by malware, such as TrickBot, that leverages rundll32 to execute its downloader. - - If a true positive is found, it suggests an attacker is trying to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. - - To implement this analytic, ensure you are ingesting logs with task schedule information from your endpoints. Be aware of potential false positives - legitimate uses of Task Scheduler in your environment may cause benign activities to be flagged. - - Upon triage, review the scheduled task's source and the command to be executed. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. +description: The following analytic detects the creation of scheduled tasks in Windows + that use the rundll32 command. It leverages Windows Security EventCode 4698, which + logs the creation of scheduled tasks, and filters for tasks executed via rundll32. + This activity is significant as it is a common technique used by malware, such as + TrickBot, to persist in an environment or deliver additional payloads. If confirmed + malicious, this could lead to data theft, ransomware deployment, or other damaging + outcomes. Immediate investigation and mitigation are crucial to prevent further + compromise. data_source: - Windows Event Log Security 4698 search: '`wineventlog_security` EventCode=4698 | xmlkv Message | search Command IN @@ -62,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/tasksched/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/tasksched/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog diff --git a/detections/endpoint/scheduled_task_creation_on_remote_endpoint_using_at.yml b/detections/endpoint/scheduled_task_creation_on_remote_endpoint_using_at.yml index be52905571..6462ab1b60 100644 --- a/detections/endpoint/scheduled_task_creation_on_remote_endpoint_using_at.yml +++ b/detections/endpoint/scheduled_task_creation_on_remote_endpoint_using_at.yml @@ -1,26 +1,18 @@ name: Scheduled Task Creation on Remote Endpoint using At id: 4be54858-432f-11ec-8209-3e22fbd008af -version: 1 -date: '2021-11-11' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP -description: 'The following analytic detects the creation of suspicious tasks on a - remote Windows endpoint using the at.exe command with command-line arguments. This - technique is commonly used by red teams and adversaries for lateral movement and - remote code execution. The at.exe binary leverages the deprecated AT protocol, which - may still work on previous versions of Windows. Attackers can enable this protocol - on demand by modifying a system registry key. It is important to consider potential - false positives. While administrators may create scheduled tasks on remote systems, - this activity is typically limited to a small set of hosts or users. - - Identifying the creation of scheduled tasks on remote endpoints is crucial for a - Security Operations Center (SOC) because it indicates potential unauthorized activity - or an attacker attempting to establish persistence or execute malicious code. The - impact of a true positive can be significant, leading to unauthorized access, data - theft, or other damaging outcomes. During triage, investigate the source and purpose - of the scheduled task, inspect relevant on-disk artifacts, and analyze concurrent - processes to identify the extent of the attack and take appropriate response actions.' +description: 'The following analytic detects the creation of scheduled tasks on remote + Windows endpoints using the at.exe command. This detection leverages Endpoint Detection + and Response (EDR) telemetry, focusing on process creation events involving at.exe + with remote command-line arguments. Identifying this activity is significant for + a SOC as it may indicate lateral movement or remote code execution attempts by an + attacker. If confirmed malicious, this activity could lead to unauthorized access, + persistence, or execution of malicious code, potentially resulting in data theft + or further compromise of the network.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml b/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml index e8ab036a5e..3087f52f73 100644 --- a/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml +++ b/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml @@ -1,19 +1,18 @@ name: Scheduled Task Deleted Or Created via CMD id: d5af132c-7c17-439c-9d31-13d55340f36c -version: 6 -date: '2023-12-27' +version: 7 +date: '2024-05-17' author: Bhavin Patel, Splunk status: production type: TTP -description: This analytic focuses on identifying the creation or deletion of scheduled - tasks using the schtasks.exe utility with the corresponding command-line flags (-create - or -delete). This technique has been notably associated with threat actors like - Dragonfly and the SUNBURST attack against SolarWinds. The purpose of this analytic - is to detect suspicious activity related to scheduled tasks that could indicate - malicious intent or unauthorized system manipulation. By monitoring for these specific - command-line flags, we can enhance our ability to identify potential threats and - prevent attacks similar to the use of scheduled tasks in the BadRabbit Ransomware - incident. +description: The following analytic identifies the creation or deletion of scheduled + tasks using the schtasks.exe utility with the -create or -delete flags. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions. This activity is significant as it can indicate unauthorized + system manipulation or malicious intent, often associated with threat actors like + Dragonfly and incidents such as the SUNBURST attack. If confirmed malicious, this + activity could allow attackers to execute code, escalate privileges, or persist + within the environment, posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -21,7 +20,7 @@ search: '| tstats `security_content_summariesonly` count values(Processes.proces max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=schtasks.exe (Processes.process=*delete* OR Processes.process=*create*) by Processes.user Processes.process_name Processes.parent_process_name Processes.dest | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `scheduled_task_deleted_or_created_via_cmd_filter` ' + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `scheduled_task_deleted_or_created_via_cmd_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -95,6 +94,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/scheduled_task_initiation_on_remote_endpoint.yml b/detections/endpoint/scheduled_task_initiation_on_remote_endpoint.yml index f6f4ce647e..437884fada 100644 --- a/detections/endpoint/scheduled_task_initiation_on_remote_endpoint.yml +++ b/detections/endpoint/scheduled_task_initiation_on_remote_endpoint.yml @@ -1,18 +1,17 @@ name: Scheduled Task Initiation on Remote Endpoint id: 95cf4608-4302-11ec-8194-3e22fbd008af -version: 1 -date: '2021-11-11' +version: 2 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic detects instances of 'schtasks.exe' being used to start - a Scheduled Task on a remote endpoint. Adversaries often abuse the Task Scheduler - for lateral movement and remote code execution. The search parameters include process - details such as the process name, parent process, and command-line executions. - Although legitimate administrators may start scheduled tasks on remote systems, - this activity is usually limited to a small set of hosts or users. The findings - from this analytic provide valuable insight into potentially malicious activities - on an endpoint. +description: The following analytic detects the use of 'schtasks.exe' to start a Scheduled + Task on a remote endpoint. This detection leverages Endpoint Detection and Response + (EDR) data, focusing on process details such as process name, parent process, and + command-line executions. This activity is significant as adversaries often abuse + Task Scheduler for lateral movement and remote code execution. If confirmed malicious, + this behavior could allow attackers to execute arbitrary code remotely, potentially + leading to further compromise of the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/schtasks_run_task_on_demand.yml b/detections/endpoint/schtasks_run_task_on_demand.yml index 140110ad9f..e9f9b1188b 100644 --- a/detections/endpoint/schtasks_run_task_on_demand.yml +++ b/detections/endpoint/schtasks_run_task_on_demand.yml @@ -1,16 +1,19 @@ name: Schtasks Run Task On Demand id: bb37061e-af1f-11eb-a159-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is designed to detect when a Windows Scheduled - Task is executed on demand via shell or command line. Adversaries often force the - execution of their created Scheduled Tasks for persistent access or lateral movement - within a compromised machine. This analytic is driven by process-related data, specifically +description: The following analytic detects the execution of a Windows Scheduled Task + on demand via the shell or command line. It leverages process-related data, including process name, parent process, and command-line executions, sourced from endpoint - logs. The search criteria focus on 'schtasks.exe' with an associated 'run' command. + logs. The detection focuses on 'schtasks.exe' with an associated 'run' command. + This activity is significant as adversaries often use it to force the execution + of their created Scheduled Tasks for persistent access or lateral movement within + a compromised machine. If confirmed malicious, this could allow attackers to maintain + persistence or move laterally within the network, potentially leading to further + compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -74,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/schtasks_scheduling_job_on_remote_system.yml b/detections/endpoint/schtasks_scheduling_job_on_remote_system.yml index 3edd969350..0a0b4544cb 100644 --- a/detections/endpoint/schtasks_scheduling_job_on_remote_system.yml +++ b/detections/endpoint/schtasks_scheduling_job_on_remote_system.yml @@ -1,18 +1,18 @@ name: Schtasks scheduling job on remote system id: 1297fb80-f42a-4b4a-9c8a-88c066237cf6 -version: 6 -date: '2022-05-23' +version: 7 +date: '2024-05-14' author: David Dorsey, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic is designed to detect suspicious command-line - arguments executed through 'schtasks.exe' to create a scheduled task on a remote - endpoint. The analytic scans process data, checking for instances where 'schtasks.exe' - has been used with specific command-line flags that suggest an attempt at lateral - movement or remote code execution, common techniques employed by adversaries and - red teams. Key data points include the process name, the specific command line used, - the parent process name, the target destination, and the user involved. Also, timestamp - data gives context to when these activities occurred. +description: The following analytic detects the use of 'schtasks.exe' to create a + scheduled task on a remote system, indicating potential lateral movement or remote + code execution. It leverages process data from Endpoint Detection and Response (EDR) + agents, focusing on specific command-line arguments and flags. This activity is + significant as it may signify an adversary's attempt to persist or execute code + remotely. If confirmed malicious, this could allow attackers to maintain access, + execute arbitrary commands, or further infiltrate the network, posing a severe security + risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/schtasks_used_for_forcing_a_reboot.yml b/detections/endpoint/schtasks_used_for_forcing_a_reboot.yml index d3bb019f67..37ac72a0f1 100644 --- a/detections/endpoint/schtasks_used_for_forcing_a_reboot.yml +++ b/detections/endpoint/schtasks_used_for_forcing_a_reboot.yml @@ -1,19 +1,18 @@ name: Schtasks used for forcing a reboot id: 1297fb80-f42a-4b4a-9c8a-88c066437cf6 -version: 4 -date: '2020-12-07' +version: 5 +date: '2024-05-11' author: Bhavin Patel, Splunk status: production type: TTP -description: The following analytic utilizes a Splunk query to pinpoint potential - threats by monitoring the 'schtasks.exe' command-line usage. This particular command, - especially when used in tandem with 'shutdown' and '/create' flags, can suggest - an adversarial force intending to schedule unwarranted system reboots. The query - focuses on endpoint process data and retrieves details such as the process name, - the parent process name, the destination, and the user involved. Essential to the - investigation are the earliest and latest timestamps of these events, providing - an activity timeline. Data such as the targeted host and initiating user offer valuable - context for analyst. +description: The following analytic detects the use of 'schtasks.exe' to schedule + forced system reboots using the 'shutdown' and '/create' flags. It leverages endpoint + process data to identify instances where these specific command-line arguments are + used. This activity is significant because it may indicate an adversary attempting + to disrupt operations or force a reboot to execute further malicious actions. If + confirmed malicious, this could lead to system downtime, potential data loss, and + provide an attacker with an opportunity to execute additional payloads or evade + detection. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -73,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtask_shutdown/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtask_shutdown/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/screensaver_event_trigger_execution.yml b/detections/endpoint/screensaver_event_trigger_execution.yml index 70770c8280..78ba213d36 100644 --- a/detections/endpoint/screensaver_event_trigger_execution.yml +++ b/detections/endpoint/screensaver_event_trigger_execution.yml @@ -1,16 +1,18 @@ name: Screensaver Event Trigger Execution id: 58cea3ec-1f6d-11ec-8560-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is developed to detect possible event trigger execution - through screensaver registry entry modification for persistence or privilege escalation. - This technique was seen in several APT and malware where they put the malicious - payload path to the SCRNSAVE.EXE registry key to redirect the execution to their - malicious payload path. This TTP is a good indicator that some attacker may modify - this entry for their persistence and privilege escalation. +description: The following analytic detects modifications to the SCRNSAVE.EXE registry + entry, indicating potential event trigger execution via screensaver settings for + persistence or privilege escalation. It leverages registry activity data from the + Endpoint data model to identify changes to the specified registry path. This activity + is significant as it is a known technique used by APT groups and malware to maintain + persistence or escalate privileges. If confirmed malicious, this could allow an + attacker to execute arbitrary code with elevated privileges, leading to further + system compromise and persistent access. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.002/scrnsave_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.002/scrnsave_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/script_execution_via_wmi.yml b/detections/endpoint/script_execution_via_wmi.yml index a13aee7cfa..d8f42a5cb9 100644 --- a/detections/endpoint/script_execution_via_wmi.yml +++ b/detections/endpoint/script_execution_via_wmi.yml @@ -1,19 +1,19 @@ name: Script Execution via WMI id: aa73f80d-d728-4077-b226-81ea0c8be589 -version: 4 -date: '2020-03-16' +version: 5 +date: '2024-05-11' author: Rico Valdez, Michael Haag, Splunk status: production type: TTP description: |- - The following analytic detects any potential misuse of Windows Management Instrumentation (WMI) for malicious purposes since adversaries often use WMI to run scripts which allows them to carry out malicious activities without raising suspicion. The detection is made by monitoring the process 'scrcons.exe', which is essential to run WMI scripts. The detection is important because it proactively identifies and responds to potential threats that leverage WMI for malicious purposes that can lead to system compromise, data exfiltration, or the establishment of persistence within the environment. False positives might occur since administrators might occasionally use WMI to launch scripts for legitimate purposes. Therefore, you must distinguish between malicious and benign activities. + The following analytic detects the execution of scripts via Windows Management Instrumentation (WMI) by monitoring the process 'scrcons.exe'. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events. WMI-based script execution is significant because adversaries often use it to perform malicious activities stealthily, such as system compromise, data exfiltration, or establishing persistence. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, or maintain long-term access to the environment. Analysts should differentiate between legitimate administrative use and potential threats. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=scrcons.exe by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `script_execution_via_wmi_filter` ' + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `script_execution_via_wmi_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -59,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/execution_scrcons/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/execution_scrcons/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/sdclt_uac_bypass.yml b/detections/endpoint/sdclt_uac_bypass.yml index 0c33fe0463..47ee1614ca 100644 --- a/detections/endpoint/sdclt_uac_bypass.yml +++ b/detections/endpoint/sdclt_uac_bypass.yml @@ -1,14 +1,18 @@ name: Sdclt UAC Bypass id: d71efbf6-da63-11eb-8c6e-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-12' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious sdclt.exe registry modification. - This technique is commonly seen when attacker try to bypassed UAC by using sdclt.exe - application by modifying some registry that sdclt.exe tries to open or query with - payload file path on it to be executed. +description: The following analytic detects suspicious modifications to the sdclt.exe + registry, a technique often used to bypass User Account Control (UAC). It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on specific registry + paths and values associated with sdclt.exe. This activity is significant because + UAC bypasses can allow attackers to execute payloads with elevated privileges without + user consent. If confirmed malicious, this could lead to unauthorized code execution, + privilege escalation, and potential persistence within the environment, posing a + severe security risk. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -83,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/sdelete_application_execution.yml b/detections/endpoint/sdelete_application_execution.yml index 1a919ea6c6..69e6542438 100644 --- a/detections/endpoint/sdelete_application_execution.yml +++ b/detections/endpoint/sdelete_application_execution.yml @@ -1,16 +1,18 @@ name: Sdelete Application Execution id: 31702fc0-2682-11ec-85c3-acde48001122 -version: 1 -date: '2021-10-06' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect the execution of sdelete.exe application sysinternal - tools. This tool is one of the most use tool of malware and adversaries to remove - or clear their tracks and artifact in the targetted host. This tool is designed - to delete securely a file in file system that remove the forensic evidence on the - machine. A good TTP query to check why user execute this application which is not - a common practice. +description: The following analytic detects the execution of the sdelete.exe application, + a Sysinternals tool often used by adversaries to securely delete files and remove + forensic evidence from a targeted host. This detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process execution logs. Monitoring + this activity is crucial as sdelete.exe is not commonly used in regular operations + and its presence may indicate an attempt to cover malicious activities. If confirmed + malicious, this could lead to the loss of critical forensic data, hindering incident + response and investigation efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/sdelete/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/sdelete/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/searchprotocolhost_with_no_command_line_with_network.yml b/detections/endpoint/searchprotocolhost_with_no_command_line_with_network.yml index 5b80c3d81d..653159cc35 100644 --- a/detections/endpoint/searchprotocolhost_with_no_command_line_with_network.yml +++ b/detections/endpoint/searchprotocolhost_with_no_command_line_with_network.yml @@ -1,17 +1,18 @@ name: SearchProtocolHost with no Command Line with Network id: b690df8c-a145-11eb-a38b-acde48001122 -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies searchprotocolhost.exe with no command - line arguments and with a network connection. It is unusual for searchprotocolhost.exe - to execute with no command line arguments present. This particular behavior is common - with malicious software, including Cobalt Strike. During investigation, identify - any network connections and parallel processes. Identify any suspicious module loads - related to credential dumping or file writes. searchprotocolhost.exe is natively - found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects instances of searchprotocolhost.exe running + without command line arguments but with an active network connection. This behavior + is identified using Endpoint Detection and Response (EDR) telemetry, focusing on + process execution and network traffic data. It is significant because searchprotocolhost.exe + typically runs with specific command line arguments, and deviations from this norm + can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, + this activity could allow attackers to establish network connections for command + and control, potentially leading to data exfiltration or further system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -73,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon_searchprotocolhost.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon_searchprotocolhost.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/secretdumps_offline_ntds_dumping_tool.yml b/detections/endpoint/secretdumps_offline_ntds_dumping_tool.yml index aa2c24789d..45c91d0cb8 100644 --- a/detections/endpoint/secretdumps_offline_ntds_dumping_tool.yml +++ b/detections/endpoint/secretdumps_offline_ntds_dumping_tool.yml @@ -1,14 +1,18 @@ name: SecretDumps Offline NTDS Dumping Tool id: 5672819c-be09-11eb-bbfb-acde48001122 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects a potential usage of secretsdump.py tool for dumping - credentials (ntlm hash) from a copy of ntds.dit and SAM.Security,SYSTEM registrry - hive. This technique was seen in some attacker that dump ntlm hashes offline after - having a copy of ntds.dit and SAM/SYSTEM/SECURITY registry hive. +description: The following analytic detects the potential use of the secretsdump.py + tool to dump NTLM hashes from a copy of ntds.dit and the SAM, SYSTEM, and SECURITY + registry hives. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on specific command-line patterns and process names associated with secretsdump.py. + This activity is significant because it indicates an attempt to extract sensitive + credential information offline, which is a common post-exploitation technique. If + confirmed malicious, this could allow an attacker to obtain NTLM hashes, facilitating + further lateral movement and potential privilege escalation within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/casper/datasets1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/serviceprincipalnames_discovery_with_powershell.yml b/detections/endpoint/serviceprincipalnames_discovery_with_powershell.yml index b8f5af41da..95cce99f66 100644 --- a/detections/endpoint/serviceprincipalnames_discovery_with_powershell.yml +++ b/detections/endpoint/serviceprincipalnames_discovery_with_powershell.yml @@ -1,33 +1,23 @@ name: ServicePrincipalNames Discovery with PowerShell id: 13243068-2d38-11ec-8908-acde48001122 -version: 2 -date: '2022-02-26' +version: 3 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies `powershell.exe` usage, using Script - Block Logging EventCode 4104, related to querying the domain for Service Principle - Names. typically, this is a precursor activity related to kerberoasting or the silver - ticket attack. - - What is a ServicePrincipleName? - - A service principal name (SPN) is a unique identifier of a service instance. SPNs - are used by Kerberos authentication to associate a service instance with a service - logon account. This allows a client application to request that the service authenticate - an account even if the client does not have the account name. - - The following analytic identifies the use of KerberosRequestorSecurityToken class - within the script block. Using .NET System.IdentityModel.Tokens.KerberosRequestorSecurityToken - class in PowerShell is the equivelant of using setspn.exe. - - During triage, review parallel processes for further suspicious activity.' +description: 'The following analytic detects the use of `powershell.exe` to query + the domain for Service Principal Names (SPNs) using Script Block Logging EventCode + 4104. It identifies the use of the KerberosRequestorSecurityToken class within the + script block, which is equivalent to using setspn.exe. This activity is significant + as it often precedes kerberoasting or silver ticket attacks, which can lead to credential + theft. If confirmed malicious, attackers could leverage this information to escalate + privileges or persist within the environment.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText="*KerberosRequestorSecurityToken*" | stats count min(_time) as firstTime max(_time) as lastTime by ScriptBlockText - Opcode Computer UserID EventCode | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `serviceprincipalnames_discovery_with_powershell_filter`' + Opcode Computer UserID EventCode | rename Computer as dest | rename UserID as user + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `serviceprincipalnames_discovery_with_powershell_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -85,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/serviceprincipalnames_discovery_with_setspn.yml b/detections/endpoint/serviceprincipalnames_discovery_with_setspn.yml index 3409f4e83a..d16327f89d 100644 --- a/detections/endpoint/serviceprincipalnames_discovery_with_setspn.yml +++ b/detections/endpoint/serviceprincipalnames_discovery_with_setspn.yml @@ -1,33 +1,17 @@ name: ServicePrincipalNames Discovery with SetSPN id: ae8b3efc-2d2e-11ec-8b57-acde48001122 -version: 1 -date: '2021-10-14' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies `setspn.exe` usage related to querying - the domain for Service Principle Names. typically, this is a precursor activity - related to kerberoasting or the silver ticket attack. - - What is a ServicePrincipleName? - - A service principal name (SPN) is a unique identifier of a service instance. SPNs - are used by Kerberos authentication to associate a service instance with a service - logon account. This allows a client application to request that the service authenticate - an account even if the client does not have the account name. - - Example usage includes the following - - * setspn -T offense -Q */* 1. setspn -T attackrange.local -F -Q MSSQLSvc/* 1. setspn - -Q */* > allspns.txt 1. setspn -q - - Values - - * -F = perform queries at the forest, rather than domain level 1. -T = perform - query on the specified domain or forest (when -F is also used) 1. -Q = query for - existence of SPN - - During triage, review parallel processes for further suspicious activity.' +description: 'The following analytic detects the use of `setspn.exe` to query the + domain for Service Principal Names (SPNs). This detection leverages Endpoint Detection + and Response (EDR) data, focusing on specific command-line arguments associated + with `setspn.exe`. Monitoring this activity is crucial as it often precedes Kerberoasting + or Silver Ticket attacks, which can lead to credential theft. If confirmed malicious, + an attacker could use the gathered SPNs to escalate privileges or persist within + the environment, posing a significant security risk.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -109,6 +93,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/atomic_red_team/windows-sysmon_setspn.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/atomic_red_team/windows-sysmon_setspn.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/services_escalate_exe.yml b/detections/endpoint/services_escalate_exe.yml index 6516615767..df20d5640f 100644 --- a/detections/endpoint/services_escalate_exe.yml +++ b/detections/endpoint/services_escalate_exe.yml @@ -1,22 +1,18 @@ name: Services Escalate Exe id: c448488c-b7ec-11eb-8253-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of `svc-exe` with Cobalt Strike. - The behavior typically follows after an adversary has already gained initial access - and is escalating privileges. Using `svc-exe`, a randomly named binary will be downloaded - from the remote Teamserver and placed on disk within `C:\Windows\400619a.exe`. Following, - the binary will be added to the registry under key `HKLM\System\CurrentControlSet\Services\400619a\` - with multiple keys and values added to look like a legitimate service. Upon loading, - `services.exe` will spawn the randomly named binary from `\\127.0.0.1\ADMIN$\400619a.exe`. - The process lineage is completed with `400619a.exe` spawning rundll32.exe, which - is the default `spawnto_` value for Cobalt Strike. The `spawnto_` value is arbitrary - and may be any process on disk (typically system32/syswow64 binary). The `spawnto_` - process will also contain a network connection. During triage, review parallel procesess - and identify any additional file modifications. +description: The following analytic identifies the execution of a randomly named binary + via `services.exe`, indicative of privilege escalation using Cobalt Strike's `svc-exe`. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process lineage and command-line executions. This activity is significant + as it often follows initial access, allowing adversaries to escalate privileges + and establish persistence. If confirmed malicious, this behavior could enable attackers + to execute arbitrary code, maintain long-term access, and potentially move laterally + within the network, posing a severe threat to the organization's security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/services_lolbas_execution_process_spawn.yml b/detections/endpoint/services_lolbas_execution_process_spawn.yml index f55c2de675..93510c2490 100644 --- a/detections/endpoint/services_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/services_lolbas_execution_process_spawn.yml @@ -1,17 +1,18 @@ name: Services LOLBAS Execution Process Spawn id: ba9e1954-4c04-11ec-8b74-3e22fbd008af -version: 1 -date: '2021-11-22' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies `services.exe` spawning a LOLBAS execution - process. When adversaries execute code on remote endpoints abusing the Service Control - Manager and creating a remote malicious service, the executed command is spawned - as a child process of `services.exe`. The LOLBAS project documents Windows native - binaries that can be abused by threat actors to perform tasks like executing malicious - code. Looking for child processes of services.exe that are part of the LOLBAS project - can help defenders identify lateral movement activity. +description: The following analytic identifies `services.exe` spawning a LOLBAS (Living + Off the Land Binaries and Scripts) execution process. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process creation events where `services.exe` + is the parent process. This activity is significant because adversaries often abuse + the Service Control Manager to execute malicious code via native Windows binaries, + facilitating lateral movement. If confirmed malicious, this behavior could allow + attackers to execute arbitrary code, escalate privileges, or maintain persistence + within the environment, posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement_lolbas/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement_lolbas/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/shim_database_file_creation.yml b/detections/endpoint/shim_database_file_creation.yml index a54e073409..737398ef05 100644 --- a/detections/endpoint/shim_database_file_creation.yml +++ b/detections/endpoint/shim_database_file_creation.yml @@ -1,15 +1,17 @@ name: Shim Database File Creation id: 6e4c4588-ba2f-42fa-97e6-9f6f548eaa33 -version: 3 -date: '2020-12-08' +version: 4 +date: '2024-05-19' author: David Dorsey, Splunk status: production type: TTP -description: This search looks for shim database files being written to default directories. - The sdbinst.exe application is used to install shim database files (.sdb). According - to Microsoft, a shim is a small library that transparently intercepts an API, changes - the parameters passed, handles the operation itself, or redirects the operation - elsewhere. +description: The following analytic detects the creation of shim database files (.sdb) + in default directories using the sdbinst.exe application. It leverages filesystem + activity data from the Endpoint.Filesystem data model to identify file writes to + the Windows\AppPatch\Custom directory. This activity is significant because shims + can intercept and alter API calls, potentially allowing attackers to bypass security + controls or execute malicious code. If confirmed malicious, this could lead to unauthorized + code execution, privilege escalation, or persistent access within the environment. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count values(Filesystem.action) @@ -59,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/shim_database_installation_with_suspicious_parameters.yml b/detections/endpoint/shim_database_installation_with_suspicious_parameters.yml index 850cc36f14..d23095f980 100644 --- a/detections/endpoint/shim_database_installation_with_suspicious_parameters.yml +++ b/detections/endpoint/shim_database_installation_with_suspicious_parameters.yml @@ -1,15 +1,18 @@ name: Shim Database Installation With Suspicious Parameters id: 404620de-46d8-48b6-90cc-8a8d7b0876a3 -version: 4 -date: '2020-11-23' +version: 5 +date: '2024-05-09' author: David Dorsey, Splunk status: production type: TTP -description: This search detects the process execution and arguments required to silently - create a shim database. The sdbinst.exe application is used to install shim database - files (.sdb). A shim is a small library which transparently intercepts an API, changes - the parameters passed, handles the operation itself, or redirects the operation - elsewhere. +description: The following analytic detects the execution of sdbinst.exe with parameters + indicative of silently creating a shim database. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, parent processes, + and command-line arguments. This activity is significant because shim databases + can be used to intercept and manipulate API calls, potentially allowing attackers + to bypass security controls or achieve persistence. If confirmed malicious, this + could enable unauthorized code execution, privilege escalation, or persistent access + to the compromised system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -63,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/short_lived_scheduled_task.yml b/detections/endpoint/short_lived_scheduled_task.yml index 1ef4cffda5..59415847fe 100644 --- a/detections/endpoint/short_lived_scheduled_task.yml +++ b/detections/endpoint/short_lived_scheduled_task.yml @@ -1,32 +1,18 @@ name: Short Lived Scheduled Task id: 6fa31414-546e-11ec-adfa-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-17' author: Mauricio Velazco, Splunk status: production type: TTP -description: 'The following analytic utilizes Windows Security EventCode 4698, "A - scheduled task was created," and EventCode 4699, "A scheduled task was deleted," - to identify scheduled tasks that are created and deleted within a short time frame - of less than 30 seconds. This behavior is indicative of a potential lateral movement - attack where the Task Scheduler is abused to achieve code execution. Both red teams - and adversaries may exploit the Task Scheduler for lateral movement and remote code - execution. - - To implement this analytic, ensure that you are ingesting Windows Security Event - Logs with EventCode 4698 enabled. Additionally, the Windows TA (Technology Add-on) - is required to parse and extract the necessary information from the logs. - - It''s important to note that while uncommon, legitimate applications may create - and delete scheduled tasks within a short duration. Analysts should filter the results - based on the specific context and environment to reduce false positives. - - Identifying short-lived scheduled tasks is valuable for a SOC as it can indicate - malicious activities attempting to move laterally or execute unauthorized code on - Windows systems. By detecting and investigating these events, security analysts - can respond promptly to prevent further compromise and mitigate potential risks. - The impact of a true positive could range from unauthorized access to data exfiltration - or the execution of malicious payloads.' +description: 'The following analytic detects the creation and deletion of scheduled + tasks within a short time frame (less than 30 seconds) using Windows Security EventCodes + 4698 and 4699. This behavior is identified by analyzing Windows Security Event Logs + and leveraging the Windows TA for parsing. Such activity is significant as it may + indicate lateral movement or remote code execution attempts by adversaries. If confirmed + malicious, this could lead to unauthorized access, data exfiltration, or execution + of malicious payloads, necessitating prompt investigation and response by security + analysts.' data_source: - Windows Event Log Security 4698 - Windows Event Log Security 4699 @@ -34,7 +20,7 @@ search: ' `wineventlog_security` EventCode=4698 OR EventCode=4699 | xmlkv Messag | transaction Task_Name startswith=(EventCode=4698) endswith=(EventCode=4699) | eval short_lived=case((duration<30),"TRUE") | search short_lived = TRUE | rename ComputerName as dest| table _time, dest, Account_Name, Command, Task_Name, short_lived - | `short_lived_scheduled_task_filter` ' + | `short_lived_scheduled_task_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. @@ -77,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/lateral_movement/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/lateral_movement/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog diff --git a/detections/endpoint/short_lived_windows_accounts.yml b/detections/endpoint/short_lived_windows_accounts.yml index 2f912af286..211e0ef1ec 100644 --- a/detections/endpoint/short_lived_windows_accounts.yml +++ b/detections/endpoint/short_lived_windows_accounts.yml @@ -1,12 +1,12 @@ name: Short Lived Windows Accounts id: b25f6f62-0782-43c1-b403-083231ffd97d -version: 3 -date: '2024-03-19' +version: 4 +date: '2024-05-14' author: David Dorsey, Splunk status: production type: TTP description: |- - The following analytic detects the creation and deletion of accounts in a short time period to identify potential threats earlier and take appropriate actions to mitigate the risks. Helps prevent or minimize the potential damage caused by unauthorized access or malicious activities within the environment. This detection is made by a Splunk query that searches for events with the result IDs 4720 and 4726 in the "Change" data model. The query then groups the results by time, user, and destination. The result is filtered to only include events with the specified result IDs. The "transaction" command is used to group events that occur within a specified time span and have the same user but are not connected. Finally, the relevant information such as the first and last time of the event, the count, user, destination, and result ID are displayed in a table. This detection is important because it suggests that an attacker is attempting to create and delete accounts rapidly, potentially to cover their tracks or gain unauthorized access. The impact of such an attack can include unauthorized access to sensitive data, privilege escalation, or the ability to carry out further malicious activities within the environment. Next steps include investigating the events flagged by the analytic, review the account creation and deletion activities, and analyze any associated logs or artifacts to determine the intent and impact of the attack. + The following analytic detects the rapid creation and deletion of Windows accounts within a short time frame. It leverages the "Change" data model in Splunk, specifically monitoring events with result IDs 4720 (account creation) and 4726 (account deletion). This behavior is significant as it may indicate an attacker attempting to create and remove accounts quickly to evade detection or gain unauthorized access. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, or further malicious actions within the environment. Immediate investigation of flagged events is crucial to mitigate potential damage. data_source: - Windows Event Log System 4720 - Windows Event Log System 4726 @@ -56,14 +56,17 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog update_timestamp: true - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-system.log source: WinEventLog:System sourcetype: WinEventLog update_timestamp: true - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/silentcleanup_uac_bypass.yml b/detections/endpoint/silentcleanup_uac_bypass.yml index 2a51d4db6b..06dd984ad7 100644 --- a/detections/endpoint/silentcleanup_uac_bypass.yml +++ b/detections/endpoint/silentcleanup_uac_bypass.yml @@ -1,14 +1,18 @@ name: SilentCleanup UAC Bypass id: 56d7cfcc-da63-11eb-92d4-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-18' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious modification of registry that may - related to UAC bypassed. This registry will be trigger once the attacker abuse the - silentcleanup task schedule to gain high privilege execution that will bypass User - control account. +description: The following analytic detects suspicious modifications to the registry + that may indicate a UAC (User Account Control) bypass attempt via the SilentCleanup + task. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on registry changes in the path "*\\Environment\\windir" with executable values. + This activity is significant as it can allow an attacker to gain high-privilege + execution without user consent, bypassing UAC protections. If confirmed malicious, + this could lead to unauthorized administrative access, enabling further system compromise + and persistence. data_source: - Sysmon EventID 1 - Sysmon EventID 12 @@ -81,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/single_letter_process_on_endpoint.yml b/detections/endpoint/single_letter_process_on_endpoint.yml index be5ab4b8aa..9f4b91fe89 100644 --- a/detections/endpoint/single_letter_process_on_endpoint.yml +++ b/detections/endpoint/single_letter_process_on_endpoint.yml @@ -1,12 +1,12 @@ name: Single Letter Process On Endpoint id: a4214f0b-e01c-41bc-8cc4-d2b71e3056b4 -version: 3 -date: '2020-12-08' +version: 4 +date: '2024-05-27' author: David Dorsey, Splunk status: production type: TTP description: |- - The following analytic detects a behavior where a process name consists only of a single letter that helps to detect potential threats earlier and mitigate the risks. This detection is important because it indicates the presence of malware or an attacker attempting to evade detection by using a process name that is difficult to identify or track so that he can carry out malicious activities such as data theft or ransomware attacks. False positives might occur since there might be legitimate uses of single-letter process names in your environment. Next steps include reviewing the process details and investigating any suspicious activity upon triage. + The following analytic detects processes with names consisting of a single letter, which is often indicative of malware or an attacker attempting to evade detection. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because attackers use such techniques to obscure their presence and carry out malicious activities like data theft or ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized access, data exfiltration, or system compromise. Immediate investigation is required to determine the legitimacy of the process. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.002/single_letter_exe/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1204.002/single_letter_exe/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/slui_runas_elevated.yml b/detections/endpoint/slui_runas_elevated.yml index 3a524e0db0..4e1704c562 100644 --- a/detections/endpoint/slui_runas_elevated.yml +++ b/detections/endpoint/slui_runas_elevated.yml @@ -1,16 +1,18 @@ name: SLUI RunAs Elevated id: 8d124810-b3e4-11eb-96c7-acde48001122 -version: 1 -date: '2021-05-13' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the Microsoft Software Licensing User - Interface Tool, `slui.exe`, elevating access using the `-verb runas` function. This - particular bypass utilizes a registry key/value. Identified by two sources, the - registry keys are `HKCU\Software\Classes\exefile\shell` and `HKCU\Software\Classes\launcher.Systemsettings\Shell\open\command`. - To simulate this behavior, multiple POC are available. The analytic identifies the - use of `runas` by `slui.exe`. +description: The following analytic detects the execution of the Microsoft Software + Licensing User Interface Tool (`slui.exe`) with elevated privileges using the `-verb + runas` function. This activity is identified through logs from Endpoint Detection + and Response (EDR) agents, focusing on specific registry keys and command-line parameters. + This behavior is significant as it indicates a potential privilege escalation attempt, + which could allow an attacker to gain elevated access and execute malicious actions + with higher privileges. If confirmed malicious, this could lead to unauthorized + system changes, data exfiltration, or further compromise of the affected endpoint. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/slui/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/slui/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/slui_spawning_a_process.yml b/detections/endpoint/slui_spawning_a_process.yml index ad739a265a..0f60018064 100644 --- a/detections/endpoint/slui_spawning_a_process.yml +++ b/detections/endpoint/slui_spawning_a_process.yml @@ -1,24 +1,26 @@ name: SLUI Spawning a Process id: 879c4330-b3e0-11eb-b1b1-acde48001122 -version: 1 -date: '2021-05-13' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the Microsoft Software Licensing User - Interface Tool, `slui.exe`, spawning a child process. This behavior is associated - with publicly known UAC bypass. `slui.exe` is commonly associated with software - updates and is most often spawned by `svchost.exe`. The `slui.exe` process should - not have child processes, and any processes spawning from it will be running with - elevated privileges. During triage, review the child process and additional parallel - processes. Identify any file modifications that may have lead to the bypass. +description: The following analytic detects the Microsoft Software Licensing User + Interface Tool (`slui.exe`) spawning a child process. This behavior is identified + using Endpoint Detection and Response (EDR) telemetry, focusing on process creation + events where `slui.exe` is the parent process. This activity is significant because + `slui.exe` should not typically spawn child processes, and doing so may indicate + a UAC bypass attempt, leading to elevated privileges. If confirmed malicious, an + attacker could leverage this to execute code with elevated privileges, potentially + compromising the system's security and gaining unauthorized access. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=slui.exe - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `slui_spawning_a_process_filter`' + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `slui_spawning_a_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -73,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/slui/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/slui/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/spike_in_file_writes.yml b/detections/endpoint/spike_in_file_writes.yml index 41de33ab9e..b7c38733cb 100644 --- a/detections/endpoint/spike_in_file_writes.yml +++ b/detections/endpoint/spike_in_file_writes.yml @@ -20,7 +20,7 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint >= relative_time(maxtime, "-1d@d"), count, null))) as "count" avg(eval(if(_time upperBound) AND num_data_samples >=20, 1, 0) | search isOutlier=1 | `spike_in_file_writes_filter` ' + > upperBound) AND num_data_samples >=20, 1, 0) | search isOutlier=1 | `spike_in_file_writes_filter`' how_to_implement: In order to implement this search, you must populate the Endpoint file-system data model node. This is typically populated via endpoint detection and response product, such as Carbon Black or endpoint data sources such as Sysmon. diff --git a/detections/endpoint/spoolsv_spawning_rundll32.yml b/detections/endpoint/spoolsv_spawning_rundll32.yml index 6b3bbea8c9..a368a4bb44 100644 --- a/detections/endpoint/spoolsv_spawning_rundll32.yml +++ b/detections/endpoint/spoolsv_spawning_rundll32.yml @@ -1,24 +1,27 @@ name: Spoolsv Spawning Rundll32 id: 15d905f6-da6b-11eb-ab82-acde48001122 -version: 2 -date: '2021-07-01' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a suspicious child process, `rundll32.exe`, - with no command-line arguments being spawned from `spoolsv.exe`. This was identified - during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. - Typically, this is not normal behavior for `spoolsv.exe` to spawn a process. During - triage, isolate the endpoint and review for source of exploitation. Capture any - additional file modification events. +description: The following analytic detects the spawning of `rundll32.exe` without + command-line arguments by `spoolsv.exe`, which is unusual and potentially indicative + of exploitation attempts like CVE-2021-34527 (PrintNightmare). This detection leverages + Endpoint Detection and Response (EDR) telemetry, focusing on process creation events + where `spoolsv.exe` is the parent process. This activity is significant as `spoolsv.exe` + typically does not spawn other processes, and such behavior could indicate an active + exploitation attempt. If confirmed malicious, this could allow an attacker to execute + arbitrary code, escalate privileges, or maintain persistence on the compromised + endpoint. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=spoolsv.exe - `process_rundll32` by Processes.dest Processes.user Processes.parent_process_name Processes.original_file_name - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `spoolsv_spawning_rundll32_filter`' + `process_rundll32` by Processes.dest Processes.user Processes.parent_process_name + Processes.original_file_name Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `spoolsv_spawning_rundll32_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -42,8 +45,8 @@ tags: cve: - CVE-2021-34527 impact: 80 - message: $parent_process_name$ has spawned $process_name$ on endpoint $dest$. - This behavior is suspicious and related to PrintNightmare. + message: $parent_process_name$ has spawned $process_name$ on endpoint $dest$. This + behavior is suspicious and related to PrintNightmare. mitre_attack_id: - T1547.012 - T1547 @@ -78,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/spoolsv_suspicious_process_access.yml b/detections/endpoint/spoolsv_suspicious_process_access.yml index 7bc07eb985..5321e878ab 100644 --- a/detections/endpoint/spoolsv_suspicious_process_access.yml +++ b/detections/endpoint/spoolsv_suspicious_process_access.yml @@ -1,15 +1,18 @@ name: Spoolsv Suspicious Process Access id: 799b606e-da81-11eb-93f8-acde48001122 -version: 1 -date: '2021-07-01' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Michael Haag, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies a suspicious behavior related to PrintNightmare, - or CVE-2021-34527 previously (CVE-2021-1675), to gain privilege escalation on the - vulnerable machine. This exploit attacks a critical Windows Print Spooler Vulnerability - to elevate privilege. This detection is to look for suspicious process access made - by the spoolsv.exe that may related to the attack. +description: The following analytic detects suspicious process access by spoolsv.exe, + potentially indicating exploitation of the PrintNightmare vulnerability (CVE-2021-34527). + It leverages Sysmon EventCode 10 to identify when spoolsv.exe accesses critical + system files or processes like rundll32.exe with elevated privileges. This activity + is significant as it may signal an attempt to gain unauthorized privilege escalation + on a vulnerable machine. If confirmed malicious, an attacker could achieve elevated + privileges, leading to further system compromise, persistent access, or unauthorized + control over the affected environment. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 SourceImage = "*\\spoolsv.exe" CallTrace = "*\\Windows\\system32\\spool\\DRIVERS\\x64\\*" @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/spoolsv_writing_a_dll.yml b/detections/endpoint/spoolsv_writing_a_dll.yml index 8b95eabe07..72a318e110 100644 --- a/detections/endpoint/spoolsv_writing_a_dll.yml +++ b/detections/endpoint/spoolsv_writing_a_dll.yml @@ -1,16 +1,18 @@ name: Spoolsv Writing a DLL id: d5bf5cf2-da71-11eb-92c2-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-27' author: Mauricio Velazco, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a `.dll` being written by `spoolsv.exe`. - This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) - or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write - a `.dll`. Current POC code used will write the suspicious DLL to disk within a path - of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source - of exploitation. Capture any additional file modification events. +description: The following analytic detects `spoolsv.exe` writing a `.dll` file, which + is unusual behavior and may indicate exploitation of vulnerabilities like CVE-2021-34527 + (PrintNightmare). This detection leverages the Endpoint datamodel, specifically + monitoring process and filesystem events to identify `.dll` file creation within + the `\spool\drivers\x64\` path. This activity is significant as it may signify an + attacker attempting to execute malicious code via the Print Spooler service. If + confirmed malicious, this could lead to unauthorized code execution and potential + system compromise. Immediate endpoint isolation and further investigation are recommended. data_source: - Sysmon EventID 1 - Sysmon EventID 11 @@ -21,9 +23,9 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path="*\\spool\\drivers\\x64\\*" Filesystem.file_name="*.dll" by _time Filesystem.dest Filesystem.process_guid Filesystem.file_create_time Filesystem.file_name Filesystem.file_path | `drop_dm_object_name(Filesystem)` | - fields _time dest file_create_time file_name file_path process_name process_path process_guid - process] | dedup file_create_time | table dest file_create_time, file_name, file_path, - process_name process_guid | `spoolsv_writing_a_dll_filter`' + fields _time dest file_create_time file_name file_path process_name process_path + process_guid process] | dedup file_create_time | table dest file_create_time, file_name, + file_path, process_name process_guid | `spoolsv_writing_a_dll_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/spoolsv_writing_a_dll___sysmon.yml b/detections/endpoint/spoolsv_writing_a_dll___sysmon.yml index e4ada7b87e..66efe10da1 100644 --- a/detections/endpoint/spoolsv_writing_a_dll___sysmon.yml +++ b/detections/endpoint/spoolsv_writing_a_dll___sysmon.yml @@ -1,16 +1,18 @@ name: Spoolsv Writing a DLL - Sysmon id: 347fd388-da87-11eb-836d-acde48001122 -version: 1 -date: '2021-07-01' +version: 2 +date: '2024-05-17' author: Mauricio Velazco, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a `.dll` being written by `spoolsv.exe`. - This was identified during our testing of CVE-2021-34527 previously(CVE-2021-1675) - or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write - a `.dll`. Current POC code used will write the suspicious DLL to disk within a path - of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source - of exploitation. Capture any additional file modification events. +description: The following analytic detects `spoolsv.exe` writing a `.dll` file, which + is unusual behavior and may indicate exploitation of vulnerabilities like CVE-2021-34527 + (PrintNightmare). This detection leverages Sysmon Event ID 11 to monitor file creation + events in the `\spool\drivers\x64\` directory. This activity is significant because + `spoolsv.exe` typically does not write DLL files, and such behavior could signify + an ongoing attack. If confirmed malicious, this could allow an attacker to execute + arbitrary code, escalate privileges, or maintain persistence on the compromised + system. data_source: - Sysmon EventID 11 search: '`sysmon` EventID=11 process_name=spoolsv.exe file_path="*\\spool\\drivers\\x64\\*" @@ -70,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/printnightmare/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/sqlite_module_in_temp_folder.yml b/detections/endpoint/sqlite_module_in_temp_folder.yml index 7b8bb3220d..dc4abc1eed 100644 --- a/detections/endpoint/sqlite_module_in_temp_folder.yml +++ b/detections/endpoint/sqlite_module_in_temp_folder.yml @@ -1,20 +1,23 @@ name: Sqlite Module In Temp Folder id: 0f216a38-f45f-11eb-b09c-acde48001122 -version: 1 -date: '2021-08-03' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious file creation of sqlite3.dll in - %temp% folder. This behavior was seen in IcedID malware where it download sqlite - module to parse browser database like for chrome or firefox to stole browser information - related to bank, credit card or credentials. +description: The following analytic detects the creation of sqlite3.dll files in the + %temp% folder. It leverages Sysmon EventCode 11 to identify when these files are + written to the temporary directory. This activity is significant because it is associated + with IcedID malware, which uses the sqlite3 module to parse browser databases and + steal sensitive information such as banking details, credit card information, and + credentials. If confirmed malicious, this behavior could lead to significant data + theft and compromise of user accounts. data_source: - Sysmon EventID 11 search: '`sysmon` EventCode=11 (TargetFilename = "*\\sqlite32.dll" OR TargetFilename - = "*\\sqlite64.dll") (TargetFilename = "*\\temp\\*") - | stats count min(_time) as - firstTime max(_time) as lastTime by dest signature signature_id process_name file_name file_path action process_guid| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + = "*\\sqlite64.dll") (TargetFilename = "*\\temp\\*") | stats count min(_time) as + firstTime max(_time) as lastTime by dest signature signature_id process_name file_name + file_path action process_guid| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `sqlite_module_in_temp_folder_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -57,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/simulated_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/steal_or_forge_authentication_certificates_behavior_identified.yml b/detections/endpoint/steal_or_forge_authentication_certificates_behavior_identified.yml index c6f46a74e7..05f3834ed9 100644 --- a/detections/endpoint/steal_or_forge_authentication_certificates_behavior_identified.yml +++ b/detections/endpoint/steal_or_forge_authentication_certificates_behavior_identified.yml @@ -1,19 +1,36 @@ name: Steal or Forge Authentication Certificates Behavior Identified id: 87ac670e-bbfd-44ca-b566-44e9f835518d -version: 1 -date: '2023-05-01' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: Correlation data_source: [] -description: This correlation rule focuses on detecting potential threats associated with MITRE ATT&CK T1649 (Steal or Forge Authentication Certificates). The rule is designed to identify instances where 5 or more analytics related to Windows Certificate Services analytic story that are triggered within a specified time frame, which may indicate a potential attack in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. -search: '| 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 All_Risk.analyticstories="Windows Certificate Services" All_Risk.risk_object_type="system" by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where source_count >= 5 | `steal_or_forge_authentication_certificates_behavior_identified_filter`' -how_to_implement: The Windows Certificate Services analytic story must have 5 or more analytics enabled. In addition, ensure data is being logged that is required. Modify the correlation as needed based on volume of noise related to the other analytics. -known_false_positives: False positives may be present based on automated tooling or system administrators. Filter as needed. +description: The following analytic identifies potential threats related to the theft + or forgery of authentication certificates. It detects when five or more analytics + from the Windows Certificate Services story trigger within a specified timeframe. + This detection leverages aggregated risk scores and event counts from the Risk data + model. This activity is significant as it may indicate an ongoing attack aimed at + compromising authentication mechanisms. If confirmed malicious, attackers could + gain unauthorized access to sensitive systems and data, potentially leading to severe + security breaches. +search: '| 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 All_Risk.analyticstories="Windows + Certificate Services" All_Risk.risk_object_type="system" by All_Risk.risk_object + All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 5 | `steal_or_forge_authentication_certificates_behavior_identified_filter`' +how_to_implement: The Windows Certificate Services analytic story must have 5 or more + analytics enabled. In addition, ensure data is being logged that is required. Modify + the correlation as needed based on volume of noise related to the other analytics. +known_false_positives: False positives may be present based on automated tooling or + system administrators. Filter as needed. references: - https://research.splunk.com/stories/windows_certificate_services/ - https://attack.mitre.org/techniques/T1649/ @@ -50,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/risk_certificate_services.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/risk_certificate_services.log source: certs sourcetype: stash diff --git a/detections/endpoint/sunburst_correlation_dll_and_network_event.yml b/detections/endpoint/sunburst_correlation_dll_and_network_event.yml index 26c97d169c..d52b748e83 100644 --- a/detections/endpoint/sunburst_correlation_dll_and_network_event.yml +++ b/detections/endpoint/sunburst_correlation_dll_and_network_event.yml @@ -20,7 +20,7 @@ search: '(`sysmon` EventCode=7 ImageLoaded=*SolarWinds.Orion.Core.BusinessLayer. AS dc_events | where dc_events=2 | stats min(_time) as firstTime max(_time) as lastTime values(ImageLoaded) AS ImageLoaded values(QueryName) AS QueryName by host | rename host as dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `sunburst_correlation_dll_and_network_event_filter` ' + | `sunburst_correlation_dll_and_network_event_filter`' how_to_implement: This detection relies on sysmon logs with the Event ID 7, Driver loaded. Please tune your sysmon config that you DriverLoad event for SolarWinds.Orion.Core.BusinessLayer.dll is captured by Sysmon. Additionally, you need sysmon logs for Event ID 22, DNS Query. diff --git a/detections/endpoint/suspicious_computer_account_name_change.yml b/detections/endpoint/suspicious_computer_account_name_change.yml index d04e89a1e5..84d32e4c57 100644 --- a/detections/endpoint/suspicious_computer_account_name_change.yml +++ b/detections/endpoint/suspicious_computer_account_name_change.yml @@ -1,23 +1,22 @@ name: Suspicious Computer Account Name Change id: 35a61ed8-61c4-11ec-bc1e-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-17' author: Mauricio Velazco, Splunk status: production type: TTP -description: As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller - Impersonation (CVE-2021-42287) exploitation chain, adversaries need to create a - new computer account name and rename it to match the name of a domain controller - account without the ending '$'. In Windows Active Directory environments, computer - account names always end with `$`. This analytic leverages Event Id 4781, `The name - of an account was changed`, to identify a computer account rename event with a suspicious - name that does not terminate with `$`. This behavior could represent an exploitation - attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation. +description: The following analytic detects a suspicious computer account name change + in Active Directory. It leverages Event ID 4781, which logs account name changes, + to identify instances where a computer account name is changed to one that does + not end with a `$`. This behavior is significant as it may indicate an attempt to + exploit CVE-2021-42278 and CVE-2021-42287, which can lead to domain controller impersonation + and privilege escalation. If confirmed malicious, this activity could allow an attacker + to gain elevated privileges and potentially control the domain. data_source: - Windows Event Log Security 4781 search: '`wineventlog_security` EventCode=4781 OldTargetUserName="*$" NewTargetUserName!="*$" - | table _time, Computer, Caller_User_Name, OldTargetUserName, NewTargetUserName | rename Computer as dest | - `suspicious_computer_account_name_change_filter`' + | table _time, Computer, Caller_User_Name, OldTargetUserName, NewTargetUserName + | rename Computer as dest | `suspicious_computer_account_name_change_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: Renaming a computer account name to a name that not end with @@ -66,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/suspicious_computer_account_name_change/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/suspicious_computer_account_name_change/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/suspicious_copy_on_system32.yml b/detections/endpoint/suspicious_copy_on_system32.yml index 5d3e835aa6..bb76235f6b 100644 --- a/detections/endpoint/suspicious_copy_on_system32.yml +++ b/detections/endpoint/suspicious_copy_on_system32.yml @@ -1,15 +1,18 @@ name: Suspicious Copy on System32 id: ce633e56-25b2-11ec-9e76-acde48001122 -version: 1 -date: '2023-08-17' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious copy of file from systemroot - folder of the windows OS. This technique is commonly used by APT or other malware - as part of execution (LOLBIN) to run its malicious code using the available legitimate - tool in OS. this type of event may seen or may execute of normal user in some instance - but this is really a anomaly that needs to be check within the network. +description: The following analytic detects suspicious file copy operations from the + System32 or SysWow64 directories, often indicative of malicious activity. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on processes initiated + by command-line tools like cmd.exe or PowerShell. This behavior is significant as + it may indicate an attempt to execute malicious code using legitimate system tools + (LOLBIN). If confirmed malicious, this activity could allow an attacker to execute + arbitrary code, potentially leading to system compromise or further lateral movement + within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/copy_sysmon/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/copy_sysmon/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_curl_network_connection.yml b/detections/endpoint/suspicious_curl_network_connection.yml index e290f57b00..f4a1e56f14 100644 --- a/detections/endpoint/suspicious_curl_network_connection.yml +++ b/detections/endpoint/suspicious_curl_network_connection.yml @@ -1,14 +1,18 @@ name: Suspicious Curl Network Connection id: 3f613dc0-21f2-4063-93b1-5d3c15eef22f -version: 1 -date: '2021-02-22' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: experimental type: TTP -description: The following analytic identifies the use of a curl contacting suspicious - remote domains to checkin to Command And Control servers or download further implants. - In the context of Silver Sparrow, curl is identified contacting s3.amazonaws.com. - This particular behavior is common with MacOS adware-malicious software. +description: The following analytic detects the use of the curl command contacting + suspicious remote domains, such as s3.amazonaws.com, which is indicative of Command + and Control (C2) activity or downloading further implants. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs and command-line arguments. This activity is significant as it may indicate + the presence of MacOS adware or other malicious software attempting to establish + persistence or exfiltrate data. If confirmed malicious, this could allow attackers + to maintain control over the compromised system and deploy additional payloads. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/suspicious_dllhost_no_command_line_arguments.yml b/detections/endpoint/suspicious_dllhost_no_command_line_arguments.yml index b7b30feef0..e3b117d33e 100644 --- a/detections/endpoint/suspicious_dllhost_no_command_line_arguments.yml +++ b/detections/endpoint/suspicious_dllhost_no_command_line_arguments.yml @@ -1,16 +1,18 @@ name: Suspicious DLLHost no Command Line Arguments id: ff61e98c-0337-4593-a78f-72a676c56f26 -version: 4 -date: '2023-07-10' +version: 5 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies DLLHost.exe with no command line arguments. - It is unusual for DLLHost.exe to execute with no command line arguments present. - This particular behavior is common with malicious software, including Cobalt Strike. - During investigation, identify any network connections and parallel processes. Identify - any suspicious module loads related to credential dumping or file writes. DLLHost.exe - is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects instances of DLLHost.exe executing without + command line arguments. This behavior is unusual and often associated with malicious + activities, such as those performed by Cobalt Strike. The detection leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs. This activity is significant because DLLHost.exe typically requires arguments + to function correctly, and its absence may indicate an attempt to evade detection. + If confirmed malicious, this could lead to unauthorized actions like credential + dumping or file manipulation, posing a severe threat to the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_driver_loaded_path.yml b/detections/endpoint/suspicious_driver_loaded_path.yml index 62a51ed660..0b866e2df3 100644 --- a/detections/endpoint/suspicious_driver_loaded_path.yml +++ b/detections/endpoint/suspicious_driver_loaded_path.yml @@ -1,25 +1,25 @@ name: Suspicious Driver Loaded Path id: f880acd4-a8f1-11eb-a53b-acde48001122 -version: 1 -date: '2021-04-29' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will detect suspicious driver loaded paths. This technique - is commonly used by malicious software like coin miners (xmrig) to register its - malicious driver from notable directories where executable or drivers do not commonly - exist. During triage, validate this driver is for legitimate business use. Review - the metadata and certificate information. Unsigned drivers from non-standard paths - is not normal, but occurs. In addition, review driver loads into `ntoskrnl.exe` - for possible other drivers of interest. Long tail analyze drivers by path (outside - of default, and in default) for further review. +description: The following analytic detects the loading of drivers from suspicious + paths, which is a technique often used by malicious software such as coin miners + (e.g., xmrig). It leverages Sysmon EventCode 6 to identify drivers loaded from non-standard + directories. This activity is significant because legitimate drivers typically reside + in specific system directories, and deviations may indicate malicious activity. + If confirmed malicious, this could allow an attacker to execute code at the kernel + level, potentially leading to privilege escalation, persistence, or further system + compromise. data_source: - Sysmon EventID 6 search: '`sysmon` EventCode=6 ImageLoaded = "*.sys" NOT (ImageLoaded IN("*\\WINDOWS\\inf","*\\WINDOWS\\System32\\drivers\\*", "*\\WINDOWS\\System32\\DriverStore\\FileRepository\\*")) | stats min(_time) as firstTime max(_time) as lastTime count by dest ImageLoaded Hashes IMPHASH Signature - Signed| rename ImageLoaded as file_name | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `suspicious_driver_loaded_path_filter`' + Signed| rename ImageLoaded as file_name | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `suspicious_driver_loaded_path_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the driver loaded and Signature from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_event_log_service_behavior.yml b/detections/endpoint/suspicious_event_log_service_behavior.yml index d45748592d..28ca08176e 100644 --- a/detections/endpoint/suspicious_event_log_service_behavior.yml +++ b/detections/endpoint/suspicious_event_log_service_behavior.yml @@ -1,21 +1,21 @@ name: Suspicious Event Log Service Behavior id: 2b85aa3d-f5f6-4c2e-a081-a09f6e1c2e40 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: Hunting -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. +description: The following analytic detects the shutdown of the Windows Event Log + service using Windows Event ID 1100. This event is logged every time the service + stops, including during normal system shutdowns. Monitoring this activity is crucial + as it can indicate attempts to cover tracks or disable logging. If confirmed malicious, + an attacker could hide their activities, making it difficult to trace their actions + and investigate further incidents. Analysts should verify if the shutdown was planned + and review other alerts and data sources for additional suspicious behavior. data_source: - Windows Event Log Security 1100 -search: '(`wineventlog_security` EventCode=1100) | stats count min(_time) as firstTime max(_time) as lastTime by dest name EventCode - | `security_content_ctime(firstTime)` +search: '(`wineventlog_security` EventCode=1100) | stats count min(_time) as firstTime + max(_time) as lastTime by dest name 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. @@ -56,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/suspicious_event_log_service_behavior/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/suspicious_event_log_service_behavior/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/suspicious_gpupdate_no_command_line_arguments.yml b/detections/endpoint/suspicious_gpupdate_no_command_line_arguments.yml index fc713c1e09..577c14d002 100644 --- a/detections/endpoint/suspicious_gpupdate_no_command_line_arguments.yml +++ b/detections/endpoint/suspicious_gpupdate_no_command_line_arguments.yml @@ -1,16 +1,18 @@ name: Suspicious GPUpdate no Command Line Arguments id: f308490a-473a-40ef-ae64-dd7a6eba284a -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies gpupdate.exe with no command line arguments. - It is unusual for gpupdate.exe to execute with no command line arguments present. - This particular behavior is common with malicious software, including Cobalt Strike. - During investigation, identify any network connections and parallel processes. Identify - any suspicious module loads related to credential dumping or file writes. gpupdate.exe - is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects the execution of gpupdate.exe without + any command line arguments. This behavior is identified using data from Endpoint + Detection and Response (EDR) agents, focusing on process execution logs. It is significant + because gpupdate.exe typically runs with specific arguments, and its execution without + them is often associated with malicious activities, such as those performed by Cobalt + Strike. If confirmed malicious, this activity could indicate an attempt to execute + unauthorized commands or scripts, potentially leading to further system compromise + or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_icedid_rundll32_cmdline.yml b/detections/endpoint/suspicious_icedid_rundll32_cmdline.yml index b42a10a684..0623f65c76 100644 --- a/detections/endpoint/suspicious_icedid_rundll32_cmdline.yml +++ b/detections/endpoint/suspicious_icedid_rundll32_cmdline.yml @@ -1,13 +1,17 @@ name: Suspicious IcedID Rundll32 Cmdline id: bed761f8-ee29-11eb-8bf3-acde48001122 -version: 2 -date: '2021-07-26' +version: 3 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious rundll32.exe commandline to execute - dll file. This technique was seen in IcedID malware to load its payload dll with - the following parameter to load encrypted dll payload which is the license.dat. +description: The following analytic detects a suspicious `rundll32.exe` command line + used to execute a DLL file, a technique associated with IcedID malware. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions containing the pattern `*/i:*`. This activity is significant as it indicates + potential malware attempting to load an encrypted DLL payload, often named `license.dat`. + If confirmed malicious, this could allow attackers to execute arbitrary code, leading + to further system compromise and potential data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/inf_icedid/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_image_creation_in_appdata_folder.yml b/detections/endpoint/suspicious_image_creation_in_appdata_folder.yml index 759afebf28..efed22edca 100644 --- a/detections/endpoint/suspicious_image_creation_in_appdata_folder.yml +++ b/detections/endpoint/suspicious_image_creation_in_appdata_folder.yml @@ -1,16 +1,18 @@ name: Suspicious Image Creation In Appdata Folder id: f6f904c4-1ac0-11ec-806b-acde48001122 -version: 2 -date: '2022-07-07' +version: 3 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious creation of image in appdata folder - made by process that also has a file reference in appdata folder. This technique - was seen in remcos rat that capture screenshot of the compromised machine and place - it in the appdata and will be send to its C2 server. This TTP is really a good indicator - to check that process because it is in suspicious folder path and image files are - not commonly created by user in this folder path. +description: The following analytic detects the creation of image files in the AppData + folder by processes that also have a file reference in the same folder. It leverages + data from the Endpoint.Processes and Endpoint.Filesystem datamodels to identify + this behavior. This activity is significant because it is commonly associated with + malware, such as the Remcos RAT, which captures screenshots and stores them in the + AppData folder before exfiltrating them to a command-and-control server. If confirmed + malicious, this activity could indicate unauthorized data capture and exfiltration, + compromising sensitive information and user privacy. data_source: - Sysmon EventID 1 - Sysmon EventID 11 @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_kerberos_service_ticket_request.yml b/detections/endpoint/suspicious_kerberos_service_ticket_request.yml index 74b75829a8..e1a1d54d94 100644 --- a/detections/endpoint/suspicious_kerberos_service_ticket_request.yml +++ b/detections/endpoint/suspicious_kerberos_service_ticket_request.yml @@ -1,26 +1,24 @@ name: Suspicious Kerberos Service Ticket Request id: 8b1297bc-6204-11ec-b7c4-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-16' author: Mauricio Velazco, Splunk status: production type: TTP -description: As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller - Impersonation (CVE-2021-42287) exploitation chain, adversaries will request and - obtain a Kerberos Service Ticket (TGS) with a domain controller computer account - as the Service Name. This Service Ticket can be then used to take control of the - domain controller on the final part of the attack. This analytic leverages Event - Id 4769, `A Kerberos service ticket was requested`, to identify an unusual TGS request - where the Account_Name requesting the ticket matches the Service_Name field. This - behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 - for privilege escalation. +description: The following analytic detects suspicious Kerberos Service Ticket (TGS) + requests where the requesting account name matches the service name, potentially + indicating an exploitation attempt of CVE-2021-42278 and CVE-2021-42287. This detection + leverages Event ID 4769 from Domain Controller and Kerberos events. Such activity + is significant as it may represent an adversary attempting to escalate privileges + by impersonating a domain controller. If confirmed malicious, this could allow an + attacker to take control of the domain controller, leading to complete domain compromise + and unauthorized access to sensitive information. data_source: - Windows Event Log Security 4769 -search: ' `wineventlog_security` EventCode=4769 - | eval isSuspicious = if(lower(ServiceName) = lower(mvindex(split(TargetUserName,"@"),0)),1,0) - | where isSuspicious = 1 | rename Computer as dest| rename TargetUserName as user - | table _time, dest, src_ip, user, ServiceName, Error_Code, isSuspicious - | `suspicious_kerberos_service_ticket_request_filter`' +search: ' `wineventlog_security` EventCode=4769 | eval isSuspicious = if(lower(ServiceName) + = lower(mvindex(split(TargetUserName,"@"),0)),1,0) | where isSuspicious = 1 | rename + Computer as dest| rename TargetUserName as user | table _time, dest, src_ip, user, + ServiceName, Error_Code, isSuspicious | `suspicious_kerberos_service_ticket_request_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -68,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/suspicious_kerberos_service_ticket_request/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/suspicious_kerberos_service_ticket_request/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/suspicious_linux_discovery_commands.yml b/detections/endpoint/suspicious_linux_discovery_commands.yml index f3bd714ed1..b1d9d22a6d 100644 --- a/detections/endpoint/suspicious_linux_discovery_commands.yml +++ b/detections/endpoint/suspicious_linux_discovery_commands.yml @@ -1,17 +1,18 @@ name: Suspicious Linux Discovery Commands id: 0edd5112-56c9-11ec-b990-acde48001122 -version: 1 -date: '2021-12-06' +version: 2 +date: '2024-05-11' author: Bhavin Patel, Splunk status: production type: TTP -description: 'This search, detects execution of suspicious bash commands from various - commonly leveraged bash scripts like (AutoSUID, LinEnum, LinPeas) to perform discovery - of possible paths of privilege execution, password files, vulnerable directories, - executables and file permissions on a Linux host. - - The search logic specifically looks for high number of distinct commands run in - a short period of time.' +description: 'The following analytic detects the execution of suspicious bash commands + commonly used in scripts like AutoSUID, LinEnum, and LinPeas for system discovery + on a Linux host. It leverages Endpoint Detection and Response (EDR) data, specifically + looking for a high number of distinct commands executed within a short time frame. + This activity is significant as it often precedes privilege escalation or other + malicious actions. If confirmed malicious, an attacker could gain detailed system + information, identify vulnerabilities, and potentially escalate privileges, posing + a severe threat to the environment.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -68,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.004/linux_discovery_tools/sysmon_linux.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.004/linux_discovery_tools/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/suspicious_microsoft_workflow_compiler_rename.yml b/detections/endpoint/suspicious_microsoft_workflow_compiler_rename.yml index 8ae1e54f4c..48390203df 100644 --- a/detections/endpoint/suspicious_microsoft_workflow_compiler_rename.yml +++ b/detections/endpoint/suspicious_microsoft_workflow_compiler_rename.yml @@ -1,16 +1,17 @@ name: Suspicious microsoft workflow compiler rename id: f0db4464-55d9-11eb-ae93-0242ac130002 -version: 5 -date: '2023-11-07' +version: 6 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies a renamed instance of microsoft.workflow.compiler.exe. - Microsoft.workflow.compiler.exe is natively found in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 - and is rarely utilized. When investigating, identify the executed code on disk and - review. A spawned child process from microsoft.workflow.compiler.exe is uncommon. - In any instance, microsoft.workflow.compiler.exe spawning from an Office product - or any living off the land binary is highly suspect. +description: The following analytic detects the renaming of microsoft.workflow.compiler.exe, + a rarely used executable typically located in C:\Windows\Microsoft.NET\Framework64\v4.0.30319. + This detection leverages Endpoint Detection and Response (EDR) data, focusing on + process names and original file names. This activity is significant because renaming + this executable can indicate an attempt to evade security controls. If confirmed + malicious, an attacker could use this renamed executable to execute arbitrary code, + potentially leading to privilege escalation or persistent access within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_msbuild_path.yml b/detections/endpoint/suspicious_msbuild_path.yml index cf48600521..8ce76cd24a 100644 --- a/detections/endpoint/suspicious_msbuild_path.yml +++ b/detections/endpoint/suspicious_msbuild_path.yml @@ -1,15 +1,17 @@ name: Suspicious msbuild path id: f5198224-551c-11eb-ae93-0242ac130002 -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies msbuild.exe executing from a non-standard - path. Msbuild.exe is natively found in C:\Windows\Microsoft.NET\Framework\v4.0.30319 - and C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Instances of Visual Studio - will run a copy of msbuild.exe. A moved instance of MSBuild is suspicious, however - there are instances of build applications that will move or use a copy of MSBuild. +description: The following analytic detects the execution of msbuild.exe from a non-standard + path. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process execution logs that deviate from typical msbuild.exe locations. This + activity is significant because msbuild.exe is commonly abused by attackers to execute + malicious code, and running it from an unusual path can indicate an attempt to evade + detection. If confirmed malicious, this behavior could allow an attacker to execute + arbitrary code, potentially leading to system compromise and further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -82,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/suspicious_msbuild_spawn.yml b/detections/endpoint/suspicious_msbuild_spawn.yml index 738730004d..2effe22e78 100644 --- a/detections/endpoint/suspicious_msbuild_spawn.yml +++ b/detections/endpoint/suspicious_msbuild_spawn.yml @@ -1,17 +1,18 @@ name: Suspicious MSBuild Spawn id: a115fba6-5514-11eb-ae93-0242ac130002 -version: 2 -date: '2021-01-12' +version: 3 +date: '2024-05-30' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies wmiprvse.exe spawning msbuild.exe. - This behavior is indicative of a COM object being utilized to spawn msbuild from - wmiprvse.exe. It is common for MSBuild.exe to be spawned from devenv.exe while using - Visual Studio. In this instance, there will be command line arguments and file paths. - In a malicious instance, MSBuild.exe will spawn from non-standard processes and - have no command line arguments. For example, MSBuild.exe spawning from explorer.exe, - powershell.exe is far less common and should be investigated. +description: The following analytic identifies instances where wmiprvse.exe spawns + msbuild.exe, which is unusual and indicative of potential misuse of a COM object. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process relationships and command-line executions. This activity is + significant because msbuild.exe is typically spawned by devenv.exe during legitimate + Visual Studio use, not by wmiprvse.exe. If confirmed malicious, this behavior could + indicate an attacker executing arbitrary code or scripts, potentially leading to + system compromise or further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -76,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/suspicious_mshta_child_process.yml b/detections/endpoint/suspicious_mshta_child_process.yml index 96fd1ea214..8590a0251f 100644 --- a/detections/endpoint/suspicious_mshta_child_process.yml +++ b/detections/endpoint/suspicious_mshta_child_process.yml @@ -1,14 +1,18 @@ name: Suspicious mshta child process id: 60023bb6-5500-11eb-ae93-0242ac130002 -version: 2 -date: '2024-01-01' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies child processes spawning from "mshta.exe". - The search will return the first time and last time these command-line arguments - were used for these executions, as well as the target system, the user, parent process - "mshta.exe" and its child process. +description: The following analytic identifies child processes spawned from "mshta.exe". + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + specific child processes like "powershell.exe" and "cmd.exe". This activity is significant + because "mshta.exe" is often exploited by attackers to execute malicious scripts + or commands. If confirmed malicious, this behavior could allow an attacker to execute + arbitrary code, escalate privileges, or maintain persistence within the environment. + Monitoring this activity helps in early detection of potential threats leveraging + "mshta.exe" for malicious purposes. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -76,7 +80,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/suspicious_plistbuddy_usage.yml b/detections/endpoint/suspicious_plistbuddy_usage.yml index f918a9be77..336f2ba446 100644 --- a/detections/endpoint/suspicious_plistbuddy_usage.yml +++ b/detections/endpoint/suspicious_plistbuddy_usage.yml @@ -1,28 +1,18 @@ name: Suspicious PlistBuddy Usage id: c3194009-e0eb-4f84-87a9-4070f8688f00 -version: 1 -date: '2021-02-22' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: experimental type: TTP -description: 'The following analytic identifies the use of a native MacOS utility, - PlistBuddy, creating or modifying a properly list (.plist) file. In the instance - of Silver Sparrow, the following commands were executed: - - * PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist - - Upon triage, capture the property list file being written to disk and review for - further indicators. Contain the endpoint and triage further.' +description: 'The following analytic identifies the use of the native macOS utility, + PlistBuddy, to create or modify property list (.plist) files. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and command-line executions involving PlistBuddy. This activity is significant because + PlistBuddy can be used to establish persistence by modifying LaunchAgents, as seen + in the Silver Sparrow malware. If confirmed malicious, this could allow an attacker + to maintain persistence, execute arbitrary commands, and potentially escalate privileges + on the compromised macOS system.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/suspicious_plistbuddy_usage_via_osquery.yml b/detections/endpoint/suspicious_plistbuddy_usage_via_osquery.yml index cb9f22d400..abeb9ae75c 100644 --- a/detections/endpoint/suspicious_plistbuddy_usage_via_osquery.yml +++ b/detections/endpoint/suspicious_plistbuddy_usage_via_osquery.yml @@ -1,28 +1,18 @@ name: Suspicious PlistBuddy Usage via OSquery id: 20ba6c32-c733-4a32-b64e-2688cf231399 -version: 1 -date: '2021-02-22' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: experimental type: TTP -description: 'The following analytic identifies the use of a native MacOS utility, - PlistBuddy, creating or modifying a properly list (.plist) file. In the instance - of Silver Sparrow, the following commands were executed: - - * PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist - - * PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist - - Upon triage, capture the property list file being written to disk and review for - further indicators. Contain the endpoint and triage further.' +description: 'The following analytic detects the use of the PlistBuddy utility on + macOS to create or modify property list (.plist) files. It leverages OSQuery to + monitor process events, specifically looking for commands that interact with LaunchAgents + and set properties like RunAtLoad. This activity is significant because PlistBuddy + can be used to establish persistence mechanisms, as seen in malware like Silver + Sparrow. If confirmed malicious, this could allow an attacker to maintain persistence, + execute arbitrary commands, and potentially escalate privileges on the compromised + system.' data_source: [] search: '`osquery_process` "columns.cmdline"="*LaunchAgents*" OR "columns.cmdline"="*RunAtLoad*" OR "columns.cmdline"="*true*" | `suspicious_plistbuddy_usage_via_osquery_filter`' diff --git a/detections/endpoint/suspicious_process_dns_query_known_abuse_web_services.yml b/detections/endpoint/suspicious_process_dns_query_known_abuse_web_services.yml index 5d11c5ab85..a743b438b9 100644 --- a/detections/endpoint/suspicious_process_dns_query_known_abuse_web_services.yml +++ b/detections/endpoint/suspicious_process_dns_query_known_abuse_web_services.yml @@ -1,25 +1,25 @@ name: Suspicious Process DNS Query Known Abuse Web Services id: 3cf0dc36-484d-11ec-a6bc-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects a suspicious process making a DNS query via known, - abused text-paste web services, VoIP, instant messaging, and digital distribution - platforms used to download external files. This technique is abused by adversaries, - malware actors, and red teams to download a malicious file on the target host. This - is a good TTP indicator for possible initial access techniques. A user will experience - false positives if the following instant messaging is allowed or common applications - like telegram or discord are allowed in the corporate network. +description: The following analytic detects a suspicious process making DNS queries + to known, abused text-paste web services, VoIP, instant messaging, and digital distribution + platforms. It leverages Sysmon Event ID 22 logs to identify queries from processes + like cmd.exe, powershell.exe, and others. This activity is significant as it may + indicate an attempt to download malicious files, a common initial access technique. + If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, + or further compromise of the target host. data_source: - Sysmon EventID 22 -search: '`sysmon` EventCode=22 QueryName IN ("*pastebin*", "*discord*", "*api.telegram*","*t.me*") - process_name IN ("cmd.exe", "*powershell*", "pwsh.exe", "wscript.exe","cscript.exe") OR Image IN ("*\\users\\public\\*", "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") - | stats count min(_time) as firstTime max(_time) as lastTime by Image QueryName QueryStatus process_name QueryResults Computer - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`sysmon` EventCode=22 QueryName IN ("*pastebin*", "*discord*", "*api.telegram*","*t.me*") + process_name IN ("cmd.exe", "*powershell*", "pwsh.exe", "wscript.exe","cscript.exe") + OR Image IN ("*\\users\\public\\*", "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", + "*\\appdata\\*", "*\\perflogs\\*") | stats count min(_time) as firstTime max(_time) + as lastTime by Image QueryName QueryStatus process_name QueryResults Computer | + rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `suspicious_process_dns_query_known_abuse_web_services_filter`' how_to_implement: This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days. @@ -69,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_pastebin_download/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_pastebin_download/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_process_executed_from_container_file.yml b/detections/endpoint/suspicious_process_executed_from_container_file.yml index 1ae1800a59..61a49ede77 100644 --- a/detections/endpoint/suspicious_process_executed_from_container_file.yml +++ b/detections/endpoint/suspicious_process_executed_from_container_file.yml @@ -1,15 +1,17 @@ name: Suspicious Process Executed From Container File id: d8120352-3b62-411c-8cb6-7b47584dd5e8 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-09' author: Steven Dick status: production type: TTP -description: This analytic identifies a suspicious process spawned by another process - from within common container/archive file types. This technique was a common technique - used by adversaries and malware to execute scripts or evade defenses. This TTP may - detect some normal software installation or user behaviors where opening archive - files is common. +description: The following analytic identifies a suspicious process executed from + within common container/archive file types such as ZIP, ISO, IMG, and others. It + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + names and command-line executions. This activity is significant as it is a common + technique used by adversaries to execute scripts or evade defenses. If confirmed + malicious, this behavior could allow attackers to execute arbitrary code, escalate + privileges, or persist within the environment, posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -74,6 +76,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_process_file_path.yml b/detections/endpoint/suspicious_process_file_path.yml index 8dbc5bdeed..838a902c60 100644 --- a/detections/endpoint/suspicious_process_file_path.yml +++ b/detections/endpoint/suspicious_process_file_path.yml @@ -1,18 +1,18 @@ name: Suspicious Process File Path id: 9be25988-ad82-11eb-a14f-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies a suspicious processes running in file paths - that are not typically associated with legitimate software. Adversaries often employ - this technique to drop and execute malicious executables in accessible locations - that do not require administrative privileges. By monitoring for processes running - in such unconventional file paths, we can identify potential indicators of compromise - and proactively respond to malicious activity. This analytic plays a crucial role - in enhancing system security by pinpointing suspicious behaviors commonly associated - with malware and unauthorized software execution. +description: The following analytic identifies processes running from file paths not + typically associated with legitimate software. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on specific process paths within the Endpoint + data model. This activity is significant because adversaries often use unconventional + file paths to execute malicious code without requiring administrative privileges. + If confirmed malicious, this behavior could indicate an attempt to bypass security + controls, leading to unauthorized software execution, potential system compromise, + and further malicious activities within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -110,6 +110,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/xmrig_miner/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_process_with_discord_dns_query.yml b/detections/endpoint/suspicious_process_with_discord_dns_query.yml index bebfbca672..a307238a63 100644 --- a/detections/endpoint/suspicious_process_with_discord_dns_query.yml +++ b/detections/endpoint/suspicious_process_with_discord_dns_query.yml @@ -1,22 +1,24 @@ name: Suspicious Process With Discord DNS Query id: 4d4332ae-792c-11ec-89c1-acde48001122 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-16' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: Anomaly -description: This analytic identifies a process making a DNS query to Discord, a well - known instant messaging and digital distribution platform. Discord can be abused - by adversaries, as seen in the WhisperGate campaign, to host and download malicious. - external files. A process resolving a Discord DNS name could be an indicator of - malware trying to download files from Discord for further execution. +description: The following analytic identifies a process making a DNS query to Discord, + excluding legitimate Discord application paths. It leverages Sysmon logs with Event + ID 22 to detect DNS queries containing "discord" in the QueryName field. This activity + is significant because Discord can be abused by adversaries to host and download + malicious files, as seen in the WhisperGate campaign. If confirmed malicious, this + could indicate malware attempting to download additional payloads from Discord, + potentially leading to further code execution and compromise of the affected system. data_source: - Sysmon EventID 22 search: '`sysmon` EventCode=22 QueryName IN ("*discord*") Image != "*\\AppData\\Local\\Discord\\*" AND Image != "*\\Program Files*" AND Image != "discord.exe" | stats count min(_time) as firstTime max(_time) as lastTime by Image QueryName QueryStatus process_name - QueryResults Computer | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `suspicious_process_with_discord_dns_query_filter`' + QueryResults Computer | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `suspicious_process_with_discord_dns_query_filter`' how_to_implement: his detection relies on sysmon logs with the Event ID 22, DNS Query. known_false_positives: Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is @@ -62,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/discord_dnsquery/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/discord_dnsquery/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_reg_exe_process.yml b/detections/endpoint/suspicious_reg_exe_process.yml index a71c958027..5f33d5b64c 100644 --- a/detections/endpoint/suspicious_reg_exe_process.yml +++ b/detections/endpoint/suspicious_reg_exe_process.yml @@ -25,7 +25,7 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime where Processes.parent_process_name=cmd.exe Processes.process_name= reg.exe by Processes.parent_process_id Processes.dest Processes.process_name | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename parent_process_id as process_id |dedup - process_id| table process_id dest] | `suspicious_reg_exe_process_filter` ' + process_id| table process_id dest] | `suspicious_reg_exe_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/endpoint/suspicious_regsvr32_register_suspicious_path.yml b/detections/endpoint/suspicious_regsvr32_register_suspicious_path.yml index 93d52eec1b..76158d6124 100644 --- a/detections/endpoint/suspicious_regsvr32_register_suspicious_path.yml +++ b/detections/endpoint/suspicious_regsvr32_register_suspicious_path.yml @@ -1,23 +1,27 @@ name: Suspicious Regsvr32 Register Suspicious Path id: 62732736-6250-11eb-ae93-0242ac130002 -version: 3 -date: '2023-03-02' +version: 4 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -description: Adversaries may abuse Regsvr32.exe to proxy execution of malicious code - by using non-standard file extensions to load DLLs. Upon investigating, look for - network connections to remote destinations (internal or external). Review additional - parrallel processes and child processes for additional activity. +description: The following analytic detects the use of Regsvr32.exe to register DLLs + from suspicious paths such as AppData, ProgramData, or Windows Temp directories. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process execution logs and command-line arguments. This activity is significant + because Regsvr32.exe can be abused to proxy execution of malicious code, bypassing + traditional security controls. If confirmed malicious, this could allow an attacker + to execute arbitrary code, potentially leading to system compromise, data exfiltration, + or further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_regsvr32` Processes.process IN ("*\\appdata\\*", "*\\programdata\\*","*\\windows\\temp\\*") NOT (Processes.process - IN ("*.dll*", "*.ax*", "*.ocx*")) by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.process Processes.original_file_name Processes.process_id - Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `suspicious_regsvr32_register_suspicious_path_filter`' + IN ("*.dll*", "*.ax*", "*.ocx*")) by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.original_file_name + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `suspicious_regsvr32_register_suspicious_path_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -89,6 +93,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.010/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.010/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_rundll32_dllregisterserver.yml b/detections/endpoint/suspicious_rundll32_dllregisterserver.yml index 99638fd769..c5697dbc90 100644 --- a/detections/endpoint/suspicious_rundll32_dllregisterserver.yml +++ b/detections/endpoint/suspicious_rundll32_dllregisterserver.yml @@ -1,25 +1,25 @@ name: Suspicious Rundll32 dllregisterserver id: 8c00a385-9b86-4ac0-8932-c9ec3713b159 -version: 2 -date: '2021-02-09' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe using dllregisterserver - on the command line to load a DLL. When a DLL is registered, the DllRegisterServer - method entry point in the DLL is invoked. This is typically seen when a DLL is being - registered on the system. Not every instance is considered malicious, but it will - capture malicious use of it. During investigation, review the parent process and - parrellel processes executing. Capture the DLL being loaded and inspect further. - Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects the execution of rundll32.exe with the + DllRegisterServer command to load a DLL. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions and process details. + This activity is significant as it may indicate an attempt to register a malicious + DLL, which can be a method for code execution or persistence. If confirmed malicious, + an attacker could gain unauthorized code execution, escalate privileges, or maintain + persistence within the environment, posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_rundll32` Processes.process=*dllregisterserver* - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.original_file_name - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `suspicious_rundll32_dllregisterserver_filter`' + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.original_file_name Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `suspicious_rundll32_dllregisterserver_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -92,6 +92,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_rundll32_no_command_line_arguments.yml b/detections/endpoint/suspicious_rundll32_no_command_line_arguments.yml index 969e0ab100..c765ae417e 100644 --- a/detections/endpoint/suspicious_rundll32_no_command_line_arguments.yml +++ b/detections/endpoint/suspicious_rundll32_no_command_line_arguments.yml @@ -1,16 +1,18 @@ name: Suspicious Rundll32 no Command Line Arguments id: e451bd16-e4c5-4109-8eb1-c4c6ecf048b4 -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe with no command line arguments. - It is unusual for rundll32.exe to execute with no command line arguments present. - This particular behavior is common with malicious software, including Cobalt Strike. - During investigation, identify any network connections and parallel processes. Identify - any suspicious module loads related to credential dumping or file writes. Rundll32.exe - is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description: The following analytic detects the execution of rundll32.exe without + any command line arguments. This behavior is identified using Endpoint Detection + and Response (EDR) telemetry, focusing on process execution logs. It is significant + because rundll32.exe typically requires command line arguments to function properly, + and its absence is often associated with malicious activities, such as those performed + by Cobalt Strike. If confirmed malicious, this activity could indicate an attempt + to execute arbitrary code, potentially leading to credential dumping, unauthorized + file writes, or other malicious actions. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -82,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_rundll32_startw.yml b/detections/endpoint/suspicious_rundll32_startw.yml index 0aa084d7ab..f8b24376d3 100644 --- a/detections/endpoint/suspicious_rundll32_startw.yml +++ b/detections/endpoint/suspicious_rundll32_startw.yml @@ -1,19 +1,18 @@ name: Suspicious Rundll32 StartW id: 9319dda5-73f2-4d43-a85a-67ce961bddb7 -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-30' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies rundll32.exe executing a DLL function - name, Start and StartW, on the command line that is commonly observed with Cobalt - Strike x86 and x64 DLL payloads. Rundll32.exe is natively found in C:\Windows\system32 - and C:\Windows\syswow64. Typically, the DLL will be written and loaded from a world - writeable path or user location. In most instances it will not have a valid certificate - (Unsigned). During investigation, review the parent process and other parallel application - execution. Capture and triage the DLL in question. In the instance of Cobalt Strike, - rundll32.exe is the default process it opens and injects shellcode into. This default - process can be changed, but typically is not. +description: The following analytic identifies the execution of rundll32.exe with + the DLL function names "Start" and "StartW," commonly associated with Cobalt Strike + payloads. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on command-line executions and process metadata. This activity + is significant as it often indicates the presence of malicious payloads, such as + Cobalt Strike, which can lead to unauthorized code execution. If confirmed malicious, + this activity could allow attackers to inject shellcode, escalate privileges, and + maintain persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml b/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml index 2e40561e9c..230691fe2e 100644 --- a/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml +++ b/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml @@ -1,21 +1,18 @@ name: Suspicious Scheduled Task from Public Directory id: 7feb7972-7ac3-11eb-bac8-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Anomaly -description: 'The following analytic, "Suspicious Scheduled Task from Public Directory", - detects the registration of scheduled tasks aimed to execute a binary or script - from public directories, a behavior often associated with malware deployment. It - utilizes the Sysmon EventID 1 data source, searching for instances where schtasks.exe - is connected with the directories users\public, \programdata\, or \windows\temp - and involves the /create command. - - The registration of such scheduled tasks in public directories could suggest that - an attacker is trying to maintain persistence or execute malicious scripts. If confirmed - as a true positive, this could lead to data compromise, unauthorized access, and - potential lateral movement within the network.' +description: 'The following analytic identifies the creation of scheduled tasks that + execute binaries or scripts from public directories, such as users\public, \programdata\, + or \windows\temp, using schtasks.exe with the /create command. It leverages Sysmon + Event ID 1 data to detect this behavior. This activity is significant because it + often indicates an attempt to maintain persistence or execute malicious scripts, + which are common tactics in malware deployment. If confirmed as malicious, this + could lead to data compromise, unauthorized access, and potential lateral movement + within the network.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtasks/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtasks/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_searchprotocolhost_no_command_line_arguments.yml b/detections/endpoint/suspicious_searchprotocolhost_no_command_line_arguments.yml index 13a25f07bc..bbd7412255 100644 --- a/detections/endpoint/suspicious_searchprotocolhost_no_command_line_arguments.yml +++ b/detections/endpoint/suspicious_searchprotocolhost_no_command_line_arguments.yml @@ -1,24 +1,26 @@ name: Suspicious SearchProtocolHost no Command Line Arguments id: f52d2db8-31f9-4aa7-a176-25779effe55c -version: 3 -date: '2023-07-10' +version: 4 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies searchprotocolhost.exe with no command - line arguments. It is unusual for searchprotocolhost.exe to execute with no command - line arguments present. This particular behavior is common with malicious software, - including Cobalt Strike. During investigation, identify any network connections - and parallel processes. Identify any suspicious module loads related to credential - dumping or file writes. searchprotocolhost.exe is natively found in C:\Windows\system32 - and C:\Windows\syswow64. +description: The following analytic detects instances of searchprotocolhost.exe running + without command line arguments. This behavior is unusual and often associated with + malicious activities, such as those performed by Cobalt Strike. The detection leverages + Endpoint Detection and Response (EDR) telemetry, focusing on process execution data. + This activity is significant because searchprotocolhost.exe typically runs with + specific arguments, and its absence may indicate an attempt to evade detection. + If confirmed malicious, this could lead to unauthorized code execution, potential + credential dumping, or other malicious actions within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name=searchprotocolhost.exe by _time span=1h Processes.process_id - Processes.process_name Processes.dest Processes.user Processes.process_path Processes.process Processes.parent_process_name - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | regex process="(?i)(searchprotocolhost\.exe.{0,4}$)" | `suspicious_searchprotocolhost_no_command_line_arguments_filter`' + Processes.process_name Processes.dest Processes.user Processes.process_path Processes.process + Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | regex process="(?i)(searchprotocolhost\.exe.{0,4}$)" + | `suspicious_searchprotocolhost_no_command_line_arguments_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -75,6 +77,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/cobalt_strike/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_sqlite3_lsquarantine_behavior.yml b/detections/endpoint/suspicious_sqlite3_lsquarantine_behavior.yml index 4c87d4a1cf..97e8ce4886 100644 --- a/detections/endpoint/suspicious_sqlite3_lsquarantine_behavior.yml +++ b/detections/endpoint/suspicious_sqlite3_lsquarantine_behavior.yml @@ -1,14 +1,18 @@ name: Suspicious SQLite3 LSQuarantine Behavior id: e1997b2e-655f-4561-82fd-aeba8e1c1a86 -version: 1 -date: '2021-02-22' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: experimental type: TTP -description: The following analytic identifies the use of a SQLite3 querying the MacOS - preferences to identify the original URL the pkg was downloaded from. This particular - behavior is common with MacOS adware-malicious software. Upon triage, review other - processes in parallel for suspicious activity. Identify any recent package installations. +description: The following analytic identifies the use of SQLite3 querying the MacOS + preferences to determine the original URL from which a package was downloaded. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line executions involving LSQuarantine. This activity + is significant as it is commonly associated with MacOS adware and other malicious + software. If confirmed malicious, this behavior could indicate an attempt to track + or manipulate downloaded packages, potentially leading to further system compromise + or persistent adware infections. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/suspicious_ticket_granting_ticket_request.yml b/detections/endpoint/suspicious_ticket_granting_ticket_request.yml index d600e452e6..db115afd9d 100644 --- a/detections/endpoint/suspicious_ticket_granting_ticket_request.yml +++ b/detections/endpoint/suspicious_ticket_granting_ticket_request.yml @@ -1,24 +1,24 @@ name: Suspicious Ticket Granting Ticket Request id: d77d349e-6269-11ec-9cfe-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: production type: Hunting -description: As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller - Impersonation (CVE-2021-42287) exploitation chain, adversaries will need to request - a Kerberos Ticket Granting Ticket (TGT) on behalf of the newly created and renamed - computer account. The TGT request will be preceded by a computer account name event. - This analytic leverages Event Id 4781, `The name of an account was changed` and - event Id 4768 `A Kerberos authentication ticket (TGT) was requested` to correlate - a sequence of events where the new computer account on event id 4781 matches the - request account on event id 4768. This behavior could represent an exploitation - attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation. +description: The following analytic detects suspicious Kerberos Ticket Granting Ticket + (TGT) requests that may indicate exploitation of CVE-2021-42278 and CVE-2021-42287. + It leverages Event ID 4781 (account name change) and Event ID 4768 (TGT request) + to identify sequences where a newly renamed computer account requests a TGT. This + behavior is significant as it could represent an attempt to escalate privileges + by impersonating a Domain Controller. If confirmed malicious, this activity could + allow attackers to gain elevated access and potentially control over the domain + environment. data_source: - Windows Event Log Security 4768 - Windows Event Log Security 4781 search: ' `wineventlog_security` (EventCode=4781 OldTargetUserName="*$" NewTargetUserName!="*$") - OR (EventCode=4768 TargetUserName!="*$") | eval RenamedComputerAccount = coalesce(NewTargetUserName, TargetUserName) | transaction RenamedComputerAccount startswith=(EventCode=4781) + OR (EventCode=4768 TargetUserName!="*$") | eval RenamedComputerAccount = coalesce(NewTargetUserName, + TargetUserName) | transaction RenamedComputerAccount startswith=(EventCode=4781) endswith=(EventCode=4768) | eval short_lived=case((duration<2),"TRUE") | search short_lived = TRUE | table _time, Computer, EventCode, TargetUserName, RenamedComputerAccount, short_lived | rename Computer as dest | `suspicious_ticket_granting_ticket_request_filter`' @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/suspicious_ticket_granting_ticket_request/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/suspicious_ticket_granting_ticket_request/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/suspicious_wav_file_in_appdata_folder.yml b/detections/endpoint/suspicious_wav_file_in_appdata_folder.yml index 252ba206fe..b05b86bfc6 100644 --- a/detections/endpoint/suspicious_wav_file_in_appdata_folder.yml +++ b/detections/endpoint/suspicious_wav_file_in_appdata_folder.yml @@ -1,16 +1,18 @@ name: Suspicious WAV file in Appdata Folder id: 5be109e6-1ac5-11ec-b421-acde48001122 -version: 2 -date: '2022-07-07' +version: 3 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious creation of .wav file in appdata - folder. This behavior was seen in Remcos RAT malware where it put the audio recording - in the appdata\audio folde as part of data collection. this recording can be send - to its C2 server as part of its exfiltration to the compromised machine. creation - of wav files in this folder path is not a ussual disk place used by user to save - audio format file. +description: The following analytic detects the creation of .wav files in the AppData + folder, a behavior associated with Remcos RAT malware, which stores audio recordings + in this location for data exfiltration. The detection leverages endpoint process + and filesystem data to identify .wav file creation within the AppData\Roaming directory. + This activity is significant as it indicates potential unauthorized data collection + and exfiltration by malware. If confirmed malicious, this could lead to sensitive + information being sent to an attacker's command and control server, compromising + the affected system's confidentiality. data_source: - Sysmon EventID 1 - Sysmon EventID 11 @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon_wav.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos_agent/sysmon_wav.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/suspicious_writes_to_windows_recycle_bin.yml b/detections/endpoint/suspicious_writes_to_windows_recycle_bin.yml index a462f82012..defc4d90ed 100644 --- a/detections/endpoint/suspicious_writes_to_windows_recycle_bin.yml +++ b/detections/endpoint/suspicious_writes_to_windows_recycle_bin.yml @@ -1,22 +1,24 @@ name: Suspicious writes to windows Recycle Bin id: b5541828-8ffd-4070-9d95-b3da4de924cb -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-18' author: Rico Valdez, Splunk status: production type: TTP description: |- - The following analytic detects when a process other than explorer.exe writes to the Windows Recycle Bin to detect potential threats earlier and mitigate the risks. This detection is made by a Splunk query that utilizes the Endpoint.Filesystem data model and the Endpoint.Processes data model. The query looks for any process writing to the "*$Recycle.Bin*" file path, excluding explorer.exe. This detection is important because it suggests that an attacker is attempting to hide their activities by using the Recycle Bin, which can lead to data theft, ransomware, or other damaging outcomes. Detecting writes to the Recycle Bin by a process other than explorer.exe can help to investigate and determine if the activity is malicious or benign. False positives might occur since there might be legitimate uses of the Recycle Bin by processes other than explorer.exe. Next steps include reviewing the process writing to the Recycle Bin and any relevant on-disk artifacts upon triage. + The following analytic detects when a process other than explorer.exe writes to the Windows Recycle Bin. It leverages the Endpoint.Filesystem and Endpoint.Processes data models in Splunk to identify any process writing to the "*$Recycle.Bin*" file path, excluding explorer.exe. This activity is significant because it may indicate an attacker attempting to hide their actions, potentially leading to data theft, ransomware, or other malicious outcomes. If confirmed malicious, this behavior could allow an attacker to persist in the environment and evade detection by security tools. data_source: - Sysmon EventID 1 - Sysmon EventID 11 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Filesystem.file_path) as file_path values(Filesystem.file_name) as file_name FROM datamodel=Endpoint.Filesystem where Filesystem.file_path = "*$Recycle.Bin*" by Filesystem.process_name Filesystem.process_id Filesystem.dest - | `drop_dm_object_name("Filesystem")` - | join process_id - [| tstats `security_content_summariesonly` values(Processes.user) as user values(Processes.process_name) as process_name values(Processes.parent_process_name) as parent_process_name FROM datamodel=Endpoint.Processes where Processes.process_name != "explorer.exe" by Processes.process_id Processes.dest - | `drop_dm_object_name("Processes")` - | table user process_name process_id dest] - | `suspicious_writes_to_windows_recycle_bin_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(Filesystem.file_path) as file_path values(Filesystem.file_name) + as file_name FROM datamodel=Endpoint.Filesystem where Filesystem.file_path = "*$Recycle.Bin*" + by Filesystem.process_name Filesystem.process_id Filesystem.dest | `drop_dm_object_name("Filesystem")` + | join process_id [| tstats `security_content_summariesonly` values(Processes.user) + as user values(Processes.process_name) as process_name values(Processes.parent_process_name) + as parent_process_name FROM datamodel=Endpoint.Processes where Processes.process_name + != "explorer.exe" by Processes.process_id Processes.dest | `drop_dm_object_name("Processes")` + | table user process_name process_id dest] | `suspicious_writes_to_windows_recycle_bin_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on filesystem and process logs responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` nodes. @@ -63,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036/write_to_recycle_bin/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036/write_to_recycle_bin/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/svchost_lolbas_execution_process_spawn.yml b/detections/endpoint/svchost_lolbas_execution_process_spawn.yml index eb6ce3401b..f6aa015e9e 100644 --- a/detections/endpoint/svchost_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/svchost_lolbas_execution_process_spawn.yml @@ -1,21 +1,18 @@ name: Svchost LOLBAS Execution Process Spawn id: 09e5c72a-4c0d-11ec-aa29-3e22fbd008af -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-14' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic is designed to spot instances of 'svchost.exe' - initiating a Living Off The Land Binaries and Scripts (LOLBAS) execution process. - Often, adversaries manipulate Task Scheduler to execute code on remote endpoints, - resulting in the spawning of a malicious command as a child process of 'svchost.exe'. - By tracking child processes of 'svchost.exe' that align with the LOLBAS project, - potential lateral movement activity can be detected. The analytic examines process - details, including the process name, parent process, and command-line executions. - A comprehensive list of LOLBAS processes is included in the search parameters. Although - the analytic might catch legitimate applications exhibiting this behavior, these - instances should be filtered accordingly. The findings from this analytic offer - valuable insight into potentially malicious activities on an endpoint. +description: The following analytic detects instances of 'svchost.exe' spawning Living + Off The Land Binaries and Scripts (LOLBAS) processes. It leverages Endpoint Detection + and Response (EDR) data to monitor child processes of 'svchost.exe' that match known + LOLBAS executables. This activity is significant as adversaries often use LOLBAS + techniques to execute malicious code stealthily, potentially indicating lateral + movement or code execution attempts. If confirmed malicious, this behavior could + allow attackers to execute arbitrary commands, escalate privileges, or maintain + persistence within the environment, posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -87,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/svchost_lolbas_execution_process_spawn/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/svchost_lolbas_execution_process_spawn/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/system_info_gathering_using_dxdiag_application.yml b/detections/endpoint/system_info_gathering_using_dxdiag_application.yml index 2523e2b3b3..db166e66b2 100644 --- a/detections/endpoint/system_info_gathering_using_dxdiag_application.yml +++ b/detections/endpoint/system_info_gathering_using_dxdiag_application.yml @@ -1,18 +1,18 @@ name: System Info Gathering Using Dxdiag Application id: f92d74f2-4921-11ec-b685-acde48001122 -version: 1 -date: '2021-11-19' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic is to detect a suspicious dxdiag.exe process command-line - execution. Dxdiag is used to collect the system info of the target host. This technique - has been used by Remcos RATS, various actors, and other malware to collect information - as part of the recon or collection phase of an attack. This behavior should rarely - be seen in a corporate network, but this command line can be used by a network administrator - to audit host machine specifications. Thus in some rare cases, this detection will - contain false positives in its results. To triage further, analyze what commands - were passed after it pipes out the result to a file for further processing. +description: The following analytic identifies the execution of the dxdiag.exe process + with specific command-line arguments, which is used to gather system information. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process creation events and command-line details. This activity is significant + because dxdiag.exe is rarely used in corporate environments and its execution may + indicate reconnaissance efforts by malicious actors. If confirmed malicious, this + activity could allow attackers to collect detailed system information, aiding in + further exploitation or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1592/host_info_dxdiag/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1592/host_info_dxdiag/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/system_processes_run_from_unexpected_locations.yml b/detections/endpoint/system_processes_run_from_unexpected_locations.yml index 3871676bae..c446396c02 100644 --- a/detections/endpoint/system_processes_run_from_unexpected_locations.yml +++ b/detections/endpoint/system_processes_run_from_unexpected_locations.yml @@ -1,27 +1,24 @@ name: System Processes Run From Unexpected Locations id: a34aae96-ccf8-4aef-952c-3ea21444444d -version: 6 -date: '2020-12-08' +version: 7 +date: '2024-05-25' author: David Dorsey, Michael Haag, Splunk status: production type: Anomaly -description: 'This search looks for system processes that typically execute from `C:\Windows\System32\` - or `C:\Windows\SysWOW64`. This may indicate a malicious process that is trying - to hide as a legitimate process. - - This detection utilizes a lookup that is deduped `system32` and `syswow64` directories - from Server 2016 and Windows 10. - - During triage, review the parallel processes - what process moved the native Windows - binary? identify any artifacts on disk and review. If a remote destination is contacted, - what is the reputation?' +description: 'The following analytic identifies system processes running from unexpected + locations outside `C:\Windows\System32\` or `C:\Windows\SysWOW64`. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process paths, + names, and hashes. This activity is significant as it may indicate a malicious process + attempting to masquerade as a legitimate system process. If confirmed malicious, + this behavior could allow an attacker to execute code, escalate privileges, or maintain + persistence within the environment, posing a significant security risk.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.process_path !="C:\\Windows\\System32*" Processes.process_path !="C:\\Windows\\SysWOW64*" by Processes.dest Processes.user - Processes.parent_process Processes.process_path Processes.process_name Processes.process Processes.process_id - Processes.parent_process_id Processes.process_hash | `drop_dm_object_name("Processes")` + Processes.parent_process Processes.process_path Processes.process_name Processes.process + Processes.process_id Processes.parent_process_id Processes.process_hash | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| `is_windows_system_file_macro` | `system_processes_run_from_unexpected_locations_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection @@ -82,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/system_user_discovery_with_query.yml b/detections/endpoint/system_user_discovery_with_query.yml index 7cb5ef9c26..0ee1d19535 100644 --- a/detections/endpoint/system_user_discovery_with_query.yml +++ b/detections/endpoint/system_user_discovery_with_query.yml @@ -1,14 +1,17 @@ name: System User Discovery With Query id: ad03bfcf-8a91-4bc2-a500-112993deba87 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-23' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `query.exe` with command-line - arguments utilized to discover the logged user. Red Teams and adversaries alike - may leverage `query.exe` to identify system users on a compromised endpoint for - situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `query.exe` with command-line + arguments aimed at discovering logged-in users. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as adversaries may use `query.exe` to gain + situational awareness and perform Active Directory discovery on compromised endpoints. + If confirmed malicious, this behavior could allow attackers to identify active users, + aiding in further lateral movement and privilege escalation within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/system_user_discovery_with_whoami.yml b/detections/endpoint/system_user_discovery_with_whoami.yml index 874bd354b2..20c9d2afc6 100644 --- a/detections/endpoint/system_user_discovery_with_whoami.yml +++ b/detections/endpoint/system_user_discovery_with_whoami.yml @@ -1,14 +1,18 @@ name: System User Discovery With Whoami id: 894fc43e-6f50-47d5-a68b-ee9ee23e18f4 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `whoami.exe` without any arguments. - This windows native binary prints out the current logged user. Red Teams and adversaries - alike may leverage `whoami.exe` to identify system users on a compromised endpoint - for situational awareness and Active Directory Discovery. +description: The following analytic detects the execution of `whoami.exe` without + any arguments. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process execution logs. This activity is significant because both Red + Teams and adversaries use `whoami.exe` to identify the current logged-in user, aiding + in situational awareness and Active Directory discovery. If confirmed malicious, + this behavior could indicate an attacker is gathering information to further compromise + the system, potentially leading to privilege escalation or lateral movement within + the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/time_provider_persistence_registry.yml b/detections/endpoint/time_provider_persistence_registry.yml index 4fda914196..3cfee5f93b 100644 --- a/detections/endpoint/time_provider_persistence_registry.yml +++ b/detections/endpoint/time_provider_persistence_registry.yml @@ -1,23 +1,27 @@ name: Time Provider Persistence Registry id: 5ba382c4-2105-11ec-8d8f-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-13' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious modification of time provider - registry for persistence and autostart. This technique can allow the attacker to - persist on the compromised host and autostart as soon as the machine boot up. This - TTP can be a good indicator of suspicious behavior since this registry is not commonly - modified by normal user or even an admin. +description: The following analytic detects suspicious modifications to the time provider + registry for persistence and autostart. It leverages data from the Endpoint.Registry + data model, focusing on changes to the "CurrentControlSet\\Services\\W32Time\\TimeProviders" + registry path. This activity is significant because such modifications are uncommon + and can indicate an attempt to establish persistence on a compromised host. If confirmed + malicious, this technique allows an attacker to maintain access and execute code + automatically upon system boot, potentially leading to further exploitation and + control over the affected system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*\\CurrentControlSet\\Services\\W32Time\\TimeProviders*") - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `time_provider_persistence_registry_filter`' + BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `time_provider_persistence_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -66,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.003/timeprovider_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.003/timeprovider_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/uac_bypass_mmc_load_unsigned_dll.yml b/detections/endpoint/uac_bypass_mmc_load_unsigned_dll.yml index 0144cd74ca..92ba9a187a 100644 --- a/detections/endpoint/uac_bypass_mmc_load_unsigned_dll.yml +++ b/detections/endpoint/uac_bypass_mmc_load_unsigned_dll.yml @@ -1,14 +1,19 @@ name: UAC Bypass MMC Load Unsigned Dll id: 7f04349c-e30d-11eb-bc7f-acde48001122 -version: 1 -date: '2021-07-12' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious loaded unsigned dll by MMC.exe - application. This technique is commonly seen in attacker that tries to bypassed - UAC feature or gain privilege escalation. This is done by modifying some CLSID registry - that will trigger the mmc.exe to load the dll path +description: The following analytic detects the loading of an unsigned DLL by the + MMC.exe application, which is indicative of a potential UAC bypass or privilege + escalation attempt. It leverages Sysmon EventCode 7 to identify instances where + MMC.exe loads a non-Microsoft, unsigned DLL. This activity is significant because + attackers often use this technique to modify CLSID registry entries, causing MMC.exe + to load malicious DLLs, thereby bypassing User Account Control (UAC) and gaining + elevated privileges. If confirmed malicious, this could allow an attacker to execute + arbitrary code with higher privileges, leading to further system compromise and + persistence. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 ImageLoaded = "*.dll" Image = "*\\mmc.exe" Signed=false @@ -59,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/uac_bypass_with_colorui_com_object.yml b/detections/endpoint/uac_bypass_with_colorui_com_object.yml index aa35ab0497..f40dff0bff 100644 --- a/detections/endpoint/uac_bypass_with_colorui_com_object.yml +++ b/detections/endpoint/uac_bypass_with_colorui_com_object.yml @@ -1,18 +1,23 @@ name: UAC Bypass With Colorui COM Object id: 2bcccd20-fc2b-11eb-8d22-acde48001122 -version: 1 -date: '2021-08-13' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a possible uac bypass using the colorui.dll - COM Object. this technique was seen in so many malware and ransomware like lockbit - where it make use of the colorui.dll COM CLSID to bypass UAC. +description: The following analytic detects a potential UAC bypass using the colorui.dll + COM Object. It leverages Sysmon EventCode 7 to identify instances where colorui.dll + is loaded by a process other than colorcpl.exe, excluding common system directories. + This activity is significant because UAC bypass techniques are often used by malware, + such as LockBit ransomware, to gain elevated privileges without user consent. If + confirmed malicious, this could allow an attacker to execute code with higher privileges, + leading to further system compromise and persistence within the environment. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 ImageLoaded="*\\colorui.dll" process_name != "colorcpl.exe" NOT(Image IN("*\\windows\\*", "*\\program files*")) | stats count min(_time) as - firstTime max(_time) as lastTime by Image ImageLoaded process_name dest user_id EventCode Signed ProcessId | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + firstTime max(_time) as lastTime by Image ImageLoaded process_name dest user_id + EventCode Signed ProcessId | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `uac_bypass_with_colorui_com_object_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -28,7 +33,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 60 - message: The following module $ImageLoaded$ was loaded by a non-standard application on endpoint $dest$. + message: The following module $ImageLoaded$ was loaded by a non-standard application + on endpoint $dest$. mitre_attack_id: - T1218 - T1218.003 @@ -59,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/uac_colorui/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/uac_colorui/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/uninstall_app_using_msiexec.yml b/detections/endpoint/uninstall_app_using_msiexec.yml index 2346b44037..3a5f4eb570 100644 --- a/detections/endpoint/uninstall_app_using_msiexec.yml +++ b/detections/endpoint/uninstall_app_using_msiexec.yml @@ -1,14 +1,18 @@ name: Uninstall App Using MsiExec id: 1fca2b28-f922-11eb-b2dd-acde48001122 -version: 1 -date: '2021-08-09' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious un-installation of application - using msiexec. This technique was seen in conti leak tool and script where it tries - to uninstall AV product using this commandline. This commandline to uninstall product - is not a common practice in enterprise network. +description: The following analytic detects the uninstallation of applications using + msiexec with specific command-line arguments. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs that include command-line + details. This activity is significant because it is an uncommon practice in enterprise + environments and has been associated with malicious behavior, such as disabling + antivirus software. If confirmed malicious, this could allow an attacker to remove + security software, potentially leading to further compromise and persistence within + the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/conti/conti_leak/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml b/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml index 9faf2a372a..6e7650ccd9 100644 --- a/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml +++ b/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml @@ -1,19 +1,28 @@ name: Unknown Process Using The Kerberos Protocol id: c91a0852-9fbb-11ec-af44-acde48001122 -version: 2 -date: '2024-01-23' +version: 3 +date: '2024-05-19' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies a process performing an outbound connection - on port 88 used by default by the network authentication protocol Kerberos. Typically, - on a regular Windows endpoint, only the lsass.exe process is the one tasked with - connecting to the Kerberos Distribution Center to obtain Kerberos tickets. Identifying - an unknown process using this protocol may be evidence of an adversary abusing the - Kerberos protocol. +description: The following analytic identifies a non-lsass.exe process making an outbound + connection on port 88, which is typically used by the Kerberos authentication protocol. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process and network traffic logs. This activity is significant because, + under normal circumstances, only the lsass.exe process should interact with the + Kerberos Distribution Center. If confirmed malicious, this behavior could indicate + an adversary attempting to abuse the Kerberos protocol, potentially leading to unauthorized + access or lateral movement within the network. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name!=lsass.exe by _time Processes.process_id Processes.process_name Processes.dest Processes.process_path Processes.process Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | join process_id dest [| tstats `security_content_summariesonly` count FROM datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port = 88 by All_Traffic.src All_Traffic.process_id All_Traffic.dest_port | `drop_dm_object_name(All_Traffic)` | rename src as dest ] | table _time dest parent_process_name process_name process_path process process_id dest_port | `unknown_process_using_the_kerberos_protocol_filter`' +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes + where Processes.process_name!=lsass.exe by _time Processes.process_id Processes.process_name + Processes.dest Processes.process_path Processes.process Processes.parent_process_name + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | join process_id dest [| tstats `security_content_summariesonly` count FROM datamodel=Network_Traffic.All_Traffic + where All_Traffic.dest_port = 88 by All_Traffic.src All_Traffic.process_id All_Traffic.dest_port + | `drop_dm_object_name(All_Traffic)` | rename src as dest ] | table _time dest + parent_process_name process_name process_path process process_id dest_port | `unknown_process_using_the_kerberos_protocol_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -34,7 +43,8 @@ tags: asset_type: Endpoint confidence: 60 impact: 60 - message: Unknown process $process_name$ using the kerberos protocol detected on host $dest$ + message: Unknown process $process_name$ using the kerberos protocol detected on + host $dest$ mitre_attack_id: - T1550 observable: @@ -62,9 +72,11 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/rubeus/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/rubeus/windows-security.log source: WinEventLog:Security sourcetype: WinEventLog - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/rubeus/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1550/rubeus/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/unload_sysmon_filter_driver.yml b/detections/endpoint/unload_sysmon_filter_driver.yml index 1bd3d35327..cf0bb0a7ce 100644 --- a/detections/endpoint/unload_sysmon_filter_driver.yml +++ b/detections/endpoint/unload_sysmon_filter_driver.yml @@ -19,8 +19,8 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime AND Processes.process=*unload* AND Processes.process=*SysmonDrv* by Processes.process_name Processes.process_id Processes.parent_process_name Processes.process Processes.dest Processes.user | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`|`security_content_ctime(lastTime)` - |`unload_sysmon_filter_driver_filter`| table firstTime lastTime dest user count - process_name process_id parent_process_name process' + | table firstTime lastTime dest user count process_name process_id parent_process_name process + | `unload_sysmon_filter_driver_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, diff --git a/detections/endpoint/unloading_amsi_via_reflection.yml b/detections/endpoint/unloading_amsi_via_reflection.yml index 5c0e3366c7..a96829949e 100644 --- a/detections/endpoint/unloading_amsi_via_reflection.yml +++ b/detections/endpoint/unloading_amsi_via_reflection.yml @@ -1,24 +1,18 @@ name: Unloading AMSI via Reflection id: a21e3484-c94d-11eb-b55b-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify suspicious PowerShell execution. Script Block Logging captures the command - sent to PowerShell, the full command to be executed. Upon enabling, logs will output - to Windows event logs. Dependent upon volume, enable on critical endpoints or all. - - - This analytic identifies the behavior of AMSI being tampered with. Implemented natively - in many frameworks, the command will look similar to `SEtValuE($Null,(New-OBJEct - COLlECtionS.GenerIC.HAshSEt{[StrINg]))}$ReF=[ReF].AsSeMbLY.GeTTyPe("System.Management.Automation.Amsi"+"Utils")` - taken from Powershell-Empire. - - During triage, review parallel processes using an EDR product or 4688 events. It - will be important to understand the timeline of events around this activity. Review - the entire logged PowerShell script block.' +description: 'The following analytic detects the tampering of AMSI (Antimalware Scan + Interface) via PowerShell reflection. It leverages PowerShell Script Block Logging + (EventCode=4104) to capture and analyze suspicious PowerShell commands, specifically + those involving `system.management.automation.amsi`. This activity is significant + as it indicates an attempt to bypass AMSI, a critical security feature that helps + detect and block malicious scripts. If confirmed malicious, this could allow an + attacker to execute harmful code undetected, leading to potential system compromise + and data exfiltration.' data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = *system.management.automation.amsi* @@ -69,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/unusual_number_of_computer_service_tickets_requested.yml b/detections/endpoint/unusual_number_of_computer_service_tickets_requested.yml index e11b3275a9..4f9f960d7e 100644 --- a/detections/endpoint/unusual_number_of_computer_service_tickets_requested.yml +++ b/detections/endpoint/unusual_number_of_computer_service_tickets_requested.yml @@ -1,16 +1,18 @@ name: Unusual Number of Computer Service Tickets Requested id: ac3b81c0-52f4-11ec-ac44-acde48001122 -version: 1 -date: '2021-12-01' +version: 2 +date: '2024-05-25' author: Mauricio Velazco, Splunk status: experimental type: Hunting -description: 'The following hunting analytic leverages Event ID 4769, `A Kerberos - service ticket was requested`, to identify an unusual number of computer service - ticket requests from one source. When a domain joined endpoint connects to a remote - endpoint, it first will request a Kerberos Ticket with the computer name as the - Service Name. An endpoint requesting a large number of computer service tickets - for different endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of service requests. To customize this analytic, users can try different combinations of the `bucket` span time, the calculation of the `upperBound` field as well as the Outlier calculation. This logic can be used for real time security monitoring as well as threat hunting exercises.' +description: 'The following analytic identifies an unusual number of computer service + ticket requests from a single source, leveraging Event ID 4769, "A Kerberos service + ticket was requested." It uses statistical analysis, including standard deviation + and the 3-sigma rule, to detect anomalies in service ticket requests. This activity + is significant as it may indicate malicious behavior such as lateral movement, malware + staging, or reconnaissance. If confirmed malicious, an attacker could gain unauthorized + access to multiple endpoints, facilitating further compromise and potential data + exfiltration.' data_source: - Windows Event Log Security 4769 search: ' `wineventlog_security` EventCode=4769 Service_Name="*$" Account_Name!="*$*" diff --git a/detections/endpoint/unusual_number_of_kerberos_service_tickets_requested.yml b/detections/endpoint/unusual_number_of_kerberos_service_tickets_requested.yml index 611d329514..066ee5a7f2 100644 --- a/detections/endpoint/unusual_number_of_kerberos_service_tickets_requested.yml +++ b/detections/endpoint/unusual_number_of_kerberos_service_tickets_requested.yml @@ -1,25 +1,23 @@ name: Unusual Number of Kerberos Service Tickets Requested id: eb3e6702-8936-11ec-98fe-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: Anomaly -description: 'The following hunting analytic leverages Kerberos Event 4769, A Kerberos - service ticket was requested, to identify a potential kerberoasting attack against - Active Directory networks. Kerberoasting allows an adversary to request kerberos - tickets for domain accounts typically used as service accounts and attempt to crack - them offline allowing them to obtain privileged access to the domain. - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number service ticket requests. - To customize this analytic, users can try different combinations of the `bucket` - span time and the calculation of the `upperBound` field.' +description: 'The following analytic identifies an unusual number of Kerberos service + ticket requests, potentially indicating a kerberoasting attack. It leverages Kerberos + Event 4769 and calculates the standard deviation for each host, using the 3-sigma + rule to detect anomalies. This activity is significant as kerberoasting allows adversaries + to request service tickets and crack them offline, potentially gaining privileged + access to the domain. If confirmed malicious, this could lead to unauthorized access + to sensitive accounts and escalation of privileges within the Active Directory environment.' data_source: - Windows Event Log Security 4769 -search: ' `wineventlog_security` EventCode=4769 ServiceName!="*$" TicketEncryptionType=0x17 | bucket span=2m _time | stats dc(ServiceName) AS unique_services values(ServiceName) - as requested_services by _time, src | eventstats avg(unique_services) - as comp_avg , stdev(unique_services) as comp_std by src | eval upperBound=(comp_avg+comp_std*3) +search: ' `wineventlog_security` EventCode=4769 ServiceName!="*$" TicketEncryptionType=0x17 + | bucket span=2m _time | stats dc(ServiceName) AS unique_services values(ServiceName) + as requested_services by _time, src | eventstats avg(unique_services) as comp_avg + , stdev(unique_services) as comp_std by src | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_services > 2 and unique_services >= upperBound, 1, 0) | search isOutlier=1 | `unusual_number_of_kerberos_service_tickets_requested_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -65,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/unusual_number_of_kerberos_service_tickets_requested/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/unusual_number_of_kerberos_service_tickets_requested/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/unusual_number_of_remote_endpoint_authentication_events.yml b/detections/endpoint/unusual_number_of_remote_endpoint_authentication_events.yml index 1634a215bb..1d25cdb3b5 100644 --- a/detections/endpoint/unusual_number_of_remote_endpoint_authentication_events.yml +++ b/detections/endpoint/unusual_number_of_remote_endpoint_authentication_events.yml @@ -1,15 +1,17 @@ name: Unusual Number of Remote Endpoint Authentication Events id: acb5dc74-5324-11ec-a36d-acde48001122 -version: 1 -date: '2021-12-01' +version: 2 +date: '2024-05-11' author: Mauricio Velazco, Splunk status: experimental type: Hunting -description: 'The following hunting analytic leverages Event ID 4624, `An account - was successfully logged on`, to identify an unusual number of remote authentication - attempts coming from one source. An endpoint authenticating to a large number of - remote endpoints could represent malicious behavior like lateral movement, malware - staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual high number of authentication events.To customize this analytic, users can try different combinations of the `bucket` span time, the calculation of the `upperBound` field as well as the Outlier calculation.This logic can be used for real time security monitoring as well as threat hunting exercises.' +description: 'The following analytic identifies an unusual number of remote authentication + attempts from a single source by leveraging Windows Event ID 4624, which logs successful + account logons. It uses statistical analysis, specifically the 3-sigma rule, to + detect deviations from normal behavior. This activity is significant for a SOC as + it may indicate lateral movement, malware staging, or reconnaissance. If confirmed + malicious, this behavior could allow an attacker to move laterally within the network, + escalate privileges, or gather information for further attacks.' data_source: - Windows Event Log Security 4624 search: ' `wineventlog_security` EventCode=4624 Logon_Type=3 Account_Name!="*$" | @@ -56,4 +58,4 @@ tags: - Account_Name - ComputerName risk_score: 42 - security_domain: endpoint \ No newline at end of file + security_domain: endpoint diff --git a/detections/endpoint/unusually_long_command_line.yml b/detections/endpoint/unusually_long_command_line.yml index 42754fafb6..7e44a8e57c 100644 --- a/detections/endpoint/unusually_long_command_line.yml +++ b/detections/endpoint/unusually_long_command_line.yml @@ -1,12 +1,12 @@ name: Unusually Long Command Line id: c77162d3-f93c-45cc-80c8-22f6a4264e7f -version: 5 -date: '2020-12-08' +version: 6 +date: '2024-05-20' author: David Dorsey, Splunk status: experimental type: Anomaly description: |- - The following analytic detects command lines that are extremely long, which might be indicative of malicious activity on your hosts because attackers often use obfuscated or complex command lines to hide their actions and evade detection. This helps to mitigate the risks associated with long command lines to enhance your overall security posture and reduce the impact of attacks. This detection is important because it suggests that an attacker might be attempting to execute a malicious command or payload on the host, which can lead to various damaging outcomes such as data theft, ransomware, or further compromise of the system. False positives might occur since legitimate processes or commands can sometimes result in long command lines. Next steps include conducting extensive triage and investigation to differentiate between legitimate and malicious activities. Review the source of the command line and the command itself during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. + The following analytic detects unusually long command lines, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on the length of command lines executed on hosts. This behavior is significant because attackers often use obfuscated or complex command lines to evade detection and execute malicious payloads. If confirmed malicious, this activity could lead to data theft, ransomware deployment, or further system compromise. Analysts should investigate the source and content of the command line, inspect relevant artifacts, and review concurrent processes to identify potential threats. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/unusually_long_command_line___mltk.yml b/detections/endpoint/unusually_long_command_line___mltk.yml index be45bd6f70..e0585e47eb 100644 --- a/detections/endpoint/unusually_long_command_line___mltk.yml +++ b/detections/endpoint/unusually_long_command_line___mltk.yml @@ -1,13 +1,17 @@ name: Unusually Long Command Line - MLTK id: 57edaefa-a73b-45e5-bbae-f39c1473f941 -version: 1 -date: '2019-05-08' +version: 2 +date: '2024-05-26' author: Rico Valdez, Splunk status: experimental type: Anomaly -description: Command lines that are extremely long may be indicative of malicious - activity on your hosts. This search leverages the Machine Learning Toolkit (MLTK) - to help identify command lines with lengths that are unusual for a given user. +description: The following analytic identifies unusually long command lines executed + on hosts, which may indicate malicious activity. It leverages the Machine Learning + Toolkit (MLTK) to detect command lines with lengths that deviate from the norm for + a given user. This is significant for a SOC as unusually long command lines can + be a sign of obfuscation or complex malicious scripts. If confirmed malicious, this + activity could allow attackers to execute sophisticated commands, potentially leading + to unauthorized access, data exfiltration, or further compromise of the system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/user_discovery_with_env_vars_powershell.yml b/detections/endpoint/user_discovery_with_env_vars_powershell.yml index 63d546faff..bf025c6f7c 100644 --- a/detections/endpoint/user_discovery_with_env_vars_powershell.yml +++ b/detections/endpoint/user_discovery_with_env_vars_powershell.yml @@ -1,15 +1,18 @@ name: User Discovery With Env Vars PowerShell id: 0cdf318b-a0dd-47d7-b257-c621c0247de8 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-19' author: Mauricio Velazco, Splunk status: production type: Hunting -description: This analytic looks for the execution of `powershell.exe` with command-line - arguments that leverage PowerShell environment variables to identify the current - logged user. Red Teams and adversaries may leverage this method to identify the - logged user on a compromised endpoint for situational awareness and Active Directory - Discovery. +description: The following analytic detects the execution of `powershell.exe` with + command-line arguments that use PowerShell environment variables to identify the + current logged user. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names and command-line executions. This activity is + significant as adversaries may use it for situational awareness and Active Directory + discovery on compromised endpoints. If confirmed malicious, this behavior could + allow attackers to gather critical user information, aiding in further exploitation + and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/user_discovery_with_env_vars_powershell_script_block.yml b/detections/endpoint/user_discovery_with_env_vars_powershell_script_block.yml index d35bd3ef5f..1c031185cc 100644 --- a/detections/endpoint/user_discovery_with_env_vars_powershell_script_block.yml +++ b/detections/endpoint/user_discovery_with_env_vars_powershell_script_block.yml @@ -1,23 +1,24 @@ name: User Discovery With Env Vars PowerShell Script Block id: 77f41d9e-b8be-47e3-ab35-5776f5ec1d20 -version: 2 -date: '2022-03-22' +version: 3 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: Hunting -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the use of PowerShell environment variables to identify the current - logged user. Red Teams and adversaries may leverage this method to identify the - logged user on a compromised endpoint for situational awareness and Active Directory - Discovery. +description: The following analytic detects the use of PowerShell environment variables + to identify the current logged user by leveraging PowerShell Script Block Logging + (EventCode=4104). This method monitors script blocks containing `$env:UserName` + or `[System.Environment]::UserName`. Identifying this activity is significant as + adversaries and Red Teams may use it for situational awareness and Active Directory + discovery on compromised endpoints. If confirmed malicious, this activity could + allow attackers to gain insights into user context, aiding in further exploitation + and lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText = "*$env:UserName*" OR ScriptBlockText = "*[System.Environment]::UserName*") | stats count min(_time) as firstTime max(_time) - as lastTime by EventCode ScriptBlockText Computer user_id - | rename Computer as dest, user_id as user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + as lastTime by EventCode ScriptBlockText Computer user_id | rename Computer as dest, + user_id as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `user_discovery_with_env_vars_powershell_script_block_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here @@ -61,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/AD_discovery/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/usn_journal_deletion.yml b/detections/endpoint/usn_journal_deletion.yml index 30f47248ed..af019c6418 100644 --- a/detections/endpoint/usn_journal_deletion.yml +++ b/detections/endpoint/usn_journal_deletion.yml @@ -1,14 +1,18 @@ name: USN Journal Deletion id: b6e0ff70-b122-4227-9368-4cf322ab43c3 -version: 2 -date: '2018-12-03' +version: 3 +date: '2024-05-12' author: David Dorsey, Splunk status: production type: TTP -description: The fsutil.exe application is a legitimate Windows utility used to perform - tasks related to the file allocation table (FAT) and NTFS file systems. The update - sequence number (USN) change journal provides a log of all changes made to the files - on the disk. This search looks for fsutil.exe deleting the USN journal. +description: The following analytic detects the deletion of the USN Journal using + the fsutil.exe utility. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process execution logs that include command-line details. This + activity is significant because the USN Journal maintains a log of all changes made + to files on the disk, and its deletion can be an indicator of an attempt to cover + tracks or hinder forensic investigations. If confirmed malicious, this action could + allow an attacker to obscure their activities, making it difficult to trace file + modifications and potentially compromising incident response efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process) @@ -60,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/vbscript_execution_using_wscript_app.yml b/detections/endpoint/vbscript_execution_using_wscript_app.yml index c49955fb04..c6ed45174a 100644 --- a/detections/endpoint/vbscript_execution_using_wscript_app.yml +++ b/detections/endpoint/vbscript_execution_using_wscript_app.yml @@ -1,15 +1,18 @@ name: Vbscript Execution Using Wscript App id: 35159940-228f-11ec-8a49-acde48001122 -version: 1 -date: '2021-10-01' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to detect a suspicious wscript commandline to execute - vbscript. This technique was seen in several malware to execute malicious vbs file - using wscript application. commonly vbs script is associated to cscript process - and this can be a technique to evade process parent child detections or even some - av script emulation system. +description: The following analytic detects the execution of VBScript using the wscript.exe + application. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process and command-line telemetry. This activity is significant because + wscript.exe is typically not used to execute VBScript, which is usually associated + with cscript.exe. This deviation can indicate an attempt to evade traditional process + monitoring and antivirus defenses. If confirmed malicious, this technique could + allow attackers to execute arbitrary code, potentially leading to system compromise, + data exfiltration, or further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/verclsid_clsid_execution.yml b/detections/endpoint/verclsid_clsid_execution.yml index b08b64a074..5fcbc96f83 100644 --- a/detections/endpoint/verclsid_clsid_execution.yml +++ b/detections/endpoint/verclsid_clsid_execution.yml @@ -1,15 +1,18 @@ name: Verclsid CLSID Execution id: 61e9a56a-20fa-11ec-8ba3-acde48001122 -version: 1 -date: '2021-09-29' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic is to detect a possible abuse of verclsid to execute malicious - file through generate CLSID. This process is a normal application of windows to - verify the CLSID COM object before it is instantiated by Windows Explorer. This - hunting query can be a good pivot point to analyze what is he CLSID or COM object - pointing too to check if it is a valid application or not. +description: The following analytic detects the potential abuse of the verclsid.exe + utility to execute malicious files via generated CLSIDs. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on specific command-line + patterns associated with verclsid.exe. This activity is significant because verclsid.exe + is a legitimate Windows application used to verify CLSID COM objects, and its misuse + can indicate an attempt to bypass security controls. If confirmed malicious, this + technique could allow an attacker to execute arbitrary code, potentially leading + to system compromise or further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -76,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.012/verclsid_exec/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.012/verclsid_exec/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/w3wp_spawning_shell.yml b/detections/endpoint/w3wp_spawning_shell.yml index b2705361f7..52aebab2b1 100644 --- a/detections/endpoint/w3wp_spawning_shell.yml +++ b/detections/endpoint/w3wp_spawning_shell.yml @@ -1,18 +1,18 @@ name: W3WP Spawning Shell id: 0f03423c-7c6a-11eb-bc47-acde48001122 -version: 2 -date: '2023-07-10' +version: 3 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: This query identifies a shell, PowerShell.exe or Cmd.exe, spawning from - W3WP.exe, or IIS. In addition to IIS logs, this behavior with an EDR product will - capture potential webshell activity, similar to the HAFNIUM Group abusing CVEs, - on publicly available Exchange mail servers. During triage, review the parent process - and child process of the shell being spawned. Review the command-line arguments - and any file modifications that may occur. Identify additional parallel process, - child processes, that may highlight further commands executed. After triaging, work - to contain the threat and patch the system that is vulnerable. +description: The following analytic identifies instances where a shell (PowerShell.exe + or Cmd.exe) is spawned from W3WP.exe, the IIS worker process. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process creation + events where the parent process is W3WP.exe. This activity is significant as it + may indicate webshell activity, often associated with exploitation attempts like + those by the HAFNIUM Group on Exchange servers. If confirmed malicious, this behavior + could allow attackers to execute arbitrary commands, potentially leading to system + compromise, data exfiltration, or further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count values(Processes.process_name) @@ -88,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wbemprox_com_object_execution.yml b/detections/endpoint/wbemprox_com_object_execution.yml index 41be0a9cb8..b9cf151cb4 100644 --- a/detections/endpoint/wbemprox_com_object_execution.yml +++ b/detections/endpoint/wbemprox_com_object_execution.yml @@ -1,17 +1,18 @@ name: Wbemprox COM Object Execution id: 9d911ce0-c3be-11eb-b177-acde48001122 -version: 1 -date: '2021-06-02' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a potential suspicious process loading - a COM object from wbemprox.dll or faskprox.dll. The Microsoft Component Object Model - (COM) is a platform-independent, distributed, object-oriented system for creating - binary software components that can interact. This feature is being abused by several - threat actors, adversaries or even red teamers to gain privilege escalation or even - to evade detections. This TTP is a good indicator that a process is loading possible - known .dll modules that were known for its COM object. +description: The following analytic detects a suspicious process loading a COM object + from wbemprox.dll, fastprox.dll, or wbemcomn.dll. It leverages Sysmon EventCode + 7 to identify instances where these DLLs are loaded by processes not typically associated + with them, excluding known legitimate processes and directories. This activity is + significant as it may indicate an attempt by threat actors to abuse COM objects + for privilege escalation or evasion of detection mechanisms. If confirmed malicious, + this could allow attackers to gain elevated privileges or maintain persistence within + the environment, posing a significant security risk. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 ImageLoaded IN ("*\\fastprox.dll", "*\\wbemprox.dll", @@ -65,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf2/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/revil/inf2/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wermgr_process_connecting_to_ip_check_web_services.yml b/detections/endpoint/wermgr_process_connecting_to_ip_check_web_services.yml index 3d2355fc2f..3d0107a0a5 100644 --- a/detections/endpoint/wermgr_process_connecting_to_ip_check_web_services.yml +++ b/detections/endpoint/wermgr_process_connecting_to_ip_check_web_services.yml @@ -1,17 +1,17 @@ name: Wermgr Process Connecting To IP Check Web Services id: ed313326-a0f9-11eb-a89c-acde48001122 -version: 2 -date: '2022-06-01' +version: 3 +date: '2024-05-27' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: This search is designed to detect suspicious wermgr.exe process that - tries to connect to known IP web services. This technique is know for trickbot and - other trojan spy malware to recon the infected machine and look for its ip address - without so much finger print on the commandline process. Since wermgr.exe is designed - for error handling process of windows it is really suspicious that this process - is trying to connect to this IP web services cause that maybe cause of some malicious - code injection. +description: The following analytic detects the wermgr.exe process attempting to connect + to known IP check web services. It leverages Sysmon EventCode 22 to identify DNS + queries made by wermgr.exe to specific IP check services. This activity is significant + because wermgr.exe is typically used for Windows error reporting, and its connection + to these services may indicate malicious code injection, often associated with malware + like Trickbot. If confirmed malicious, this behavior could allow attackers to recon + the infected machine's IP address, aiding in further exploitation and evasion tactics. data_source: - Sysmon EventID 22 search: '`sysmon` EventCode =22 process_name = wermgr.exe QueryName IN ("*wtfismyip.com", @@ -19,8 +19,9 @@ search: '`sysmon` EventCode =22 process_name = wermgr.exe QueryName IN ("*wtfism "*ip.anysrc.com","*api.ip.sb", "ident.me", "www.myexternalip.com", "*zen.spamhaus.org", "*cbl.abuseat.org", "*b.barracudacentral.org","*dnsbl-1.uceprotect.net", "*spam.dnsbl.sorbs.net") | stats min(_time) as firstTime max(_time) as lastTime count by Image process_name - ProcessId QueryName QueryStatus QueryResults EventCode Computer | rename Computer as dest | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `wermgr_process_connecting_to_ip_check_web_services_filter`' + ProcessId QueryName QueryStatus QueryResults EventCode Computer | rename Computer + as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `wermgr_process_connecting_to_ip_check_web_services_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from your endpoints like EventCode 22. If you are using Sysmon, you must have at least @@ -63,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wermgr_process_create_executable_file.yml b/detections/endpoint/wermgr_process_create_executable_file.yml index c55a509bb0..231e40d92a 100644 --- a/detections/endpoint/wermgr_process_create_executable_file.yml +++ b/detections/endpoint/wermgr_process_create_executable_file.yml @@ -1,16 +1,17 @@ name: Wermgr Process Create Executable File id: ab3bcce0-a105-11eb-973c-acde48001122 -version: 1 -date: '2021-04-19' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: this search is designed to detect potential malicious wermgr.exe process - that drops or create executable file. Since wermgr.exe is an application trigger - when error encountered in a process, it is really un ussual to this process to drop - executable file. This technique is commonly seen in trickbot malware where it injects - it code to this process to execute it malicious behavior like downloading other - payload +description: The following analytic detects the wermgr.exe process creating an executable + file. It leverages Sysmon EventCode 11 to identify instances where wermgr.exe generates + a .exe file. This behavior is unusual because wermgr.exe is typically associated + with error reporting, not file creation. Such activity is significant as it may + indicate TrickBot malware, which injects code into wermgr.exe to execute malicious + actions like downloading additional payloads. If confirmed malicious, this could + lead to further malware infections, data exfiltration, or system compromise. data_source: - Sysmon EventID 11 search: '`sysmon` EventCode=11 process_name = "wermgr.exe" TargetFilename = "*.exe" @@ -56,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wermgr_process_spawned_cmd_or_powershell_process.yml b/detections/endpoint/wermgr_process_spawned_cmd_or_powershell_process.yml index 4bb17179bc..df44295542 100644 --- a/detections/endpoint/wermgr_process_spawned_cmd_or_powershell_process.yml +++ b/detections/endpoint/wermgr_process_spawned_cmd_or_powershell_process.yml @@ -1,14 +1,18 @@ name: Wermgr Process Spawned CMD Or Powershell Process id: e8fc95bc-a107-11eb-a978-acde48001122 -version: 2 -date: '2021-04-19' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is designed to detect suspicious cmd and powershell process - spawned by wermgr.exe process. This suspicious behavior are commonly seen in code - injection technique technique like trickbot to execute a shellcode, dll modules - to run malicious behavior. +description: The following analytic detects the spawning of cmd or PowerShell processes + by the wermgr.exe process. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process telemetry, including parent-child process relationships + and command-line executions. This behavior is significant as it is commonly associated + with code injection techniques used by malware like TrickBot to execute shellcode + or malicious DLL modules. If confirmed malicious, this activity could allow attackers + to execute arbitrary code, escalate privileges, or maintain persistence within the + environment, posing a severe threat to system security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as cmdline @@ -68,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/infection/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wget_download_and_bash_execution.yml b/detections/endpoint/wget_download_and_bash_execution.yml index f997b41d31..5284757eb7 100644 --- a/detections/endpoint/wget_download_and_bash_execution.yml +++ b/detections/endpoint/wget_download_and_bash_execution.yml @@ -1,13 +1,17 @@ name: Wget Download and Bash Execution id: 35682718-5a85-11ec-b8f7-acde48001122 -version: 1 -date: '2021-12-11' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of wget on Linux or MacOS attempting - to download a file from a remote source and pipe it to bash. This is typically found - with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +description: The following analytic detects the use of wget on Linux or MacOS to download + a file from a remote source and pipe it to bash. This detection leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant as it is commonly associated with malicious + actions like coinminers and exploits such as CVE-2021-44228 in Log4j. If confirmed + malicious, this behavior could allow attackers to execute arbitrary code, potentially + leading to system compromise and unauthorized access to sensitive data. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/detections/endpoint/windows_abused_web_services.yml b/detections/endpoint/windows_abused_web_services.yml index 2bcb34653e..1095d267ba 100644 --- a/detections/endpoint/windows_abused_web_services.yml +++ b/detections/endpoint/windows_abused_web_services.yml @@ -1,24 +1,23 @@ name: Windows Abused Web Services id: 01f0aef4-8591-4daa-a53d-0ed49823b681 -version: 1 -date: '2023-09-20' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 22 -description: The following analytic detects a suspicious process making a DNS query via known, - abused text-paste web services, VoIP, internet via secure tunneling,instant messaging, and digital distribution - platforms used to download external files. This technique is abused by adversaries, - malware actors, and red teams to download a malicious file on the target host. This - is a good TTP indicator for possible initial access techniques. A user will experience - false positives if the following instant messaging is allowed or common applications - like telegram or discord are allowed in the corporate network. -search: '`sysmon` EventCode=22 QueryName IN ("*pastebin*",""*textbin*"", "*ngrok.io*", "*discord*", "*duckdns.org*", "*pasteio.com*") - | stats count min(_time) as firstTime max(_time) as lastTime by Image QueryName QueryStatus process_name QueryResults Computer - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects a suspicious process making DNS queries + to known, abused web services such as text-paste sites, VoIP, secure tunneling, + instant messaging, and digital distribution platforms. This detection leverages + Sysmon logs with Event ID 22, focusing on specific query names. This activity is + significant as it may indicate an adversary attempting to download malicious files, + a common initial access technique. If confirmed malicious, this could lead to unauthorized + code execution, data exfiltration, or further compromise of the target host. +search: '`sysmon` EventCode=22 QueryName IN ("*pastebin*",""*textbin*"", "*ngrok.io*", + "*discord*", "*duckdns.org*", "*pasteio.com*") | stats count min(_time) as firstTime + max(_time) as lastTime by Image QueryName QueryStatus process_name QueryResults + Computer | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_abused_web_services_filter`' how_to_implement: This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days. @@ -62,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1102/njrat_ngrok_connection/ngrok.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1102/njrat_ngrok_connection/ngrok.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_access_token_manipulation_sedebugprivilege.yml b/detections/endpoint/windows_access_token_manipulation_sedebugprivilege.yml index f9596dc30f..36a82e515d 100644 --- a/detections/endpoint/windows_access_token_manipulation_sedebugprivilege.yml +++ b/detections/endpoint/windows_access_token_manipulation_sedebugprivilege.yml @@ -1,17 +1,17 @@ name: Windows Access Token Manipulation SeDebugPrivilege id: 6ece9ed0-5f92-4315-889d-48560472b188 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a suspicious process enabling the "SeDebugPrivilege" - privilege token. SeDebugPrivilege allows a process to inspect and adjust the memory - of other processes, and has long been a security concern. SeDebugPrivilege allows - the token bearer to access any process or thread, regardless of security descriptors, - per Palantir. This technique is abused by adversaries to gain debug privileges with - their malicious software to be able to access or debug a process to dump credentials - or to inject malicious code. +description: The following analytic detects a process enabling the "SeDebugPrivilege" + privilege token. It leverages Windows Security Event Logs with EventCode 4703, filtering + out common legitimate processes. This activity is significant because SeDebugPrivilege + allows a process to inspect and modify the memory of other processes, potentially + leading to credential dumping or code injection. If confirmed malicious, an attacker + could gain extensive control over system processes, enabling them to escalate privileges, + persist in the environment, or access sensitive information. data_source: - Windows Event Log Security 4703 search: '`wineventlog_security` EventCode=4703 EnabledPrivilegeList = "*SeDebugPrivilege*" @@ -72,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/sedebugprivilege_token/security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/sedebugprivilege_token/security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_access_token_manipulation_winlogon_duplicate_token_handle.yml b/detections/endpoint/windows_access_token_manipulation_winlogon_duplicate_token_handle.yml index 2cb73893ef..3379233382 100644 --- a/detections/endpoint/windows_access_token_manipulation_winlogon_duplicate_token_handle.yml +++ b/detections/endpoint/windows_access_token_manipulation_winlogon_duplicate_token_handle.yml @@ -1,21 +1,25 @@ name: Windows Access Token Manipulation Winlogon Duplicate Token Handle id: dda126d7-1d99-4f0b-b72a-4c14031f9398 -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process requesting access to winlogon.exe - attempting to duplicate its handle. This technique was seen in several adversaries - to gain privileges for their process. Winlogon.exe is the common targeted process - of this technique because it contains high privileges and security tokens. +description: The following analytic detects a process attempting to access winlogon.exe + to duplicate its handle. This is identified using Sysmon EventCode 10, focusing + on processes targeting winlogon.exe with specific access rights. This activity is + significant because it is a common technique used by adversaries to escalate privileges + by leveraging the high privileges and security tokens associated with winlogon.exe. + If confirmed malicious, this could allow an attacker to gain elevated privileges, + potentially leading to full system compromise and unauthorized access to sensitive + information. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage IN("*\\system32\\winlogon.exe*", "*\\SysWOW64\\winlogon.exe*") GrantedAccess = 0x1040 | stats count min(_time) as firstTime max(_time) as lastTime by SourceImage TargetImage SourceProcessGUID TargetProcessGUID SourceProcessId TargetProcessId - GrantedAccess CallTrace dest user_id | `security_content_ctime(firstTime)` | - `security_content_ctime(lastTime)` | `windows_access_token_manipulation_winlogon_duplicate_token_handle_filter`' + GrantedAccess CallTrace dest user_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_access_token_manipulation_winlogon_duplicate_token_handle_filter`' how_to_implement: To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 @@ -66,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/brute_duplicate_token/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/brute_duplicate_token/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_access_token_winlogon_duplicate_handle_in_uncommon_path.yml b/detections/endpoint/windows_access_token_winlogon_duplicate_handle_in_uncommon_path.yml index e2ecf54105..cc92288e72 100644 --- a/detections/endpoint/windows_access_token_winlogon_duplicate_handle_in_uncommon_path.yml +++ b/detections/endpoint/windows_access_token_winlogon_duplicate_handle_in_uncommon_path.yml @@ -1,25 +1,26 @@ name: Windows Access Token Winlogon Duplicate Handle In Uncommon Path id: b8f7ed6b-0556-4c84-bffd-839c262b0278 -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process requesting access in winlogon.exe - to duplicate its handle with a non-common or public process source path. This technique - was seen where adversaries attempt to gain privileges to their process. This duplicate - handle access technique, may refer to a malicious process duplicating the process - token of winlogon.exe and using it to a new process instance. Winlogon.exe is the - common targeted process of this technique because it contains high privileges and - security tokens. +description: The following analytic detects a process attempting to duplicate the + handle of winlogon.exe from an uncommon or public source path. This is identified + using Sysmon EventCode 10, focusing on processes targeting winlogon.exe with specific + access rights and excluding common system paths. This activity is significant because + it may indicate an adversary trying to escalate privileges by leveraging the high-privilege + tokens associated with winlogon.exe. If confirmed malicious, this could allow the + attacker to gain elevated access, potentially leading to full system compromise + and persistent control over the affected host. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage IN("*\\system32\\winlogon.exe*", "*\\SysWOW64\\winlogon.exe*") AND GrantedAccess = 0x1040 AND NOT (SourceImage IN("C:\\Windows\\*", "C:\\Program File*", "%systemroot%\\*")) | stats count min(_time) as firstTime max(_time) as - lastTime by Computer SourceImage TargetImage SourceProcessGUID TargetProcessGUID SourceProcessId - TargetProcessId GrantedAccess CallTrace | rename Computer as dest| `security_content_ctime(firstTime)` | - `security_content_ctime(lastTime)` | `windows_access_token_winlogon_duplicate_handle_in_uncommon_path_filter`' + lastTime by Computer SourceImage TargetImage SourceProcessGUID TargetProcessGUID + SourceProcessId TargetProcessId GrantedAccess CallTrace | rename Computer as dest| + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_access_token_winlogon_duplicate_handle_in_uncommon_path_filter`' how_to_implement: To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 @@ -35,7 +36,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A process $SourceImage$ is duplicating the handle token of winlogon.exe on $dest$ + message: A process $SourceImage$ is duplicating the handle token of winlogon.exe + on $dest$ mitre_attack_id: - T1134.001 - T1134 @@ -69,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/brute_duplicate_token/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/brute_duplicate_token/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_account_discovery_for_none_disable_user_account.yml b/detections/endpoint/windows_account_discovery_for_none_disable_user_account.yml index 64babf75f4..c4aadd207c 100644 --- a/detections/endpoint/windows_account_discovery_for_none_disable_user_account.yml +++ b/detections/endpoint/windows_account_discovery_for_none_disable_user_account.yml @@ -1,26 +1,30 @@ name: Windows Account Discovery for None Disable User Account id: eddbf5ba-b89e-47ca-995e-2d259804e55e -version: 2 -date: '2023-12-15' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Powershell Script Block Logging 4104 -description: The following analytic utilizes PowerShell Script Block Logging to identify - the execution of the PowerView PowerShell commandlet Get-NetUser. In the context - of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory - user accounts that are not disabled. The full script block text based on the CISA-23-347A advisory is "Get-NetUser -UACFilter NOT_ACCOUNTDISABLE". Utilize this query to identify potential suspicious activity of user account enumeration. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText = "*NOT_ACCOUNTDISABLE*" ScriptBlockText = "*-UACFilter*" - | rename Computer as dest, UserID as user - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of the PowerView PowerShell + cmdlet Get-NetUser with the UACFilter parameter set to NOT_ACCOUNTDISABLE, indicating + an attempt to enumerate Active Directory user accounts that are not disabled. This + detection leverages PowerShell Script Block Logging (EventCode 4104) to identify + the specific script block text. Monitoring this activity is significant as it may + indicate reconnaissance efforts by an attacker to identify active user accounts + for further exploitation. If confirmed malicious, this activity could lead to unauthorized + access, privilege escalation, or lateral movement within the network. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText + = "*NOT_ACCOUNTDISABLE*" ScriptBlockText = "*-UACFilter*" | rename Computer as dest, + UserID as user | stats count min(_time) as firstTime max(_time) as lastTime by EventCode + ScriptBlockText dest user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_account_discovery_for_none_disable_user_account_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Administrators may leverage PowerView for legitimate purposes, filter as needed. +known_false_positives: Administrators may leverage PowerView for legitimate purposes, + filter as needed. references: - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a - https://powersploit.readthedocs.io/en/stable/Recon/README/ @@ -32,7 +36,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 30 - message: Windows Account Discovery for None Disable User Account using PowerView's Get-NetUser on $dest$. + message: Windows Account Discovery for None Disable User Account using PowerView's + Get-NetUser on $dest$. mitre_attack_id: - T1087 - T1087.001 @@ -56,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_account_discovery_for_sam_account_name.yml b/detections/endpoint/windows_account_discovery_for_sam_account_name.yml index 670cd298ad..2701339e68 100644 --- a/detections/endpoint/windows_account_discovery_for_sam_account_name.yml +++ b/detections/endpoint/windows_account_discovery_for_sam_account_name.yml @@ -1,26 +1,30 @@ name: Windows Account Discovery for Sam Account Name id: 69934363-e1dd-4c49-8651-9d7663dd4d2f -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Powershell Script Block Logging 4104 -description: The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. - In the context of PowerView's Get-NetUser cmdlet as a filter or parameter - to query Active Directory user account's "samccountname". This hunting query is a good pivot to look for suspicious process - or malware that gather user account information in a host or within network system. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText IN ("*samaccountname*", "*pwdlastset*") - | rename Computer as dest, UserID as user - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of the PowerView PowerShell + cmdlet Get-NetUser, specifically querying for "samaccountname" and "pwdlastset" + attributes. It leverages Event ID 4104 from PowerShell Script Block Logging to identify + this activity. This behavior is significant as it may indicate an attempt to gather + user account information from Active Directory, which is a common reconnaissance + step in lateral movement or privilege escalation attacks. If confirmed malicious, + this activity could allow an attacker to map out user accounts, potentially leading + to further exploitation and unauthorized access within the network. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText + IN ("*samaccountname*", "*pwdlastset*") | rename Computer as dest, UserID as user + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + dest user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_account_discovery_for_sam_account_name_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Administrators may leverage PowerView for legitimate purposes, filter as needed. +known_false_positives: Administrators may leverage PowerView for legitimate purposes, + filter as needed. references: - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a tags: @@ -52,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_account_discovery_with_netuser_preauthnotrequire.yml b/detections/endpoint/windows_account_discovery_with_netuser_preauthnotrequire.yml index a87b2c702e..6545581668 100644 --- a/detections/endpoint/windows_account_discovery_with_netuser_preauthnotrequire.yml +++ b/detections/endpoint/windows_account_discovery_with_netuser_preauthnotrequire.yml @@ -1,26 +1,29 @@ name: Windows Account Discovery With NetUser PreauthNotRequire id: cf056b65-44b2-4d32-9172-d6b6f081a376 -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Powershell Script Block Logging 4104 -description: The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. - This technique was observed in the context of PowerView's Get-NetUser cmdlet as a filter or parameter - to query Active Directory user accounts that do not require preauthentication for Kerberos. This hunting query is a good pivot to look for suspicious process - or malware that gather user account information in a host or within network system. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText = "*-PreauthNotRequire*" - | rename Computer as dest, UserID as user - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of the PowerView PowerShell + cmdlet Get-NetUser with the -PreauthNotRequire parameter, leveraging Event ID 4104. + This method identifies attempts to query Active Directory user accounts that do + not require Kerberos preauthentication. Monitoring this activity is crucial as it + can indicate reconnaissance efforts by an attacker to identify potentially vulnerable + accounts. If confirmed malicious, this behavior could lead to further exploitation, + such as unauthorized access or privilege escalation within the network. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetUser*" ScriptBlockText + = "*-PreauthNotRequire*" | rename Computer as dest, UserID as user | stats count + min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest + user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_account_discovery_with_netuser_preauthnotrequire_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Administrators may leverage PowerView for legitimate purposes, filter as needed. +known_false_positives: Administrators may leverage PowerView for legitimate purposes, + filter as needed. references: - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a tags: @@ -29,7 +32,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 30 - message: A user dicovery using powerview commandlet Get-NetUser with PreauthNotRequire parameter on $dest$. + message: A user dicovery using powerview commandlet Get-NetUser with PreauthNotRequire + parameter on $dest$. mitre_attack_id: - T1087 observable: @@ -52,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_adminsdholder_acl_modified.yml b/detections/endpoint/windows_ad_adminsdholder_acl_modified.yml index c68b7b90b2..b78653d7b2 100644 --- a/detections/endpoint/windows_ad_adminsdholder_acl_modified.yml +++ b/detections/endpoint/windows_ad_adminsdholder_acl_modified.yml @@ -1,26 +1,30 @@ name: Windows AD AdminSDHolder ACL Modified id: 00d877c3-7b7b-443d-9562-6b231e2abab9 -version: 1 -date: '2022-11-15' +version: 2 +date: '2024-05-13' author: Mauricio Velazco, Splunk type: TTP status: production -data_source: +data_source: - Windows Event Log Security 5136 -description: The following analytic identifies the modification of the Access Control List for the AdminSDHolder object within a Windows domain. Specifically, the - detection triggers on the addition of a new rule to the existing ACL. AdminSDHolder is an object located in the System Partition in Active Directory and is used as a - security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that dont - match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object - Access Control List (ACL) with the security permissions set on the AdminSDHolder. An adversary who has obtained privileged access to a Windows Domain may modify the AdminSDHolder - ACL to establish persistence and allow an unprivileged user to take control of a domain. -search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=nTSecurityDescriptor OperationType="%%14674" ObjectDN="CN=AdminSDHolder,CN=System*" - | rex field=AttributeValue max_match=10000 "A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;(?PS-1-[0-59]-\d{2}-\d{8,10}-\d{8,10}-\d{8,10}-[1-9]\d{3})\)" - | stats values(added_user_sid) by _time, Computer, SubjectUserName, ObjectDN - | `windows_ad_adminsdholder_acl_modified_filter`' -how_to_implement: To successfully implement this search, you ned to be ingesting eventcode - `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for the AdminSDHolder object in order to log modifications. -known_false_positives: Adding new users or groups to the AdminSDHolder ACL is not usual. Filter as needed +description: The following analytic detects modifications to the Access Control List + (ACL) of the AdminSDHolder object in a Windows domain, specifically the addition + of new rules. It leverages EventCode 5136 from the Security Event Log, focusing + on changes to the nTSecurityDescriptor attribute. This activity is significant because + the AdminSDHolder object secures privileged group members, and unauthorized changes + can allow attackers to establish persistence and escalate privileges. If confirmed + malicious, this could enable an attacker to control domain-level permissions, compromising + the entire Active Directory environment. +search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=nTSecurityDescriptor + OperationType="%%14674" ObjectDN="CN=AdminSDHolder,CN=System*" | rex field=AttributeValue + max_match=10000 "A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;(?PS-1-[0-59]-\d{2}-\d{8,10}-\d{8,10}-\d{8,10}-[1-9]\d{3})\)" + | stats values(added_user_sid) by _time, Computer, SubjectUserName, ObjectDN | `windows_ad_adminsdholder_acl_modified_filter`' +how_to_implement: To successfully implement this search, you ned to be ingesting eventcode + `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` + within `DS Access` needs to be enabled. Additionally, a SACL needs to be created + for the AdminSDHolder object in order to log modifications. +known_false_positives: Adding new users or groups to the AdminSDHolder ACL is not + usual. Filter as needed references: - https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory - https://social.technet.microsoft.com/wiki/contents/articles/22331.adminsdholder-protected-groups-and-security-descriptor-propagator.aspx @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546/adminsdholder_modified/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546/adminsdholder_modified/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_cross_domain_sid_history_addition.yml b/detections/endpoint/windows_ad_cross_domain_sid_history_addition.yml index 05141f0b5a..d5a0b0fbd1 100644 --- a/detections/endpoint/windows_ad_cross_domain_sid_history_addition.yml +++ b/detections/endpoint/windows_ad_cross_domain_sid_history_addition.yml @@ -1,28 +1,32 @@ name: Windows AD Cross Domain SID History Addition id: 41bbb371-28ba-439c-bb5c-d9930c28365d -version: 1 -date: '2022-11-17' +version: 2 +date: '2024-05-11' author: Dean Luxton type: TTP status: production -data_source: +data_source: - Windows Event Log Security 4742 - Windows Event Log Security 4738 -description: The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects within different domains. - The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access - continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries for inter-domain privilege escalation and persistence. -search: '`wineventlog_security` (EventCode=4742 OR EventCode=4738) NOT SidHistory IN ("%%1793", -) - | rex field=SidHistory "(^%{|^)(?P.*)(\-|\\\)" - | rex field=TargetSid "^(?P.*)(\-|\\\)" - | where SidHistoryMatch!=TargetSidmatch AND SidHistoryMatch!=TargetDomainName - | rename TargetSid as userSid - | table _time action status host user userSid SidHistory Logon_ID src_user - | `windows_ad_cross_domain_sid_history_addition_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcodes - `4738` and `4742`. The Advanced Security Audit policy settings - `Audit User Account Management` and `Audit Computer Account Management` - within `Account Management` all need to be enabled. -known_false_positives: Domain mergers and migrations may generate large volumes of false positives for this analytic. +description: The following analytic detects changes to the sIDHistory attribute of + user or computer objects across different domains. It leverages Windows Security + Event Codes 4738 and 4742 to identify when the sIDHistory attribute is modified. + This activity is significant because the sIDHistory attribute allows users to inherit + permissions from other AD accounts, which can be exploited by adversaries for inter-domain + privilege escalation and persistence. If confirmed malicious, this could enable + attackers to gain unauthorized access to resources, maintain persistence, and escalate + privileges across domain boundaries. +search: '`wineventlog_security` (EventCode=4742 OR EventCode=4738) NOT SidHistory + IN ("%%1793", -) | rex field=SidHistory "(^%{|^)(?P.*)(\-|\\\)" + | rex field=TargetSid "^(?P.*)(\-|\\\)" | where SidHistoryMatch!=TargetSidmatch + AND SidHistoryMatch!=TargetDomainName | rename TargetSid as userSid | table _time + action status host user userSid SidHistory Logon_ID src_user | `windows_ad_cross_domain_sid_history_addition_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit + User Account Management` and `Audit Computer Account Management` within `Account + Management` all need to be enabled. +known_false_positives: Domain mergers and migrations may generate large volumes of + false positives for this analytic. references: - https://adsecurity.org/?p=1772 - https://learn.microsoft.com/en-us/windows/win32/adschema/a-sidhistory?redirectedfrom=MSDN @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_domain_controller_audit_policy_disabled.yml b/detections/endpoint/windows_ad_domain_controller_audit_policy_disabled.yml index e209fc63c9..10b933d2aa 100644 --- a/detections/endpoint/windows_ad_domain_controller_audit_policy_disabled.yml +++ b/detections/endpoint/windows_ad_domain_controller_audit_policy_disabled.yml @@ -1,13 +1,20 @@ name: Windows AD Domain Controller Audit Policy Disabled id: fc3ccef1-60a4-4239-bd66-b279511b4d14 -version: 1 -date: '2023-01-26' +version: 2 +date: '2024-05-12' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4719 -description: The following analytic detects the disabling of audit policies on a domain controller. The detection is made by identifying changes made to audit policies and checks for the removal of success or failure auditing, which are common indicators of policy tampering. The detection is important because it indicates that an attacker has gained access to the domain controller and is attempting to evade detection and cover up malicious activity. The impact of such an attack can be severe, including data theft, privilege escalation, and compromise of the entire network. False positives might occur since legitimate changes to audit policies might also trigger the analytic. Upon triage, review the audit policy change event and investigate the source of the change. Additionally, you must capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the attack source." +description: The following analytic detects the disabling of audit policies on a domain + controller. It leverages EventCode 4719 from Windows Security Event Logs to identify + changes where success or failure auditing is removed. This activity is significant + as it suggests an attacker may have gained access to the domain controller and is + attempting to evade detection by tampering with audit policies. If confirmed malicious, + this could lead to severe consequences, including data theft, privilege escalation, + and full network compromise. Immediate investigation is required to determine the + source and intent of the change. search: '`wineventlog_security` EventCode=4719 (AuditPolicyChanges IN ("%%8448","%%8450","%%8448, %%8450") OR Changes IN ("Failure removed","Success removed","Success removed, Failure removed")) dest_category="domain_controller"| replace "%%8448" with "Success removed", @@ -53,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable_gpo/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable_gpo/windows-security-xml.log source: XmlWinEventLog:Security sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_domain_controller_promotion.yml b/detections/endpoint/windows_ad_domain_controller_promotion.yml index 205f4feffd..43fd9e1f94 100644 --- a/detections/endpoint/windows_ad_domain_controller_promotion.yml +++ b/detections/endpoint/windows_ad_domain_controller_promotion.yml @@ -1,21 +1,34 @@ name: Windows AD Domain Controller Promotion id: e633a0ef-2a6e-4ed7-b925-5ff999e5d1f0 -version: 1 -date: '2023-01-26' +version: 2 +date: '2024-05-18' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4742 -description: This analytic identifies a genuine DC promotion event. Identifying when a computer assigns itself the - necessary SPNs to function as a domain controller. Note these events are triggered on the existing domain controllers, not the newly - joined domain controller. This detection will serve to identify rogue DCs added to the network. There are 2x detections within this analytic story - which identify DCShadow attacks, if you do not currently possess the logging for these detections, remove the where clause within this - detection to identify DCShadow activity. -search: "`wineventlog_security` EventCode=4742 ServicePrincipalNames IN (\"*E3514235-4B06-11D1-AB04-00C04FC2DCD2/*\",\"*GC/*\")| stats min(_time) as _time latest(ServicePrincipalNames) as ServicePrincipalNames,values(signature) as signature, values(src_user) as src_user, values(user) as user by Logon_ID, dvc| where src_user=user| rename Logon_ID as TargetLogonId, user as dest | appendpipe [| map search=\"search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$\" | fields - dest, dvc, signature]| stats min(_time) as _time, values(TargetUserSid) as TargetUserSid, values(Target_Domain) as Target_Domain, values(user) as user, values(status) as status, values(src_category) as src_category, values(src_ip) as src_ip values(ServicePrincipalNames) as ServicePrincipalNames values(signature) as signature values(dest) as dest values(dvc) as dvc by TargetLogonId | eval dest=trim(dest,\"$\") | `windows_ad_domain_controller_promotion_filter`" -how_to_implement: To successfully implement this search, you need to be ingesting eventcode - `4742`. The Advanced Security Audit policy setting `Audit Computer Account Management` - within `Account Management` needs to be enabled. +description: The following analytic identifies a genuine Domain Controller (DC) promotion + event by detecting when a computer assigns itself the necessary Service Principal + Names (SPNs) to function as a domain controller. It leverages Windows Security Event + Code 4742 to monitor existing domain controllers for these changes. This activity + is significant as it can help identify rogue DCs added to the network, which could + indicate a DCShadow attack. If confirmed malicious, this could allow an attacker + to manipulate Active Directory, leading to potential privilege escalation and persistent + access within the environment. +search: "`wineventlog_security` EventCode=4742 ServicePrincipalNames IN (\"*E3514235-4B06-11D1-AB04-00C04FC2DCD2/*\"\ + ,\"*GC/*\")| stats min(_time) as _time latest(ServicePrincipalNames) as ServicePrincipalNames,values(signature) + as signature, values(src_user) as src_user, values(user) as user by Logon_ID, dvc| + where src_user=user| rename Logon_ID as TargetLogonId, user as dest | appendpipe + [| map search=\"search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$\"\ + \ | fields - dest, dvc, signature]| stats min(_time) as _time, values(TargetUserSid) + as TargetUserSid, values(Target_Domain) as Target_Domain, values(user) as user, + values(status) as status, values(src_category) as src_category, values(src_ip) as + src_ip values(ServicePrincipalNames) as ServicePrincipalNames values(signature) + as signature values(dest) as dest values(dvc) as dvc by TargetLogonId | eval dest=trim(dest,\"\ + $\") | `windows_ad_domain_controller_promotion_filter`" +how_to_implement: To successfully implement this search, you need to be ingesting + eventcode `4742`. The Advanced Security Audit policy setting `Audit Computer Account + Management` within `Account Management` needs to be enabled. known_false_positives: None. references: - https://attack.mitre.org/techniques/T1207/ @@ -23,8 +36,8 @@ tags: analytic_story: - Sneaky Active Directory Persistence Tricks asset_type: Endpoint - confidence: 100 - impact: 80 + confidence: 100 + impact: 80 message: AD Domain Controller Promotion Event Detected for $dest$ mitre_attack_id: - T1207 @@ -50,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/dc_promo/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/dc_promo/windows-security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_domain_replication_acl_addition.yml b/detections/endpoint/windows_ad_domain_replication_acl_addition.yml index 91eab3b69d..0be1143257 100644 --- a/detections/endpoint/windows_ad_domain_replication_acl_addition.yml +++ b/detections/endpoint/windows_ad_domain_replication_acl_addition.yml @@ -1,70 +1,84 @@ name: Windows AD Domain Replication ACL Addition id: 8c372853-f459-4995-afdc-280c114d33ab -version: 1 -date: "2022-11-18" +version: 2 +date: "2024-05-16" author: Dean Luxton type: TTP status: experimental data_source: [] -description: - The following analytic detects the addition of the permissions necessary to perform a DCSync attack. - In order to replicate AD objects, the initiating user or computer must have the following permissions on the domain. - - DS-Replication-Get-Changes - - DS-Replication-Get-Changes-All - Certain Sync operations may require the additional permission of DS-Replication-Get-Changes-In-Filtered-Set. - By default, adding DCSync permissions via the Powerview Add-ObjectACL operation adds all 3. This alert identifies where this trifecta has been met, and also where just the base level requirements have been met. -search: '`wineventlog_security` | rex field=AttributeValue max_match=10000 \"OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;(?PS-1-[0-59]-\d{2}-\d{8,10}-\d{8,10}-\d{8,10}-[1-9]\d{3})\)\"| table _time dest src_user DSRGetChanges_user_sid DSRGetChangesAll_user_sid DSRGetChangesFiltered_user_sid| mvexpand DSRGetChanges_user_sid| eval minDCSyncPermissions=if(DSRGetChanges_user_sid=DSRGetChangesAll_user_sid,\"true\",\"false\"), fullSet=if(DSRGetChanges_user_sid=DSRGetChangesAll_user_sid AND DSRGetChanges_user_sid=DSRGetChangesFiltered_user_sid,\"true\",\"false\")| where minDCSyncPermissions=\"true\" | lookup identity_lookup_expanded objectSid as DSRGetChanges_user_sid OUTPUT sAMAccountName as user | rename DSRGetChanges_user_sid as userSid | stats min(_time) as _time values(user) as user by dest src_user userSid minDCSyncPermissions fullSet| `windows_ad_domain_replication_acl_addition_filter`' -how_to_implement: - To successfully implement this search, you need to be ingesting the eventcode 5136. The Advanced Security Audit policy setting - `Audit Directory Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` to `Write All Properties` - applied to the domain root and all descendant objects. Once the necessary logging has been enabled, enumerate the domain policy to verify if existing - accounts with access need to be whitelisted, or revoked. Assets and Identities is also leveraged to automatically translate the objectSid into username. - Ensure your identities lookup is configured with the sAMAccountName and objectSid of all AD user and computer objects. -known_false_positives: - When there is a change to nTSecurityDescriptor, Windows logs the entire ACL with the newly added components. - If existing accounts are present with this permission, they will raise an alert each time the nTSecurityDescriptor is updated unless whitelisted. +description: The following analytic detects the addition of permissions required for + a DCSync attack, specifically DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, + and DS-Replication-Get-Changes-In-Filtered-Set. It leverages EventCode 5136 from + the Windows Security Event Log to identify when these permissions are granted. This + activity is significant because it indicates potential preparation for a DCSync + attack, which can be used to replicate AD objects and exfiltrate sensitive data. + If confirmed malicious, an attacker could gain extensive access to Active Directory, + leading to severe data breaches and privilege escalation. +search: '`wineventlog_security` | rex field=AttributeValue max_match=10000 \"OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;(?PS-1-[0-59]-\d{2}-\d{8,10}-\d{8,10}-\d{8,10}-[1-9]\d{3})\)\"| + table _time dest src_user DSRGetChanges_user_sid DSRGetChangesAll_user_sid DSRGetChangesFiltered_user_sid| + mvexpand DSRGetChanges_user_sid| eval minDCSyncPermissions=if(DSRGetChanges_user_sid=DSRGetChangesAll_user_sid,\"true\",\"false\"), + fullSet=if(DSRGetChanges_user_sid=DSRGetChangesAll_user_sid AND DSRGetChanges_user_sid=DSRGetChangesFiltered_user_sid,\"true\",\"false\")| + where minDCSyncPermissions=\"true\" | lookup identity_lookup_expanded objectSid + as DSRGetChanges_user_sid OUTPUT sAMAccountName as user | rename DSRGetChanges_user_sid + as userSid | stats min(_time) as _time values(user) as user by dest src_user userSid + minDCSyncPermissions fullSet| `windows_ad_domain_replication_acl_addition_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + the eventcode 5136. The Advanced Security Audit policy setting `Audit Directory + Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` + to `Write All Properties` applied to the domain root and all descendant objects. + Once the necessary logging has been enabled, enumerate the domain policy to verify + if existing accounts with access need to be whitelisted, or revoked. Assets and + Identities is also leveraged to automatically translate the objectSid into username. + Ensure your identities lookup is configured with the sAMAccountName and objectSid + of all AD user and computer objects. +known_false_positives: When there is a change to nTSecurityDescriptor, Windows logs + the entire ACL with the newly added components. If existing accounts are present + with this permission, they will raise an alert each time the nTSecurityDescriptor + is updated unless whitelisted. references: - - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb - - https://github.com/SigmaHQ/sigma/blob/29a5c62784faf986dc03952ae3e90e3df3294284/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml +- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb +- https://github.com/SigmaHQ/sigma/blob/29a5c62784faf986dc03952ae3e90e3df3294284/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml tags: analytic_story: - - Sneaky Active Directory Persistence Tricks + - Sneaky Active Directory Persistence Tricks asset_type: Endpoint confidence: 80 impact: 100 message: $src_user$ has granted $user$ permission to replicate AD objects mitre_attack_id: - - T1484 + - T1484 observable: - - name: user - type: User - role: - - Victim - - name: src_user - type: User - role: - - Victim - - name: dest - type: Hostname - role: - - Victim + - name: user + type: User + role: + - Victim + - name: src_user + type: User + role: + - Victim + - name: dest + type: Hostname + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - dest - - src_user - - AttributeLDAPDisplayName - - AttributeValue - - ObjectClass + - _time + - dest + - src_user + - AttributeLDAPDisplayName + - AttributeValue + - ObjectClass risk_score: 80 security_domain: endpoint - manual_test: This search uses a lookup provided by Enterprise Security and needs to be manually tested. + manual_test: This search uses a lookup provided by Enterprise Security and needs + to be manually tested. tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484/aclmodification/windows-security-xml.log - source: XmlWinEventLog:Security - sourcetype: xmlwineventlog +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484/aclmodification/windows-security-xml.log + source: XmlWinEventLog:Security + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_dsrm_account_changes.yml b/detections/endpoint/windows_ad_dsrm_account_changes.yml index 90663061d2..6d87eae63b 100644 --- a/detections/endpoint/windows_ad_dsrm_account_changes.yml +++ b/detections/endpoint/windows_ad_dsrm_account_changes.yml @@ -1,28 +1,31 @@ name: Windows AD DSRM Account Changes id: 08cb291e-ea77-48e8-a95a-0799319bf056 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-24' author: Dean Luxton type: TTP status: production data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: Aside from being used to promote genuine domain controllers, the DSRM - (Directory Services Restore Mode) account can be used to persist within a Domain. - A DC can be configured to allow the DSRM account to logon & be used in the same - way as a local administrator account. This detection is looking for alterations - to the behaviour of the account via registry. +description: The following analytic identifies changes to the Directory Services Restore + Mode (DSRM) account behavior via registry modifications. It detects alterations + in the registry path "*\\System\\CurrentControlSet\\Control\\Lsa\\DSRMAdminLogonBehavior" + with specific values indicating potential misuse. This activity is significant because + the DSRM account, if misconfigured, can be exploited to persist within a domain, + similar to a local administrator account. If confirmed malicious, an attacker could + gain persistent administrative access to a Domain Controller, leading to potential + domain-wide compromise and unauthorized access to sensitive information. search: '| tstats `security_content_summariesonly` min(_time) as _time from datamodel=Endpoint.Registry where Registry.registry_path= "*\\System\\CurrentControlSet\\Control\\Lsa\\DSRMAdminLogonBehavior" Registry.registry_value_data IN ("*1","*2") by Registry.action Registry.registry_path - Registry.registry_value_data Registry.registry_value_type Registry.process_guid Registry.dest Registry.user - | `drop_dm_object_name(Registry)` | join type=outer process_guid [| tstats `security_content_summariesonly` - count FROM datamodel=Endpoint.Processes by Processes.user Processes.process_name - Processes.process Processes.dest Processes.parent_process_name Processes.parent_process - Processes.process_guid | `drop_dm_object_name(Processes)`] | table _time action - dest user parent_process_name parent_process process_name process process_guid registry_path - registry_value_data registry_value_type | `windows_ad_dsrm_account_changes_filter`' + Registry.registry_value_data Registry.registry_value_type Registry.process_guid + Registry.dest Registry.user | `drop_dm_object_name(Registry)` | join type=outer + process_guid [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes + by Processes.user Processes.process_name Processes.process Processes.dest Processes.parent_process_name + Processes.parent_process Processes.process_guid | `drop_dm_object_name(Processes)`] + | table _time action dest user parent_process_name parent_process process_name process + process_guid registry_path registry_value_data registry_value_type | `windows_ad_dsrm_account_changes_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -70,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dsrm_account/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dsrm_account/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_dsrm_password_reset.yml b/detections/endpoint/windows_ad_dsrm_password_reset.yml index b4611939fe..6afb115e79 100644 --- a/detections/endpoint/windows_ad_dsrm_password_reset.yml +++ b/detections/endpoint/windows_ad_dsrm_password_reset.yml @@ -1,24 +1,30 @@ name: Windows AD DSRM Password Reset id: d1ab841c-36a6-46cf-b50f-b2b04b31182a -version: 1 -date: '2022-09-08' +version: 2 +date: '2024-05-12' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4794 -description: Aside from being used to promote genuine domain controllers, the DSRM (Directory Services Restore Mode) - account can be used to persist within a Domain. A DC can be configured to allow the DSRM account to logon & be - used in the same way as a local administrator account. This detection is looking for any password reset attempts against that account. +description: The following analytic detects attempts to reset the Directory Services + Restore Mode (DSRM) administrator password on a Domain Controller. It leverages + event code 4794 from the Windows Security Event Log, specifically looking for events + where the DSRM password reset is attempted. This activity is significant because + the DSRM account can be used similarly to a local administrator account, providing + potential persistence for an attacker. If confirmed malicious, this could allow + an attacker to maintain administrative access to the Domain Controller, posing a + severe risk to the domain's security. search: '| tstats `security_content_summariesonly` min(_time) as _time from datamodel=Change where All_Changes.result_id="4794" AND All_Changes.result="An attempt was made to - set the Directory Services Restore Mode administrator password" by All_Changes.action, - All_Changes.dest, All_Changes.src, All_Changes.user - | `drop_dm_object_name(All_Changes)` | `windows_ad_dsrm_password_reset_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcode - `4794` and have the Advanced Security Audit policy - `Audit User Account Management` within `Account Management` enabled. -known_false_positives: Resetting the DSRM password for legitamate reasons, i.e. forgot the password. Disaster recovery. Deploying AD backdoor deliberately. + set the Directory Services Restore Mode administrator password" by All_Changes.action, + All_Changes.dest, All_Changes.src, All_Changes.user | `drop_dm_object_name(All_Changes)` + | `windows_ad_dsrm_password_reset_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + eventcode `4794` and have the Advanced Security Audit policy `Audit User Account + Management` within `Account Management` enabled. +known_false_positives: Resetting the DSRM password for legitamate reasons, i.e. forgot + the password. Disaster recovery. Deploying AD backdoor deliberately. references: - https://adsecurity.org/?p=1714 tags: @@ -56,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dsrm_account/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dsrm_account/windows-security-xml.log source: XmlWinEventLog:Security - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_privileged_account_sid_history_addition.yml b/detections/endpoint/windows_ad_privileged_account_sid_history_addition.yml index 01d8943395..471e1d7456 100644 --- a/detections/endpoint/windows_ad_privileged_account_sid_history_addition.yml +++ b/detections/endpoint/windows_ad_privileged_account_sid_history_addition.yml @@ -1,71 +1,71 @@ name: Windows AD Privileged Account SID History Addition id: 6b521149-b91c-43aa-ba97-c2cac59ec830 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-26' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4742 - Windows Event Log Security 4738 -description: - This detection identifies when the SID of a privileged user is added to - the SID History attribute of another user. Useful for tracking SID history abuse - across multiple domains. This detection leverages the Asset and Identities - framework. See the implementation section for further details on configuration. -search: - '`wineventlog_security` (EventCode=4742 OR EventCode=4738) NOT SidHistory IN ("%%1793", -) - | rex field=SidHistory "(^%{|^)(?P.*?)(}$|$)" - | eval category="privileged" - | lookup identity_lookup_expanded category, identity as SidHistory OUTPUT identity_tag as match - | where isnotnull(match) - | rename TargetSid as userSid - | table _time action status host user userSid SidHistory Logon_ID src_user - | `windows_ad_privileged_account_sid_history_addition_filter`' -how_to_implement: - Ensure you have objectSid and the Down Level Logon Name `DOMAIN\sAMACountName` +description: The following analytic identifies when the SID of a privileged user is + added to the SID History attribute of another user. It leverages Windows Security + Event Codes 4742 and 4738, combined with identity lookups, to detect this activity. + This behavior is significant as it may indicate an attempt to abuse SID history + for unauthorized access across multiple domains. If confirmed malicious, this activity + could allow an attacker to escalate privileges or maintain persistent access within + the environment, posing a significant security risk. +search: '`wineventlog_security` (EventCode=4742 OR EventCode=4738) NOT SidHistory + IN ("%%1793", -) | rex field=SidHistory "(^%{|^)(?P.*?)(}$|$)" | eval + category="privileged" | lookup identity_lookup_expanded category, identity as SidHistory + OUTPUT identity_tag as match | where isnotnull(match) | rename TargetSid as userSid + | table _time action status host user userSid SidHistory Logon_ID src_user | `windows_ad_privileged_account_sid_history_addition_filter`' +how_to_implement: Ensure you have objectSid and the Down Level Logon Name `DOMAIN\sAMACountName` added to the identity field of your Asset and Identities lookup, along with the - category of privileged for the applicable users. Ensure you are - ingesting eventcodes 4742 and 4738. Two advanced audit policies - `Audit User Account Management` and `Audit Computer Account Management` under - `Account Management` are required to generate these event codes. + category of privileged for the applicable users. Ensure you are ingesting eventcodes + 4742 and 4738. Two advanced audit policies `Audit User Account Management` and `Audit + Computer Account Management` under `Account Management` are required to generate + these event codes. known_false_positives: Migration of privileged accounts. references: - - https://adsecurity.org/?p=1772 +- https://adsecurity.org/?p=1772 tags: analytic_story: - - Sneaky Active Directory Persistence Tricks + - Sneaky Active Directory Persistence Tricks asset_type: Endpoint confidence: 90 impact: 100 - message: A Privileged User Account SID History Attribute was added to $userSid$ by $src_user$ + message: A Privileged User Account SID History Attribute was added to $userSid$ + by $src_user$ mitre_attack_id: - - T1134.005 - - T1134 + - T1134.005 + - T1134 observable: - - name: src_user - type: User - role: - - Victim + - name: src_user + type: User + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - EventCode - - SidHistory - - TargetSid - - TargetDomainName - - user - - src_user - - Logon_ID + - _time + - EventCode + - SidHistory + - TargetSid + - TargetDomainName + - user + - src_user + - Logon_ID risk_score: 90 security_domain: endpoint - manual_test: This search uses a lookup provided by Enterprise Security and needs to be manually tested. + manual_test: This search uses a lookup provided by Enterprise Security and needs + to be manually tested. tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log - source: XmlWinEventLog:Security - sourcetype: xmlwineventlog +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log + source: XmlWinEventLog:Security + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_ad_privileged_object_access_activity.yml b/detections/endpoint/windows_ad_privileged_object_access_activity.yml index e365da2754..fde48019ed 100644 --- a/detections/endpoint/windows_ad_privileged_object_access_activity.yml +++ b/detections/endpoint/windows_ad_privileged_object_access_activity.yml @@ -1,44 +1,38 @@ name: Windows AD Privileged Object Access Activity id: dc2f58bc-8cd2-4e51-962a-694b963acde0 -version: 1 -date: '2023-06-01' +version: 2 +date: '2024-05-18' author: Steven Dick status: production type: TTP -description: Windows Active Directory contains numerous objects that grant elevated access to the domain they reside in. These objects should be rarely accessed by normal users or processes. Access attempts to one or more of these objects may be evidence of attacker enumeration of Active Directory. +description: The following analytic detects access attempts to privileged Active Directory + objects, such as Domain Admins or Enterprise Admins. It leverages Windows Security + Event Code 4662 to identify when these sensitive objects are accessed. This activity + is significant because such objects should rarely be accessed by normal users or + processes, and unauthorized access attempts may indicate attacker enumeration or + lateral movement within the domain. If confirmed malicious, this activity could + allow attackers to escalate privileges, persist in the environment, or gain control + over critical domain resources. data_source: - Windows Event Log Security 4662 -search: '`wineventlog_security` EventCode=4662 ObjectName IN ( -"CN=Account Operators,*", -"CN=Administrators,*", -"CN=Backup Operators,*", -"CN=Cert Publishers,*", -"CN=Certificate Service DCOM Access,*", -"CN=Domain Admins,*", -"CN=Domain Controllers,*", -"CN=Enterprise Admins,*", -"CN=Enterprise Read-only Domain Controllers,*", -"CN=Group Policy Creator Owners,*", -"CN=Incoming Forest Trust Builders,*", -"CN=Microsoft Exchange Servers,*", -"CN=Network Configuration Operators,*", -"CN=Power Users,*", -"CN=Print Operators,*", -"CN=Read-only Domain Controllers,*", -"CN=Replicators,*", -"CN=Schema Admins,*", -"CN=Server Operators,*", -"CN=Exchange Trusted Subsystem,*", -"CN=Exchange Windows Permission,*", -"CN=Organization Management,*") -| rex field=ObjectName "CN\=(?[^,]+)" -| stats values(Computer) as dest, values(object_name) as object_name, dc(ObjectName) as object_count, min(_time) as firstTime, max(_time) as lastTime, count by SubjectUserName -| rename SubjectUserName as user -| `security_content_ctime(firstTime)` -| `security_content_ctime(lastTime)` -| `windows_ad_privileged_object_access_activity_filter`' -how_to_implement: Enable Audit Directory Service Access via GPO and collect event code 4662. The required SACLs need to be created for the relevant objects. Be aware Splunk filters this event by default on the Windows TA. -known_false_positives: Service accounts or applications that routinely query Active Directory for information. +search: '`wineventlog_security` EventCode=4662 ObjectName IN ( "CN=Account Operators,*", + "CN=Administrators,*", "CN=Backup Operators,*", "CN=Cert Publishers,*", "CN=Certificate + Service DCOM Access,*", "CN=Domain Admins,*", "CN=Domain Controllers,*", "CN=Enterprise + Admins,*", "CN=Enterprise Read-only Domain Controllers,*", "CN=Group Policy Creator + Owners,*", "CN=Incoming Forest Trust Builders,*", "CN=Microsoft Exchange Servers,*", + "CN=Network Configuration Operators,*", "CN=Power Users,*", "CN=Print Operators,*", + "CN=Read-only Domain Controllers,*", "CN=Replicators,*", "CN=Schema Admins,*", "CN=Server + Operators,*", "CN=Exchange Trusted Subsystem,*", "CN=Exchange Windows Permission,*", + "CN=Organization Management,*") | rex field=ObjectName "CN\=(?[^,]+)" + | stats values(Computer) as dest, values(object_name) as object_name, dc(ObjectName) + as object_count, min(_time) as firstTime, max(_time) as lastTime, count by SubjectUserName + | rename SubjectUserName as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_ad_privileged_object_access_activity_filter`' +how_to_implement: Enable Audit Directory Service Access via GPO and collect event + code 4662. The required SACLs need to be created for the relevant objects. Be aware + Splunk filters this event by default on the Windows TA. +known_false_positives: Service accounts or applications that routinely query Active + Directory for information. references: - https://medium.com/securonix-tech-blog/detecting-ldap-enumeration-and-bloodhound-s-sharphound-collector-using-active-directory-decoys-dfc840f2f644 - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662 @@ -69,7 +63,7 @@ tags: required_fields: - _time - EventCode - - ObjectName + - ObjectName - EventCode - Computer - SubjectUserName @@ -78,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/4662_ad_enum/4662_priv_events.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/4662_ad_enum/4662_priv_events.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_ad_replication_request_initiated_by_user_account.yml b/detections/endpoint/windows_ad_replication_request_initiated_by_user_account.yml index c10d6584b3..09293b4370 100644 --- a/detections/endpoint/windows_ad_replication_request_initiated_by_user_account.yml +++ b/detections/endpoint/windows_ad_replication_request_initiated_by_user_account.yml @@ -1,24 +1,42 @@ name: Windows AD Replication Request Initiated by User Account id: 51307514-1236-49f6-8686-d46d93cc2821 -version: 2 -date: '2024-01-05' +version: 3 +date: '2024-05-16' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4662 -description: This alert was written to detect activity associated with the DCSync attack. - When a domain controller receives a replication request, the user account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. - Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. - This alert detects when a user account creates a handle to domainDNS with the necessary replication permissions. -search: '`wineventlog_security` EventCode=4662 ObjectType IN ("%{19195a5b-6da0-11d0-afd3-00c04fd930c9}", "domainDNS") AND Properties IN ("*Replicating Directory Changes All*", "*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*", "*{9923a32a-3607-11d2-b9be-0000f87a36b2}*","*{1131f6ac-9c07-11d1-f79f-00c04fc2dcd2}*") AND AccessMask="0x100" AND NOT (SubjectUserSid="NT AUT*" OR SubjectUserSid="S-1-5-18" OR SubjectDomainName="Window Manager" OR SubjectUserName="*$") | stats min(_time) as _time, count by SubjectDomainName, SubjectUserName, Computer, Logon_ID, ObjectName, ObjectServer, ObjectType, OperationType, status | rename SubjectDomainName as Target_Domain, SubjectUserName as user, Logon_ID as TargetLogonId, _time as attack_time | appendpipe [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] | table attack_time, AuthenticationPackageName, LogonProcessName, LogonType, TargetUserSid, Target_Domain, user, Computer, TargetLogonId, status, src_ip, src_category, ObjectName, ObjectServer, ObjectType, OperationType | stats min(attack_time) as _time values(TargetUserSid) as TargetUserSid, values(Target_Domain) as Target_Domain, values(user) as user, values(Computer) as Computer, values(status) as status, values(src_category) as src_category, values(src_ip) as src_ip by TargetLogonId | `windows_ad_replication_request_initiated_by_user_account_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcode `4662`. - The Advanced Security Audit policy settings `Audit Directory Services Access` - within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root - and all descendant objects. The principals `everybody`, `Domain Computers`, and `Domain Controllers` - auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and - `Replicating Directory Changes In Filtered Set` -known_false_positives: Azure AD Connect syncing operations. +description: The following analytic detects a user account initiating an Active Directory + replication request, indicative of a DCSync attack. It leverages EventCode 4662 + from the Windows Security Event Log, focusing on specific object types and replication + permissions. This activity is significant because it can allow an attacker with + sufficient privileges to request password hashes for any or all users within the + domain. If confirmed malicious, this could lead to unauthorized access, privilege + escalation, and potential compromise of the entire domain. +search: '`wineventlog_security` EventCode=4662 ObjectType IN ("%{19195a5b-6da0-11d0-afd3-00c04fd930c9}", + "domainDNS") AND Properties IN ("*Replicating Directory Changes All*", "*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*", + "*{9923a32a-3607-11d2-b9be-0000f87a36b2}*","*{1131f6ac-9c07-11d1-f79f-00c04fc2dcd2}*") + AND AccessMask="0x100" AND NOT (SubjectUserSid="NT AUT*" OR SubjectUserSid="S-1-5-18" + OR SubjectDomainName="Window Manager" OR SubjectUserName="*$") | stats min(_time) + as _time, count by SubjectDomainName, SubjectUserName, Computer, Logon_ID, ObjectName, + ObjectServer, ObjectType, OperationType, status | rename SubjectDomainName as Target_Domain, + SubjectUserName as user, Logon_ID as TargetLogonId, _time as attack_time | appendpipe + [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] + | table attack_time, AuthenticationPackageName, LogonProcessName, LogonType, TargetUserSid, + Target_Domain, user, Computer, TargetLogonId, status, src_ip, src_category, ObjectName, + ObjectServer, ObjectType, OperationType | stats min(attack_time) as _time values(TargetUserSid) + as TargetUserSid, values(Target_Domain) as Target_Domain, values(user) as user, + values(Computer) as Computer, values(status) as status, values(src_category) as + src_category, values(src_ip) as src_ip by TargetLogonId | `windows_ad_replication_request_initiated_by_user_account_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services + Access` within `DS Access` needs to be enabled, as well as the following SACLs applied + to the domain root and all descendant objects. The principals `everybody`, `Domain + Computers`, and `Domain Controllers` auditing the permissions `Replicating Directory + Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes + In Filtered Set` +known_false_positives: Azure AD Connect syncing operations. references: - https://adsecurity.org/?p=1729 - https://www.linkedin.com/pulse/mimikatz-dcsync-event-log-detections-john-dwyer @@ -30,7 +48,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 100 - message: Windows Active Directory Replication Request Initiated by User Account $user$ at $src_ip$ + message: Windows Active Directory Replication Request Initiated by User Account + $user$ at $src_ip$ mitre_attack_id: - T1003.006 - T1003 @@ -68,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.006/mimikatz/xml-windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.006/mimikatz/xml-windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_replication_request_initiated_from_unsanctioned_location.yml b/detections/endpoint/windows_ad_replication_request_initiated_from_unsanctioned_location.yml index 4e5b7d00d5..1b02916fdf 100644 --- a/detections/endpoint/windows_ad_replication_request_initiated_from_unsanctioned_location.yml +++ b/detections/endpoint/windows_ad_replication_request_initiated_from_unsanctioned_location.yml @@ -1,43 +1,46 @@ name: Windows AD Replication Request Initiated from Unsanctioned Location id: 50998483-bb15-457b-a870-965080d9e3d3 -version: 3 -date: '2024-01-05' +version: 4 +date: '2024-05-20' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4662 - Windows Event Log Security 4624 -description: This alert was written to detect activity associated with the DCSync attack performed by computer accounts. - When a domain controller receives a replication request, the account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. - Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. - This alert detects when a computer account account creates a handle to domainDNS with the necessary replication permissions. These requests are then filtered to exclude where the events originate - from a known domain controller IP address. +description: The following analytic identifies unauthorized Active Directory replication + requests initiated from non-domain controller locations. It leverages EventCode + 4662 to detect when a computer account with replication permissions creates a handle + to domainDNS, filtering out known domain controller IP addresses. This activity + is significant as it may indicate a DCSync attack, where an attacker with privileged + access can request password hashes for any or all users within the domain. If confirmed + malicious, this could lead to unauthorized access to sensitive information and potential + full domain compromise. search: '`wineventlog_security` EventCode=4662 ObjectType IN ("%{19195a5b-6da0-11d0-afd3-00c04fd930c9}", - "domainDNS") AND Properties IN ("*Replicating Directory Changes All*", "*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*", - "*{9923a32a-3607-11d2-b9be-0000f87a36b2}*","*{1131f6ac-9c07-11d1-f79f-00c04fc2dcd2}*") - AND AccessMask="0x100" AND (SubjectUserSid="NT AUT*" OR SubjectUserSid="S-1-5-18" OR SubjectDomainName="Window Manager" OR SubjectUserName="*$") - | stats min(_time) as attack_time, count by SubjectDomainName, SubjectUserName, Computer, Logon_ID, ObjectName, ObjectServer, ObjectType, OperationType, status - | rename SubjectDomainName as Target_Domain, SubjectUserName as user, Logon_ID as - TargetLogonId - | appendpipe - [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] + "domainDNS") AND Properties IN ("*Replicating Directory Changes All*", "*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*", + "*{9923a32a-3607-11d2-b9be-0000f87a36b2}*","*{1131f6ac-9c07-11d1-f79f-00c04fc2dcd2}*") + AND AccessMask="0x100" AND (SubjectUserSid="NT AUT*" OR SubjectUserSid="S-1-5-18" + OR SubjectDomainName="Window Manager" OR SubjectUserName="*$") | stats min(_time) + as attack_time, count by SubjectDomainName, SubjectUserName, Computer, Logon_ID, + ObjectName, ObjectServer, ObjectType, OperationType, status | rename SubjectDomainName + as Target_Domain, SubjectUserName as user, Logon_ID as TargetLogonId | appendpipe + [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] | table attack_time, AuthenticationPackageName, LogonProcessName, LogonType, TargetUserSid, - Target_Domain, user, Computer, TargetLogonId, status, src_ip, src_category, ObjectName, - ObjectServer, ObjectType, OperationType - | stats min(attack_time) as _time, values(TargetUserSid) as TargetUserSid, values(Target_Domain) - as Target_Domain, values(user) as user, values(Computer) as Computer, values(status) - as status, values(src_category) as src_category, values(src_ip) as src_ip by TargetLogonId - | search NOT src_category="domain_controller" + Target_Domain, user, Computer, TargetLogonId, status, src_ip, src_category, ObjectName, + ObjectServer, ObjectType, OperationType | stats min(attack_time) as _time, values(TargetUserSid) + as TargetUserSid, values(Target_Domain) as Target_Domain, values(user) as user, + values(Computer) as Computer, values(status) as status, values(src_category) as + src_category, values(src_ip) as src_ip by TargetLogonId | search NOT src_category="domain_controller" | `windows_ad_replication_request_initiated_from_unsanctioned_location_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcode `4662`. - The Advanced Security Audit policy settings `Audit Directory Services Access` - within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root - and all descendant objects. The principals `everybody`, `Domain Computers`, and `Domain Controllers` - auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and - `Replicating Directory Changes In Filtered Set` - Assets and Identities will also need to be configured, with the category of domain_controller added for domain controllers. -known_false_positives: Genuine DC promotion may trigger this alert. +how_to_implement: To successfully implement this search, you need to be ingesting + eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services + Access` within `DS Access` needs to be enabled, as well as the following SACLs applied + to the domain root and all descendant objects. The principals `everybody`, `Domain + Computers`, and `Domain Controllers` auditing the permissions `Replicating Directory + Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes + In Filtered Set` Assets and Identities will also need to be configured, with the + category of domain_controller added for domain controllers. +known_false_positives: Genuine DC promotion may trigger this alert. references: - https://adsecurity.org/?p=1729 - https://www.linkedin.com/pulse/mimikatz-dcsync-event-log-detections-john-dwyer @@ -49,7 +52,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 100 - message: Windows Active Directory Replication Request Initiated from Unsanctioned Location $src_ip$ by $user$ + message: Windows Active Directory Replication Request Initiated from Unsanctioned + Location $src_ip$ by $user$ mitre_attack_id: - T1003.006 - T1003 @@ -87,6 +91,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.006/impacket/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.006/impacket/windows-security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_same_domain_sid_history_addition.yml b/detections/endpoint/windows_ad_same_domain_sid_history_addition.yml index 1211667b7d..8aa08c4d09 100644 --- a/detections/endpoint/windows_ad_same_domain_sid_history_addition.yml +++ b/detections/endpoint/windows_ad_same_domain_sid_history_addition.yml @@ -1,29 +1,30 @@ name: Windows AD Same Domain SID History Addition id: 5fde0b7c-df7a-40b1-9b3a-294c00f0289d -version: 2 -date: '2022-09-09' +version: 3 +date: '2024-05-22' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 4742 - Windows Event Log Security 4738 -description: The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects which exist within the same domain. - The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access - continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain. - This analytic was written to pick up on activity via Mimikatz sid::patch. Please note there are additional avenues to abuse SID history such as DCShadow & Golden / Diamond tickets which won't be detected using these event codes. +description: The following analytic detects changes to the sIDHistory attribute of + user or computer objects within the same domain. It leverages Windows Security Event + Codes 4738 and 4742 to identify when the sIDHistory attribute is modified. This + activity is significant because the sIDHistory attribute can be abused by adversaries + to grant unauthorized access by inheriting permissions from another account. If + confirmed malicious, this could allow attackers to maintain persistent access or + escalate privileges within the domain, posing a severe security risk. search: '`wineventlog_security` (EventCode=4742 OR EventCode=4738) NOT SidHistory - IN ("%%1793", -) - | rex field=SidHistory "(^%{|^)(?P.*)(\-|\\\)" - | rex field=TargetSid "^(?P.*)(\-|\\\)" - | where SidHistoryMatch=TargetSidmatch OR SidHistoryMatch=TargetDomainName - | rename TargetSid as userSid, TargetDomainName as userDomainName - | table _time action status host user userSid userDomainName SidHistory Logon_ID src_user - | `windows_ad_same_domain_sid_history_addition_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcodes - `4738` and `4742`. The Advanced Security Audit policy settings - `Audit User Account Management` and `Audit Computer Account Management` - within `Account Management` all need to be enabled. SID resolution is not required.. + IN ("%%1793", -) | rex field=SidHistory "(^%{|^)(?P.*)(\-|\\\)" + | rex field=TargetSid "^(?P.*)(\-|\\\)" | where SidHistoryMatch=TargetSidmatch + OR SidHistoryMatch=TargetDomainName | rename TargetSid as userSid, TargetDomainName + as userDomainName | table _time action status host user userSid userDomainName SidHistory + Logon_ID src_user | `windows_ad_same_domain_sid_history_addition_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit + User Account Management` and `Audit Computer Account Management` within `Account + Management` all need to be enabled. SID resolution is not required.. known_false_positives: Unknown references: - https://adsecurity.org/?p=1772 @@ -68,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/mimikatz/windows-security-xml.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_serviceprincipalname_added_to_domain_account.yml b/detections/endpoint/windows_ad_serviceprincipalname_added_to_domain_account.yml index e7c6122c46..e22a02f6f0 100644 --- a/detections/endpoint/windows_ad_serviceprincipalname_added_to_domain_account.yml +++ b/detections/endpoint/windows_ad_serviceprincipalname_added_to_domain_account.yml @@ -1,23 +1,29 @@ name: Windows AD ServicePrincipalName Added To Domain Account id: 8a1259cb-0ea7-409c-8bfe-74bad89259f9 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-22' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 5136 -description: The following analytic identifies the addition of a Service Principal Name to a domain account. While this event may be part of a legitimate action part of certain administrative operations, - it may also be evidence of a persistence attack. Domain accounts with Servce Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password - of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt - to obtain its clertext password. -search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName OperationType="%%14674" - | stats values(ObjectDN) as ObjectDN by _time, Computer, SubjectUserName, AttributeValue | rename Computer as dest SubjectUserName as user +description: The following analytic detects the addition of a Service Principal Name + (SPN) to a domain account. It leverages Windows Event Code 5136 and monitors changes + to the servicePrincipalName attribute. This activity is significant because it may + indicate an attempt to perform Kerberoasting, a technique where attackers extract + and crack service account passwords offline. If confirmed malicious, this could + allow an attacker to obtain cleartext passwords, leading to unauthorized access + and potential lateral movement within the domain environment. +search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName + OperationType="%%14674" | stats values(ObjectDN) as ObjectDN by _time, Computer, + SubjectUserName, AttributeValue | rename Computer as dest SubjectUserName as user | `windows_ad_serviceprincipalname_added_to_domain_account_filter`' -how_to_implement: To successfully implement this search, you ned to be ingesting eventcode - `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. -known_false_positives: A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on +how_to_implement: To successfully implement this search, you ned to be ingesting eventcode + `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` + within `DS Access` needs to be enabled. Additionally, a SACL needs to be created + for AD objects in order to ingest attribute modifications. +known_false_positives: A Service Principal Name should only be added to an account + when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed. references: - https://adsecurity.org/?p=3466 @@ -58,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/service_principal_name_added/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/service_principal_name_added/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_short_lived_domain_account_serviceprincipalname.yml b/detections/endpoint/windows_ad_short_lived_domain_account_serviceprincipalname.yml index 6080a8de50..8d1a3b2fe9 100644 --- a/detections/endpoint/windows_ad_short_lived_domain_account_serviceprincipalname.yml +++ b/detections/endpoint/windows_ad_short_lived_domain_account_serviceprincipalname.yml @@ -1,26 +1,31 @@ name: Windows AD Short Lived Domain Account ServicePrincipalName id: b681977c-d90c-4efc-81a5-c58f945fb541 -version: 1 -date: '2022-11-18' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 5136 -description: The following analytic identifies the addition of a Service Principal Name to a domain account that is quickly deleted within 5 minutes or less. While this event may be part of a legitimate action part of certain administrative operations, - it may also be evidence of a persistence attack. Domain accounts with Service Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password - of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt - to obtain its clertext password. To clean things up, the adversary may delete the SPN which will trigger this detection. +description: The following analytic identifies the addition and quick deletion of + a Service Principal Name (SPN) to a domain account within 5 minutes. This detection + leverages EventCode 5136 from the Windows Security Event Log, focusing on changes + to the servicePrincipalName attribute. This activity is significant as it may indicate + an attempt to perform Kerberoasting, a technique used to crack the cleartext password + of a domain account offline. If confirmed malicious, this could allow an attacker + to gain unauthorized access to sensitive information or escalate privileges within + the domain environment. search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName - | transaction ObjectDN AttributeValue startswith=(EventCode=5136 OperationType="%%14674") endswith=(EventCode=5136 OperationType="%%14675") - | eval short_lived=case((duration<300),"TRUE") - | search short_lived = TRUE | rename ObjectDN as user - | `windows_ad_short_lived_domain_account_serviceprincipalname_filter`' -how_to_implement: To successfully implement this search, you ned to be ingesting eventcode - `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. -known_false_positives: A Service Principal Name should only be added to an account when an application requires it. Adding an SPN and quickly deleting it - is less common but may be part of legitimate action. Filter as needed. + | transaction ObjectDN AttributeValue startswith=(EventCode=5136 OperationType="%%14674") + endswith=(EventCode=5136 OperationType="%%14675") | eval short_lived=case((duration<300),"TRUE") + | search short_lived = TRUE | rename ObjectDN as user | `windows_ad_short_lived_domain_account_serviceprincipalname_filter`' +how_to_implement: To successfully implement this search, you ned to be ingesting eventcode + `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` + within `DS Access` needs to be enabled. Additionally, a SACL needs to be created + for AD objects in order to ingest attribute modifications. +known_false_positives: A Service Principal Name should only be added to an account + when an application requires it. Adding an SPN and quickly deleting it is less common + but may be part of legitimate action. Filter as needed. references: - https://adsecurity.org/?p=3466 - https://www.thehacker.recipes/ad/movement/dacl/targeted-kerberoasting @@ -56,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/short_lived_service_principal_name/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/short_lived_service_principal_name/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_short_lived_domain_controller_spn_attribute.yml b/detections/endpoint/windows_ad_short_lived_domain_controller_spn_attribute.yml index 6fbc3762d4..aaa5800936 100644 --- a/detections/endpoint/windows_ad_short_lived_domain_controller_spn_attribute.yml +++ b/detections/endpoint/windows_ad_short_lived_domain_controller_spn_attribute.yml @@ -1,29 +1,43 @@ name: Windows AD Short Lived Domain Controller SPN Attribute -id: 57e27f27-369c-4df8-af08-e8c7ee8373d4 -version: 3 -date: '2023-11-07' +id: 57e27f27-369c-4df8-af08-e8c7ee8373d4 +version: 4 +date: '2024-05-11' author: Dean Luxton type: TTP status: production data_source: - Windows Event Log Security 5136 - Windows Event Log Security 4624 -description: The following analytic identifies when either a global catalog SPN or a DRS RPC SPN are temporarily added to an Active Directory computer object, both of which can be evidence of a DCShadow attack. - DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject - and replicate changes into the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security researchers Benjamin Delpy and Vincent Le Toux. - No event logs are written for changes to AD attributes, allowing for stealthy backdoors to be implanted in the domain, or metadata such as timestamps overwritten to cover tracks. -search: '`wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName (AttributeValue="GC/*" OR AttributeValue="E3514235-4B06-11D1-AB04-00C04FC2DCD2/*") | stats min(_time) as _time range(_time) as duration values(OperationType) as OperationType values(user) as user values(src_ip) as src_ip values(src_nt_domain) as src_nt_domain values(src_user) as src_user values(Computer) as dest, values(ObjectDN) as ObjectDN by Logon_ID | eval short_lived=case((duration<30),"TRUE") | where short_lived="TRUE" AND mvcount(OperationType)>1 | replace "%%14674" with "Value Added", "%%14675" with "Value Deleted" in OperationType | rename Logon_ID as TargetLogonId | appendpipe [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] | stats min(_time) as _time, values(ObjectDN) as ObjectDN values(OperationType) as OperationType by TargetLogonId src_user dest | `windows_ad_short_lived_domain_controller_spn_attribute_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting eventcode - `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled, alongside a SACL for `everybody` to - `Write All Properties` applied to the domain root and all descendant objects. +description: The following analytic detects the temporary addition of a global catalog + SPN or a DRS RPC SPN to an Active Directory computer object, indicative of a potential + DCShadow attack. This detection leverages EventCode 5136 from the `wineventlog_security` + data source, focusing on specific SPN attribute changes. This activity is significant + as DCShadow attacks allow attackers with privileged access to register rogue Domain + Controllers, enabling unauthorized changes to the AD infrastructure. If confirmed + malicious, this could lead to unauthorized replication of changes, including credentials + and keys, compromising the entire domain's security. +search: '`wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName + (AttributeValue="GC/*" OR AttributeValue="E3514235-4B06-11D1-AB04-00C04FC2DCD2/*") + | stats min(_time) as _time range(_time) as duration values(OperationType) as OperationType + values(user) as user values(src_ip) as src_ip values(src_nt_domain) as src_nt_domain + values(src_user) as src_user values(Computer) as dest, values(ObjectDN) as ObjectDN + by Logon_ID | eval short_lived=case((duration<30),"TRUE") | where short_lived="TRUE" + AND mvcount(OperationType)>1 | replace "%%14674" with "Value Added", "%%14675" with + "Value Deleted" in OperationType | rename Logon_ID as TargetLogonId | appendpipe + [| map search="search `wineventlog_security` EventCode=4624 TargetLogonId=$TargetLogonId$"] + | stats min(_time) as _time, values(ObjectDN) as ObjectDN values(OperationType) + as OperationType by TargetLogonId src_user dest | `windows_ad_short_lived_domain_controller_spn_attribute_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services + Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` + to `Write All Properties` applied to the domain root and all descendant objects. known_false_positives: None. references: - https://www.dcshadow.com/ - https://blog.netwrix.com/2022/09/28/dcshadow_attack/ - https://gist.github.com/gentilkiwi/dcc132457408cf11ad2061340dcb53c2 - https://attack.mitre.org/techniques/T1207/ -- https://blog.alsid.eu/dcshadow-explained-4510f52fc19d +- https://blog.alsid.eu/dcshadow-explained-4510f52fc19d tags: analytic_story: - Sneaky Active Directory Persistence Tricks @@ -58,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/mimikatz/windows-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/mimikatz/windows-security-xml.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_short_lived_server_object.yml b/detections/endpoint/windows_ad_short_lived_server_object.yml index c3fe144eb2..1aefbcaed6 100644 --- a/detections/endpoint/windows_ad_short_lived_server_object.yml +++ b/detections/endpoint/windows_ad_short_lived_server_object.yml @@ -1,29 +1,31 @@ name: Windows AD Short Lived Server Object id: 193769d3-1e33-43a9-970e-ad4a88256cdb -version: 1 -date: '2022-10-17' +version: 2 +date: '2024-05-21' author: Mauricio Velazco, Splunk type: TTP status: production -data_source: +data_source: - Windows Event Log Security 5137 - Windows Event Log Security 5141 -description: 'The following analytic identifies a change in an Active Directory environment that could represent evidence of the DCShadow attack. - DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject - and replicate changes in the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security - researchers Benjamin Delpy and Vincent Le Toux. Specifically, the detection will trigger when a possible rogue Domain Controller - computer object is created and quickly deleted within 30 seconds or less in an Active Directory domain. This behavior was identfied by simulating the DCShadow attack with - Mimikatz.' +description: 'The following analytic identifies the creation and quick deletion of + a Domain Controller (DC) object within 30 seconds in an Active Directory environment, + indicative of a potential DCShadow attack. This detection leverages Windows Security + Event Codes 5137 and 5141, analyzing the duration between these events. This activity + is significant as DCShadow allows attackers with privileged access to register a + rogue DC, enabling unauthorized changes to AD objects, including credentials. If + confirmed malicious, this could lead to unauthorized AD modifications, compromising + the integrity and security of the entire domain.' search: ' `wineventlog_security` EventCode=5137 OR EventCode=5141 ObjectDN="*CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration*" - | transaction ObjectDN startswith=(EventCode=5137) endswith=(EventCode=5141) - | eval short_lived=case((duration<30),"TRUE") - | search short_lived = TRUE - | stats values(ObjectDN) values(signature) values(EventCode) by _time, Computer, SubjectUserName - | `windows_ad_short_lived_server_object_filter`' -how_to_implement: To successfully implement this search, you ned to be ingesting Event codes - `5137` and `5141`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled. For these event codes to be generated, specific SACLs are required. -known_false_positives: Creating and deleting a server object within 30 seconds or less is unusual but not impossible in a production environment. Filter as needed. + | transaction ObjectDN startswith=(EventCode=5137) endswith=(EventCode=5141) | eval + short_lived=case((duration<30),"TRUE") | search short_lived = TRUE | stats values(ObjectDN) + values(signature) values(EventCode) by _time, Computer, SubjectUserName | `windows_ad_short_lived_server_object_filter`' +how_to_implement: To successfully implement this search, you ned to be ingesting Event + codes `5137` and `5141`. The Advanced Security Audit policy setting `Audit Directory + Services Changes` within `DS Access` needs to be enabled. For these event codes + to be generated, specific SACLs are required. +known_false_positives: Creating and deleting a server object within 30 seconds or + less is unusual but not impossible in a production environment. Filter as needed. references: - https://www.dcshadow.com/ - https://attack.mitre.org/techniques/T1207/ @@ -65,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/short_lived_server_object/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1207/short_lived_server_object/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ad_sid_history_attribute_modified.yml b/detections/endpoint/windows_ad_sid_history_attribute_modified.yml index ddedfa605c..c855fcc1d1 100644 --- a/detections/endpoint/windows_ad_sid_history_attribute_modified.yml +++ b/detections/endpoint/windows_ad_sid_history_attribute_modified.yml @@ -1,22 +1,29 @@ name: Windows AD SID History Attribute Modified id: 1155e47d-307f-4247-beab-71071e3a458c -version: 1 -date: '2022-11-16' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk type: TTP status: production -data_source: +data_source: - Windows Event Log Security 5136 -description: The following analytic leverages event code `5136` to identify a modification of the SID History AD attribute. - The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access - continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain. -search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=sIDHistory OperationType="%%14674" - | stats values(ObjectDN) as ObjectDN by _time, Computer, SubjectUserName, AttributeValue | rename Computer as dest - | `windows_ad_sid_history_attribute_modified_filter`' -how_to_implement: To successfully implement this search, you ned to be ingesting eventcode - `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` - within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. -known_false_positives: Domain mergers and migrations may generate large volumes of false positives for this analytic. +description: The following analytic detects modifications to the SID History attribute + in Active Directory by leveraging event code 5136. This detection uses logs from + the `wineventlog_security` data source to identify changes to the sIDHistory attribute. + Monitoring this activity is crucial as the SID History attribute can be exploited + by adversaries to inherit permissions from other accounts, potentially granting + unauthorized access. If confirmed malicious, this activity could allow attackers + to maintain persistent access and escalate privileges within the domain, posing + a significant security risk. +search: ' `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=sIDHistory + OperationType="%%14674" | stats values(ObjectDN) as ObjectDN by _time, Computer, + SubjectUserName, AttributeValue | rename Computer as dest | `windows_ad_sid_history_attribute_modified_filter`' +how_to_implement: To successfully implement this search, you ned to be ingesting eventcode + `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` + within `DS Access` needs to be enabled. Additionally, a SACL needs to be created + for AD objects in order to ingest attribute modifications. +known_false_positives: Domain mergers and migrations may generate large volumes of + false positives for this analytic. references: - https://adsecurity.org/?p=1772 - https://learn.microsoft.com/en-us/windows/win32/adschema/a-sidhistory?redirectedfrom=MSDN @@ -28,7 +35,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 80 - message: SID History AD attribute modified by $SubjectUserName$ for $ObjectDN$ on $dest$ + message: SID History AD attribute modified by $SubjectUserName$ for $ObjectDN$ on + $dest$ mitre_attack_id: - T1134 - T1134.005 @@ -55,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/sid_history2/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134.005/sid_history2/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_adfind_exe.yml b/detections/endpoint/windows_adfind_exe.yml index b89fb6de5e..e23d9c6d48 100644 --- a/detections/endpoint/windows_adfind_exe.yml +++ b/detections/endpoint/windows_adfind_exe.yml @@ -1,18 +1,18 @@ name: Windows AdFind Exe id: bd3b0187-189b-46c0-be45-f52da2bae67f -version: 3 -date: '2023-06-13' +version: 4 +date: '2024-05-13' author: Jose Hernandez, Bhavin Patel, Splunk status: production type: TTP -description: 'This search looks for the execution of `adfind.exe` with command-line - arguments that it uses by default specifically the filter or search functions. It - also considers the arguments necessary like objectcategory, see readme for more - details: https://www.joeware.net/freetools/tools/adfind/usage.htm. AdFind.exe is - a powerful tool that is commonly used for querying and retrieving information from - Active Directory (AD). While it is primarily designed for AD administration and - management, it has been seen used before by Wizard Spider, FIN6 and actors whom - also launched SUNBURST.' +description: 'The following analytic identifies the execution of `adfind.exe` with + specific command-line arguments related to Active Directory queries. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names, + command-line arguments, and parent processes. This activity is significant because + `adfind.exe` is a powerful tool often used by threat actors like Wizard Spider and + FIN6 to gather sensitive AD information. If confirmed malicious, this activity could + allow attackers to map the AD environment, facilitating further attacks such as + privilege escalation or lateral movement.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_admin_permission_discovery.yml b/detections/endpoint/windows_admin_permission_discovery.yml index 7f1a28ea13..5bb5a9d541 100644 --- a/detections/endpoint/windows_admin_permission_discovery.yml +++ b/detections/endpoint/windows_admin_permission_discovery.yml @@ -1,32 +1,35 @@ name: Windows Admin Permission Discovery id: e08620cb-9488-4052-832d-97bcc0afd414 -version: 1 -date: '2023-09-19' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 11 -description: This analytic is developed to identify suspicious file creation in the root drive (C:\). - This tactic was observed in NjRAT as a means to ascertain whether its malware instance running on - the compromised host possesses administrative privileges. - The methodology involves an attempt to create a 'win.dat' file in the C:\ directory. - If this file is successfully created, it serves as an indicator that the process indeed holds administrative privileges. - This anomaly detection mechanism serves as a valuable pivot point for detecting NjRAT and other malware strains employing - similar techniques to assess the privileges of their running malware instances, without using token privilege API calls or PowerShell commandlets. -search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem - where Filesystem.file_name IN ("*.exe", "*.dll", "*.sys", "*.com", "*.vbs", "*.vbe", "*.js", "*.bat", "*.cmd", "*.pif", "*.lnk", "*.dat") - by Filesystem.dest Filesystem.file_create_time Filesystem.process_id Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.user - | `drop_dm_object_name(Filesystem)` - | eval dropped_file_path = split(file_path, "\\") - | eval dropped_file_path_split_count = mvcount(dropped_file_path) - | eval root_drive = mvindex(dropped_file_path,0) | where LIKE(root_drive, "C:") AND dropped_file_path_split_count = 2 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_admin_permission_discovery_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that - include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. -known_false_positives: False positives may occur if there are legitimate accounts with the privilege to drop files in the root of the C drive. It's recommended to verify the legitimacy of such actions and the accounts involved. +description: The following analytic identifies the creation of a suspicious file named + 'win.dat' in the root directory (C:\). It leverages data from the Endpoint.Filesystem + datamodel to detect this activity. This behavior is significant as it is commonly + used by malware like NjRAT to check for administrative privileges on a compromised + host. If confirmed malicious, this activity could indicate that the malware has + administrative access, allowing it to perform high-privilege actions, potentially + leading to further system compromise and persistence. +search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*.exe", + "*.dll", "*.sys", "*.com", "*.vbs", "*.vbe", "*.js", "*.bat", "*.cmd", "*.pif", + "*.lnk", "*.dat") by Filesystem.dest Filesystem.file_create_time Filesystem.process_id + Filesystem.process_guid Filesystem.file_name Filesystem.file_path Filesystem.user + | `drop_dm_object_name(Filesystem)` | eval dropped_file_path = split(file_path, + "\\") | eval dropped_file_path_split_count = mvcount(dropped_file_path) | eval root_drive + = mvindex(dropped_file_path,0) | where LIKE(root_drive, "C:") AND dropped_file_path_split_count + = 2 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | + `windows_admin_permission_discovery_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the Filesystem responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Filesystem` node. +known_false_positives: False positives may occur if there are legitimate accounts + with the privilege to drop files in the root of the C drive. It's recommended to + verify the legitimacy of such actions and the accounts involved. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat tags: @@ -66,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/njrat_admin_check/win_dat.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/njrat_admin_check/win_dat.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_administrative_shares_accessed_on_multiple_hosts.yml b/detections/endpoint/windows_administrative_shares_accessed_on_multiple_hosts.yml index e2d36bdc0e..fc8331a2e3 100644 --- a/detections/endpoint/windows_administrative_shares_accessed_on_multiple_hosts.yml +++ b/detections/endpoint/windows_administrative_shares_accessed_on_multiple_hosts.yml @@ -1,22 +1,20 @@ name: Windows Administrative Shares Accessed On Multiple Hosts id: d92f2d95-05fb-48a7-910f-4d3d61ab8655 -version: 1 -date: '2023-03-23' +version: 2 +date: '2024-05-19' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 5140 - Windows Event Log Security 5145 -description: The following analytic leverages Event IDs 5140 or 5145 to identify a - source computer accessing windows administrative shares (C$, Admin$ and IPC$ ) across - a large number remote endpoints. Specifically, the logic will trigger when a source - endpoint accesses administrative shares across 30 or more target computers within - a 5 minute timespan. This behavior could represent an adversary who is enumerating - network shares across an Active Directory environment in the search for sensitive - files, a common technique leveraged by red teamers and threat actors. As environments - differ across organizations, security teams should customize the thresholds of this - detection as needed. +description: The following analytic detects a source computer accessing Windows administrative + shares (C$, Admin$, IPC$) on 30 or more remote endpoints within a 5-minute window. + It leverages Event IDs 5140 and 5145 from file share events. This behavior is significant + as it may indicate an adversary enumerating network shares to locate sensitive files, + a common tactic used by threat actors. If confirmed malicious, this activity could + lead to unauthorized access to critical data, lateral movement, and potential compromise + of multiple systems within the network. search: ' `wineventlog_security` EventCode=5140 OR EventCode=5145 (ShareName="\\\\*\\ADMIN$" OR ShareName="\\\\*\\IPC$" OR ShareName="\\\\*\\C$") | bucket span=5m _time | stats dc(Computer) AS unique_targets values(Computer) as host_targets values(ShareName) @@ -71,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/ipc_share_accessed/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/ipc_share_accessed/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_admon_default_group_policy_object_modified.yml b/detections/endpoint/windows_admon_default_group_policy_object_modified.yml index ff923c82ac..c9c7b2a75d 100644 --- a/detections/endpoint/windows_admon_default_group_policy_object_modified.yml +++ b/detections/endpoint/windows_admon_default_group_policy_object_modified.yml @@ -1,24 +1,30 @@ name: Windows Admon Default Group Policy Object Modified id: 83458004-db60-4170-857d-8572f16f070b -version: 1 -date: '2023-03-29' +version: 2 +date: '2024-05-28' author: Mauricio Velazco, Splunk status: production type: TTP -data_source : +data_source: - Windows Active Directory Admon -description: The following analytic leverages Splunks Admon to identify the modification of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain - two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. - The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group - policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the modification of the default GPOs. -search: ' `admon` admonEventType=Update objectCategory="CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=*" (displayName="Default Domain Policy" OR displayName="Default Domain Controllers Policy") - | stats min(_time) as firstTime max(_time) as lastTime values(gPCFileSysPath) by dcName, displayName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects modifications to the default Group Policy + Objects (GPOs) in an Active Directory environment. It leverages Splunk's Admon to + monitor updates to the "Default Domain Policy" and "Default Domain Controllers Policy." + This activity is significant because changes to these default GPOs can indicate + an adversary with privileged access attempting to gain further control, establish + persistence, or deploy malware across multiple hosts. If confirmed malicious, such + modifications could lead to widespread policy enforcement changes, unauthorized + access, and potential compromise of the entire domain environment. +search: ' `admon` admonEventType=Update objectCategory="CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=*" + (displayName="Default Domain Policy" OR displayName="Default Domain Controllers + Policy") | stats min(_time) as firstTime max(_time) as lastTime values(gPCFileSysPath) + by dcName, displayName | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_admon_default_group_policy_object_modified_filter`' -how_to_implement: To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here +how_to_implement: To successfully implement this search, you need to be monitoring + Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory -known_false_positives: The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed. +known_false_positives: The default Group Policy Objects within an AD network may be + legitimately updated for administrative operations, filter as needed. references: - https://attack.mitre.org/techniques/T1484/ - https://attack.mitre.org/techniques/T1484/001 @@ -57,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log source: ActiveDirectory - sourcetype: ActiveDirectory \ No newline at end of file + sourcetype: ActiveDirectory diff --git a/detections/endpoint/windows_admon_group_policy_object_created.yml b/detections/endpoint/windows_admon_group_policy_object_created.yml index 67e0bbe23a..a200ad7329 100644 --- a/detections/endpoint/windows_admon_group_policy_object_created.yml +++ b/detections/endpoint/windows_admon_group_policy_object_created.yml @@ -1,24 +1,28 @@ name: Windows Admon Group Policy Object Created id: 69201633-30d9-48ef-b1b6-e680805f0582 -version: 1 -date: '2023-04-06' +version: 2 +date: '2024-05-20' author: Mauricio Velazco, Splunk status: production type: TTP -data_source : +data_source: - Windows Active Directory Admon -description: The following analytic leverages Splunks Admon to identify the creation of a new Group Policy Object. With GPOs, system administrators can manage and configure - applications, software operations, and user settings throughout an entire organization. GPOs can be abused and leveraged by adversaries to escalate privileges or - deploy malware across an Active Directory network. As an example, the Lockbit ransomware malware will create new group policies on the domain controller that are then pushed out to every device on the network. - Security teams should monitor the creation of new Group Policy Objects. -search: ' `admon` admonEventType=Update objectCategory="CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=*" versionNumber=0 displayName!="New Group Policy Object" - | stats min(_time) as firstTime max(_time) as lastTime values(gPCFileSysPath) by dcName, displayName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_admon_group_policy_object_created_filter`' -how_to_implement: To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here +description: The following analytic detects the creation of a new Group Policy Object + (GPO) using Splunk's Admon data. It identifies events where a new GPO is created, + excluding default "New Group Policy Object" entries. Monitoring GPO creation is + crucial as adversaries can exploit GPOs to escalate privileges or deploy malware + across an Active Directory network. If confirmed malicious, this activity could + allow attackers to control system configurations, deploy ransomware, or propagate + malware, significantly compromising the network's security. +search: ' `admon` admonEventType=Update objectCategory="CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=*" + versionNumber=0 displayName!="New Group Policy Object" | stats min(_time) as firstTime + max(_time) as lastTime values(gPCFileSysPath) by dcName, displayName | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_admon_group_policy_object_created_filter`' +how_to_implement: To successfully implement this search, you need to be monitoring + Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory -known_false_positives: Group Policy Objects are created as part of regular administrative operations, filter as needed. +known_false_positives: Group Policy Objects are created as part of regular administrative + operations, filter as needed. references: - https://attack.mitre.org/techniques/T1484/ - https://attack.mitre.org/techniques/T1484/001 @@ -57,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/group_policy_created/windows-admon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/group_policy_created/windows-admon.log source: ActiveDirectory sourcetype: ActiveDirectory diff --git a/detections/endpoint/windows_alternate_datastream___base64_content.yml b/detections/endpoint/windows_alternate_datastream___base64_content.yml index 225c00c009..9bf07cecb7 100644 --- a/detections/endpoint/windows_alternate_datastream___base64_content.yml +++ b/detections/endpoint/windows_alternate_datastream___base64_content.yml @@ -1,30 +1,35 @@ name: Windows Alternate DataStream - Base64 Content id: 683f48de-982f-4a7e-9aac-9cec550da498 -version: 2 -date: '2024-02-15' +version: 3 +date: '2024-05-28' author: Steven Dick, Teoderick Contreras, Michael Haag, Splunk status: production type: TTP -description: This analytic leverages Sysmon EventID 15, a critical file creation event, to detect the creation of Alternate Data Streams (ADS) on Windows systems. ADS is a feature of the NTFS file system that allows the storage of data in hidden streams attached to files. These streams are not visible in standard file listings, making them a popular technique for concealing malicious activity. Event ID 15 captures both the hash of the primary file content (unnamed stream) and the content of any additional named streams, which can include executables, scripts, or configuration data. Malware often exploits ADS to hide payloads, leveraging browser downloads to attach a Zone.Identifier stream, marking the file as originating from the Internet (Mark Of The Web, MOTW). This analytic is designed to identify such misuse by analyzing the content and creation patterns of named streams, including those under 1KB which may contain MOTW information. It is essential for detecting sophisticated threats that utilize non-executable file types or conceal malicious scripts within ADS, beyond the traditional focus on PE executables. The detection process involves monitoring for the creation of named streams, which are part of the NTFS structure and can be examined using tools like PowerShell for the presence of additional data streams or MOTW information. This approach helps in uncovering hidden payloads and tracking the origin of suspicious files downloaded via browsers or email clients, providing a comprehensive defense against ADS abuse. +description: The following analytic detects the creation of Alternate Data Streams + (ADS) with Base64 content on Windows systems. It leverages Sysmon Event ID 15, which + captures file creation events, including the content of named streams. ADS can conceal + malicious payloads, making them significant for SOC monitoring. This detection identifies + hidden streams that may contain executables, scripts, or configuration data, often + used by malware to evade detection. If confirmed malicious, this activity could + allow attackers to hide and execute payloads, persist in the environment, or access + sensitive information without being easily detected. data_source: - Sysmon EventID 15 -search: '`sysmon` EventCode=15 NOT Contents IN ("-","[ZoneTransfer]*") - | regex TargetFilename="(? upperBound, "Yes", "No") - | where anomaly="Yes" - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_applocker_execution_from_uncommon_locations_filter`' -how_to_implement: The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there. Upon tuning, modify to Anomaly or TTP. -known_false_positives: False positives are possible if legitimate users are executing applications from file paths that are not permitted by AppLocker. It is recommended to investigate the context of the application execution to determine if it is malicious or not. Modify the threshold as needed to reduce false positives. +description: The following analytic identifies the execution of applications or scripts + from uncommon or suspicious file paths, potentially indicating malware or unauthorized + activity. It leverages Windows AppLocker event logs and uses statistical analysis + to detect anomalies. By calculating the average and standard deviation of execution + counts per file path, it flags paths with execution counts significantly higher + than expected. This behavior is significant as it can uncover malicious activities + or policy violations. If confirmed malicious, this activity could allow attackers + to execute unauthorized code, leading to potential system compromise or data breaches. +search: '`applocker` | spath input=UserData_Xml | rename RuleAndFileData.* as *, Computer + as dest, TargetUser AS user | stats count min(_time) as firstTime max(_time) as + lastTime by dest, PolicyName, RuleId, user, TargetProcessId, FilePath, FullFilePath + | eventstats avg(count) as avg, stdev(count) as stdev | eval upperBound=(avg+stdev*2), + anomaly=if(count > upperBound, "Yes", "No") | where anomaly="Yes" | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_applocker_execution_from_uncommon_locations_filter`' +how_to_implement: The analytic is designed to be run against Windows AppLocker event + logs collected from endpoints with AppLocker enabled. If using Microsoft Defender + for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match + the block events for AppLocker. The analytic requires the AppLocker event logs to + be ingested into Splunk. Note that, an additional method to reduce any false positives + would be to add the specific EventCodes - 8003 or 8004 and filter from there. Upon + tuning, modify to Anomaly or TTP. +known_false_positives: False positives are possible if legitimate users are executing + applications from file paths that are not permitted by AppLocker. It is recommended + to investigate the context of the application execution to determine if it is malicious + or not. Modify the threshold as needed to reduce false positives. references: - https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/operations/querying-application-control-events-centrally-using-advanced-hunting - https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker @@ -49,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log sourcetype: xmlwineventlog - source: XmlWinEventLog:Microsoft-Windows-AppLocker/MSI and Script \ No newline at end of file + source: XmlWinEventLog:Microsoft-Windows-AppLocker/MSI and Script diff --git a/detections/endpoint/windows_applocker_privilege_escalation_via_unauthorized_bypass.yml b/detections/endpoint/windows_applocker_privilege_escalation_via_unauthorized_bypass.yml index 3ca9e28623..0dc0da18b9 100644 --- a/detections/endpoint/windows_applocker_privilege_escalation_via_unauthorized_bypass.yml +++ b/detections/endpoint/windows_applocker_privilege_escalation_via_unauthorized_bypass.yml @@ -47,6 +47,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-AppLocker/MSI and Script diff --git a/detections/endpoint/windows_applocker_rare_application_launch_detection.yml b/detections/endpoint/windows_applocker_rare_application_launch_detection.yml index f8b7da2868..3e97153c5e 100644 --- a/detections/endpoint/windows_applocker_rare_application_launch_detection.yml +++ b/detections/endpoint/windows_applocker_rare_application_launch_detection.yml @@ -1,20 +1,33 @@ name: Windows AppLocker Rare Application Launch Detection id: 9556f7b7-285f-4f18-8eeb-963d989f9d27 -version: 1 -date: '2024-03-21' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk data_source: [] type: Hunting -status: production -description: This analytic is designed to detect the launch of applications that occur rarely within the environment, which could indicate the use of potentially malicious software or tools by attackers. It works by aggregating the count of application launches over time, then calculating the average and standard deviation of these counts. Applications whose launch counts significantly deviate from the norm, either by exceeding or falling below three standard deviations from the average, are flagged for further investigation. This approach helps in identifying unusual application activity that could be indicative of a security threat. -search: '`applocker` - | spath input=UserData_Xml | rename RuleAndFileData.* as *, Computer as dest, TargetUser AS user - | stats dc(_time) as days, count by FullFilePath dest user - | eventstats avg(count) as avg, stdev(count) as stdev - | eval upperBound=(avg+stdev*3), lowerBound=(avg-stdev*3) - | where count > upperBound OR count < lowerBound | `windows_applocker_rare_application_launch_detection_filter`' -how_to_implement: The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there. -known_false_positives: False positives are possible if legitimate users are launching applications that are not permitted by AppLocker. It is recommended to investigate the context of the application launch to determine if it is malicious or not. Modify the threshold as needed to reduce false positives. +status: production +description: The following analytic detects the launch of rarely used applications + within the environment, which may indicate the use of potentially malicious software + or tools by attackers. It leverages Windows AppLocker event logs, aggregating application + launch counts over time and flagging those that significantly deviate from the norm. + This behavior is significant as it helps identify unusual application activity that + could signal a security threat. If confirmed malicious, this activity could allow + attackers to execute unauthorized code, potentially leading to further compromise + of the system. +search: '`applocker` | spath input=UserData_Xml | rename RuleAndFileData.* as *, Computer + as dest, TargetUser AS user | stats dc(_time) as days, count by FullFilePath dest + user | eventstats avg(count) as avg, stdev(count) as stdev | eval upperBound=(avg+stdev*3), + lowerBound=(avg-stdev*3) | where count > upperBound OR count < lowerBound | `windows_applocker_rare_application_launch_detection_filter`' +how_to_implement: The analytic is designed to be run against Windows AppLocker event + logs collected from endpoints with AppLocker enabled. If using Microsoft Defender + for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match + the block events for AppLocker. The analytic requires the AppLocker event logs to + be ingested into Splunk. Note that, an additional method to reduce any false positives + would be to add the specific EventCodes - 8003 or 8004 and filter from there. +known_false_positives: False positives are possible if legitimate users are launching + applications that are not permitted by AppLocker. It is recommended to investigate + the context of the application launch to determine if it is malicious or not. Modify + the threshold as needed to reduce false positives. references: - https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker - https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/operations/querying-application-control-events-centrally-using-advanced-hunting @@ -24,7 +37,8 @@ tags: asset_type: Endpoint confidence: 30 impact: 50 - message: An application launch that deviates from the norm was detected on a host $dest$. + message: An application launch that deviates from the norm was detected on a host + $dest$. mitre_attack_id: - T1218 observable: @@ -46,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/applocker/applocker.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-AppLocker/MSI and Script diff --git a/detections/endpoint/windows_archive_collected_data_via_powershell.yml b/detections/endpoint/windows_archive_collected_data_via_powershell.yml index 61962cced8..6e45ec66b2 100644 --- a/detections/endpoint/windows_archive_collected_data_via_powershell.yml +++ b/detections/endpoint/windows_archive_collected_data_via_powershell.yml @@ -1,23 +1,23 @@ name: Windows Archive Collected Data via Powershell id: 74c5a3b0-27a7-463c-9d00-1a5bb12cb7b5 -version: 1 -date: '2023-12-19' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies suspicious PowerShell script that archive files to a temp folder. - This anomaly detection serves as a valuable indicator to uncover threats from adversaries utilizing PowerShell scripts - for data archiving purposes. Identifying this method becomes pivotal in flagging and investigating potential threats, - enabling proactive measures threat actors leveraging similar PowerShell-based data collection and archiving techniques. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Compress-Archive*" ScriptBlockText = "*\\Temp\\*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID - | rename Computer as dest - | rename UserID as user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_archive_collected_data_via_powershell_filter`' +description: The following analytic detects the use of PowerShell scripts to archive + files into a temporary folder. It leverages PowerShell Script Block Logging, specifically + monitoring for the `Compress-Archive` command targeting the `Temp` directory. This + activity is significant as it may indicate an adversary's attempt to collect and + compress data for exfiltration. If confirmed malicious, this behavior could lead + to unauthorized data access and exfiltration, posing a severe risk to sensitive + information and overall network security. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Compress-Archive*" ScriptBlockText + = "*\\Temp\\*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode + ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_archive_collected_data_via_powershell_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -54,6 +54,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560/powershell_archive/powershell_archive.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560/powershell_archive/powershell_archive.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_archive_collected_data_via_rar.yml b/detections/endpoint/windows_archive_collected_data_via_rar.yml index c40dad972e..52f7397116 100644 --- a/detections/endpoint/windows_archive_collected_data_via_rar.yml +++ b/detections/endpoint/windows_archive_collected_data_via_rar.yml @@ -1,28 +1,28 @@ name: Windows Archive Collected Data via Rar id: 2015de95-fe91-413d-9d62-2fe011b67e82 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: The following analytic identifies a process execute a rar utilities to archive files. - This method has been exploited by various threat actors, including red-teamers and malware like DarkGate, - to gather and compress collected data on compromised hosts. Subsequently, these archives are transmitted to - command and control servers as part of their data exfiltration techniques. - These adversaries leverage RAR archiving to consolidate and compress collected data on compromised hosts. - Once the data is compiled into these archives, it serves as a means for these entities to effectively exfiltrate sensitive information. - This process involves transferring the archived data to command and control servers, - facilitating the extraction and retrieval of critical information from compromised systems. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name="Rar.exe" OR Processes.original_file_name = "Rar.exe" AND Processes.process = "*a*" Processes.process = "* -ep1*" Processes.process = "* -r*" Processes.process = "* -y*" - Processes.process = "* -v5m*" Processes.process = "* -m1*" - by Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.process_guid Processes.parent_process_name Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the execution of RAR utilities to archive + files on a system. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process names, GUIDs, and command-line arguments. This activity + is significant as threat actors, including red-teamers and malware like DarkGate, + use RAR archiving to compress and exfiltrate collected data from compromised hosts. + If confirmed malicious, this behavior could lead to the unauthorized transfer of + sensitive information to command and control servers, posing a severe risk to data + confidentiality and integrity. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name="Rar.exe" + OR Processes.original_file_name = "Rar.exe" AND Processes.process = "*a*" Processes.process + = "* -ep1*" Processes.process = "* -r*" Processes.process = "* -y*" Processes.process + = "* -v5m*" Processes.process = "* -m1*" by Processes.process_name Processes.original_file_name + Processes.process Processes.process_id Processes.process_guid Processes.parent_process_name + Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_archive_collected_data_via_rar_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -75,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility_darkgate/rar_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility_darkgate/rar_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_autoit3_execution.yml b/detections/endpoint/windows_autoit3_execution.yml index 4158c8942c..226da555e3 100644 --- a/detections/endpoint/windows_autoit3_execution.yml +++ b/detections/endpoint/windows_autoit3_execution.yml @@ -1,21 +1,37 @@ name: Windows AutoIt3 Execution id: 0ecb40d9-492b-4a57-9f87-515dd742794c -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic is designed to detect any execution of AutoIt3, a scripting language designed for automating the Windows GUI and general scripting. This includes instances where AutoIt3 has been renamed or otherwise altered in an attempt to evade detection. The analytic works by searching for process names or original file names that match 'autoit3.exe', which is the default executable for AutoIt scripts. This detection is important as AutoIt3 is often used by attackers to automate malicious activities, such as the execution of malware or other unwanted software. False positives may occur with legitimate uses of AutoIt3. +description: The following analytic detects the execution of AutoIt3, a scripting + language often used for automating Windows GUI tasks and general scripting. It identifies + instances where AutoIt3 or its variants are executed by searching for process names + or original file names matching 'autoit3.exe'. This activity is significant because + attackers frequently use AutoIt3 to automate malicious actions, such as executing + malware. If confirmed malicious, this activity could lead to unauthorized code execution, + system compromise, or further propagation of malware within the environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.process_name IN ("autoit3.exe", "autoit*.exe") OR Processes.original_file_name IN ("autoit3.exe", "autoit*.exe") - by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_autoit3_execution_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives may be present if the application is legitimately used, filter by user or endpoint as needed. + as lastTime from datamodel=Endpoint.Processes where Processes.process_name IN ("autoit3.exe", + "autoit*.exe") OR Processes.original_file_name IN ("autoit3.exe", "autoit*.exe") + by Processes.dest Processes.user Processes.parent_process_name Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_autoit3_execution_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: False positives may be present if the application is legitimately + used, filter by user or endpoint as needed. references: - https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2023-10-25-IOCs-from-DarkGate-activity.txt tags: @@ -25,7 +41,8 @@ tags: atomic_guid: [] confidence: 100 impact: 50 - message: Execution of AutoIt3 detected. The source process is $parent_process_name$ and the destination process is $process_name$ on $dest$ by + message: Execution of AutoIt3 detected. The source process is $parent_process_name$ + and the destination process is $process_name$ on $dest$ by mitre_attack_id: - T1059 observable: @@ -63,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_autostart_execution_lsass_driver_registry_modification.yml b/detections/endpoint/windows_autostart_execution_lsass_driver_registry_modification.yml index 639d32db3a..c3c0f33fdc 100644 --- a/detections/endpoint/windows_autostart_execution_lsass_driver_registry_modification.yml +++ b/detections/endpoint/windows_autostart_execution_lsass_driver_registry_modification.yml @@ -1,16 +1,18 @@ name: Windows Autostart Execution LSASS Driver Registry Modification id: 57fb8656-141e-4d8a-9f51-62cff4ecb82a -version: 1 -date: '2022-08-22' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the abuse of two undocumented registry - keys that allow for a DLL to load into lsass.exe to potentially capture credentials. - Upon successful modification of \CurrentControlSet\Services\NTDS\DirectoryServiceExtPt - or \CurrentControlSet\Services\NTDS\LsaDbExtPt, a DLL either remote or local will - be set as the value and load up into lsass.exe. Based on POC code a text file may - be written to disk with credentials. +description: The following analytic detects modifications to undocumented registry + keys that allow a DLL to load into lsass.exe, potentially capturing credentials. + It leverages the Endpoint.Registry data model to identify changes to \CurrentControlSet\Services\NTDS\DirectoryServiceExtPt + or \CurrentControlSet\Services\NTDS\LsaDbExtPt. This activity is significant as + it indicates a possible attempt to inject malicious code into the Local Security + Authority Subsystem Service (LSASS), which can lead to credential theft. If confirmed + malicious, this could allow attackers to gain unauthorized access to sensitive information + and escalate privileges within the environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -64,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.008/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.008/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_binary_proxy_execution_mavinject_dll_injection.yml b/detections/endpoint/windows_binary_proxy_execution_mavinject_dll_injection.yml index 5642b5ef8f..2f14bd3f8a 100644 --- a/detections/endpoint/windows_binary_proxy_execution_mavinject_dll_injection.yml +++ b/detections/endpoint/windows_binary_proxy_execution_mavinject_dll_injection.yml @@ -1,18 +1,18 @@ name: Windows Binary Proxy Execution Mavinject DLL Injection id: ccf4b61b-1b26-4f2e-a089-f2009c569c57 -version: 1 -date: '2022-07-07' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -description: Adversaries may abuse mavinject.exe to inject malicious DLLs into running - processes (i.e. Dynamic-link Library Injection), allowing for arbitrary code execution - (ex. C:\Windows\system32\mavinject.exe PID /INJECTRUNNING PATH_DLL). In addition - to Dynamic-link Library Injection, Mavinject.exe can also be abused to perform import - descriptor injection via its /HMODULE command-line parameter (ex. mavinject.exe - PID /HMODULE=BASE_ADDRESS PATH_DLL ORDINAL_NUMBER). This command would inject an - import table entry consisting of the specified DLL into the module at the given - base address. During triage, review file modifcations and parallel processes. +description: The following analytic detects the use of mavinject.exe for DLL injection + into running processes, identified by specific command-line parameters such as /INJECTRUNNING + and /HMODULE. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant because it indicates potential arbitrary code execution, a common + tactic for malware deployment and persistence. If confirmed malicious, this could + allow attackers to execute unauthorized code, escalate privileges, and maintain + persistence within the environment, posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -86,7 +86,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.013/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.013/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_boot_or_logon_autostart_execution_in_startup_folder.yml b/detections/endpoint/windows_boot_or_logon_autostart_execution_in_startup_folder.yml index 5532609a59..c7b1e4b4d2 100644 --- a/detections/endpoint/windows_boot_or_logon_autostart_execution_in_startup_folder.yml +++ b/detections/endpoint/windows_boot_or_logon_autostart_execution_in_startup_folder.yml @@ -1,24 +1,25 @@ name: Windows Boot or Logon Autostart Execution In Startup Folder id: 99d157cb-923f-4a00-aee9-1f385412146f -version: 1 -date: '2023-01-12' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic will identify suspicious files dropped or created in the Windows %startup% folder. - This technique is a common way to gain persistence on a targeted host. Threat actor, adversaries and red teamer - abuse this folder path to automatically execute their malicious sample upon boot or restart of the infected host. - This TTP detection is a good indicator that a suspicious process wants to gain persistence on the targeted host. We suggest to - verify the process name by using the process guid field, the file created and also the user and the computer name for further investigation. +description: The following analytic detects the creation of files in the Windows %startup% + folder, a common persistence technique. It leverages the Endpoint.Filesystem data + model to identify file creation events in this specific directory. This activity + is significant because adversaries often use the startup folder to ensure their + malicious code executes automatically upon system boot or user logon. If confirmed + malicious, this could allow attackers to maintain persistence on the host, potentially + leading to further system compromise and unauthorized access to sensitive information. data_source: - Sysmon EventID 11 -search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem - where Filesystem.file_path = "*\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" - by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name Filesystem.user Filesystem.file_path Filesystem.process_guid Filesystem.dest - | `drop_dm_object_name(Filesystem)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_boot_or_logon_autostart_execution_in_startup_folder_filter`' +search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_path = "*\\Microsoft\\Windows\\Start + Menu\\Programs\\Startup\\*" by Filesystem.file_create_time Filesystem.process_id + Filesystem.file_name Filesystem.user Filesystem.file_path Filesystem.process_guid + Filesystem.dest | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_boot_or_logon_autostart_execution_in_startup_folder_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. @@ -66,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_bootloader_inventory.yml b/detections/endpoint/windows_bootloader_inventory.yml index 6fedbe5add..a3c6ac2f68 100644 --- a/detections/endpoint/windows_bootloader_inventory.yml +++ b/detections/endpoint/windows_bootloader_inventory.yml @@ -1,21 +1,30 @@ name: Windows BootLoader Inventory id: 4f7e3913-4db3-4ccd-afe4-31198982305d -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: experimental type: Hunting data_source: [] -description: The following hunting query utilizes a PowerShell Scripted input that captures the bootloader paths for each Windows endpoint it is deployed to. The template inputs.conf is located in the references link. - By default, it only captures the path, but may be modified to capture everything that BCDedit provides. It can be verbose, but may be worth it. -search: '`bootloader_inventory` | stats count min(_time) as firstTime max(_time) - as lastTime values(_raw) by host | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_bootloader_inventory_filter`' -how_to_implement: To implement this analytic, a new stanza will need to be added to a inputs.conf and deployed to all or some Windows endpoints. https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 provides the stanza. If modifying the sourcetype, be sure to update the Macro for this analytic. Recommend running it daily, or weekly, depending on threat model. -known_false_positives: No false positives here, only bootloaders. Filter as needed or create a lookup as a baseline. +description: The following analytic identifies the bootloader paths on Windows endpoints. + It leverages a PowerShell Scripted input to capture this data, which is then processed + and aggregated using Splunk. Monitoring bootloader paths is significant for a SOC + as it helps detect unauthorized modifications that could indicate bootkits or other + persistent threats. If confirmed malicious, such activity could allow attackers + to maintain persistence, bypass security controls, and potentially control the boot + process, leading to full system compromise. +search: '`bootloader_inventory` | stats count min(_time) as firstTime max(_time) as + lastTime values(_raw) by host | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_bootloader_inventory_filter`' +how_to_implement: To implement this analytic, a new stanza will need to be added to + a inputs.conf and deployed to all or some Windows endpoints. https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 + provides the stanza. If modifying the sourcetype, be sure to update the Macro for + this analytic. Recommend running it daily, or weekly, depending on threat model. +known_false_positives: No false positives here, only bootloaders. Filter as needed + or create a lookup as a baseline. references: - - https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 - - https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ +- https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 +- https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ tags: analytic_story: - BlackLotus Campaign @@ -41,4 +50,4 @@ tags: - _time - _raw risk_score: 81 - security_domain: endpoint \ No newline at end of file + security_domain: endpoint diff --git a/detections/endpoint/windows_bypass_uac_via_pkgmgr_tool.yml b/detections/endpoint/windows_bypass_uac_via_pkgmgr_tool.yml index 5738aed020..baaaa620e6 100644 --- a/detections/endpoint/windows_bypass_uac_via_pkgmgr_tool.yml +++ b/detections/endpoint/windows_bypass_uac_via_pkgmgr_tool.yml @@ -1,24 +1,20 @@ name: Windows Bypass UAC via Pkgmgr Tool id: cce58e2c-988a-4319-9390-0daa9eefa3cd -version: 1 -date: '2023-07-26' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: The following analytic identifies a potentially suspicious execution - of the 'pkgmgr' process involving the use of an XML input file for package management. - The 'pkgmgr' process, though deprecated in modern Windows systems, was historically - used for managing packages. The presence of an XML input file raises concerns about - the nature of the executed command and its potential impact on the system. Due to - the deprecated status of 'pkgmgr' and the involvement of an XML file, this activity - warrants careful investigation. XML files are commonly used for configuration and - data exchange, making it crucial to ascertain the intentions and legitimacy of the - command. To ensure system security, it is recommended to use up-to-date package - management utilities, such as DISM or PowerShell's PackageManagement module, and - exercise caution when executing commands involving potentially sensitive operations - or files. +description: The following analytic detects the execution of the deprecated 'pkgmgr.exe' + process with an XML input file, which is unusual and potentially suspicious. This + detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on + process execution details and command-line arguments. The significance lies in the + deprecated status of 'pkgmgr.exe' and the use of XML files, which could indicate + an attempt to bypass User Account Control (UAC). If confirmed malicious, this activity + could allow an attacker to execute commands with elevated privileges, leading to + potential system compromise and unauthorized changes. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = pkgmgr.exe Processes.process = "*.xml*" NOT(Processes.parent_process_path IN("*:\\windows\\system32\\*", @@ -84,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/pkgmgr_uac_bypass/pkgmgr_create_file.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/pkgmgr_uac_bypass/pkgmgr_create_file.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_cab_file_on_disk.yml b/detections/endpoint/windows_cab_file_on_disk.yml index b39614152e..be9ec1dbfa 100644 --- a/detections/endpoint/windows_cab_file_on_disk.yml +++ b/detections/endpoint/windows_cab_file_on_disk.yml @@ -1,18 +1,36 @@ name: Windows CAB File on Disk id: 622f08d0-69ef-42c2-8139-66088bc25acd -version: 1 -date: '2023-11-08' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: Anomaly data_source: - Sysmon EventID 11 -description: The following analytic identifies .cab files being written to disk. Utilize this analytic as a way to hunt for suspect .cab files being written to non-standard paths and tune as needed. Cab files were recently being utilized to deliver .url files embedded. The .url files were then used to deliver malicious payloads. The search specifically looks for instances where the file name is '*.cab' and the action is 'write'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. +description: The following analytic detects .cab files being written to disk. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on events where + the file name is '*.cab' and the action is 'write'. This activity is significant + as .cab files can be used to deliver malicious payloads, including embedded .url + files that execute harmful code. If confirmed malicious, this behavior could lead + to unauthorized code execution and potential system compromise. Analysts should + review the file path and associated artifacts for further investigation. search: '| tstats `security_content_summariesonly` count values(Filesystem.file_path) - as file_path min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where (Filesystem.file_name=*.cab) by Filesystem.dest Filesystem.action Filesystem.process_id Filesystem.file_name - | `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_cab_file_on_disk_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives will only be present if a process legitimately writes a .cab file to disk. Modify the analytic as needed by file path. Filter as needed. + as file_path min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem + where (Filesystem.file_name=*.cab) by Filesystem.dest Filesystem.action Filesystem.process_id + Filesystem.file_name | `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_cab_file_on_disk_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: False positives will only be present if a process legitimately + writes a .cab file to disk. Modify the analytic as needed by file path. Filter as + needed. references: - https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2023-10-25-IOCs-from-DarkGate-activity.txt tags: @@ -44,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/cab_files.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/cab_files.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_cached_domain_credentials_reg_query.yml b/detections/endpoint/windows_cached_domain_credentials_reg_query.yml index 2269b4bec5..c1be8ead59 100644 --- a/detections/endpoint/windows_cached_domain_credentials_reg_query.yml +++ b/detections/endpoint/windows_cached_domain_credentials_reg_query.yml @@ -1,17 +1,18 @@ name: Windows Cached Domain Credentials Reg Query id: 40ccb8e0-1785-466e-901e-6a8b75c04ecd -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line related to the - discovery of cache domain credential logon count in the registry. This Technique - was being abused by several post exploitation tool like Winpeas where it query CachedLogonsCount - registry value in Winlogon registry. This value can be good information about the - login caching setting on the Windows OS target host. A value of 0 means login caching - is disable and values > 50 caches only 50 login attempts. By default all versions - of Windows 10 save cached logins except Windows Server 2008. +description: The following analytic identifies a process command line querying the + CachedLogonsCount registry value in the Winlogon registry. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and registry queries. Monitoring this activity is significant as it can + indicate the use of post-exploitation tools like Winpeas, which gather information + about login caching settings. If confirmed malicious, this activity could help attackers + understand login caching configurations, potentially aiding in credential theft + or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -77,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_change_default_file_association_for_no_file_ext.yml b/detections/endpoint/windows_change_default_file_association_for_no_file_ext.yml index 853763f307..5b487622a8 100644 --- a/detections/endpoint/windows_change_default_file_association_for_no_file_ext.yml +++ b/detections/endpoint/windows_change_default_file_association_for_no_file_ext.yml @@ -1,14 +1,18 @@ name: Windows Change Default File Association For No File Ext id: dbdf52ad-d6a1-4b68-975f-0a10939d8e38 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is developed to detect suspicious process commandline to - change or set the default file association of a file without file extension with - notepad.exe. This technique was seen in some APT and ransomware Prestige where it - set/modify the default process to run file association, like .txt to notepad.exe. +description: The following analytic detects attempts to change the default file association + for files without an extension to open with Notepad.exe. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on specific command-line + patterns and registry modifications. This activity is significant as it can indicate + an attempt to manipulate file handling behavior, a technique observed in APT and + ransomware attacks like Prestige. If confirmed malicious, this could allow attackers + to execute arbitrary code by tricking users into opening files, potentially leading + to system compromise or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/prestige_ransomware/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/prestige_ransomware/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_clipboard_data_via_get_clipboard.yml b/detections/endpoint/windows_clipboard_data_via_get_clipboard.yml index 156a89d1b0..4d38dd0681 100644 --- a/detections/endpoint/windows_clipboard_data_via_get_clipboard.yml +++ b/detections/endpoint/windows_clipboard_data_via_get_clipboard.yml @@ -1,21 +1,23 @@ name: Windows ClipBoard Data via Get-ClipBoard id: ab73289e-2246-4de0-a14b-67006c72a893 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a powershell script command to retrieve - clipboard data. This technique was seen in several post exploitation tools like - WINPEAS to steal sensitive information that was saved in clipboard. Using the Get-Clipboard - powershell commandlet, adversaries can be able collect data stored in clipboard - that might be a copied user name, password or other sensitive information. +description: The following analytic detects the execution of the PowerShell command + 'Get-Clipboard' to retrieve clipboard data. It leverages PowerShell Script Block + Logging (EventCode 4104) to identify instances where this command is used. This + activity is significant because it can indicate an attempt to steal sensitive information + such as usernames, passwords, or other confidential data copied to the clipboard. + If confirmed malicious, this behavior could lead to unauthorized access to sensitive + information, potentially compromising user accounts and other critical assets. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-Clipboard*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer - UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_clipboard_data_via_get_clipboard_filter`' + UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_clipboard_data_via_get_clipboard_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -31,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Powershell script $ScriptBlockText$ execute Get-Clipboard commandlet on $dest$ + message: Powershell script $ScriptBlockText$ execute Get-Clipboard commandlet on + $dest$ mitre_attack_id: - T1115 observable: @@ -59,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/powershell/windows-powershell-xml2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/powershell/windows-powershell-xml2.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_com_hijacking_inprocserver32_modification.yml b/detections/endpoint/windows_com_hijacking_inprocserver32_modification.yml index 1ffad64d33..0dca0667c7 100644 --- a/detections/endpoint/windows_com_hijacking_inprocserver32_modification.yml +++ b/detections/endpoint/windows_com_hijacking_inprocserver32_modification.yml @@ -1,18 +1,18 @@ name: Windows COM Hijacking InprocServer32 Modification id: b7bd83c0-92b5-4fc7-b286-23eccfa2c561 -version: 1 -date: '2022-09-26' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of reg.exe performing an add - to the InProcServer32, which may be related to COM hijacking. Adversaries can use - the COM system to insert malicious code that can be executed in place of legitimate - software through hijacking the COM references and relationships as a means for persistence. - Hijacking a COM object requires a change in the Registry to replace a reference - to a legitimate system component which may cause that component to not work when - executed. When that system component is executed through normal system operation - the adversary's code will be executed instead. +description: The following analytic detects the modification of the InProcServer32 + registry key by reg.exe, indicative of potential COM hijacking. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process and + command-line execution logs. COM hijacking is significant as it allows adversaries + to insert malicious code that executes in place of legitimate software, providing + a means for persistence. If confirmed malicious, this activity could enable attackers + to execute arbitrary code, disrupt legitimate system components, and maintain long-term + access to the compromised environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.015/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_command_and_scripting_interpreter_hunting_path_traversal.yml b/detections/endpoint/windows_command_and_scripting_interpreter_hunting_path_traversal.yml index 36bdfb13bb..bae81a6e17 100644 --- a/detections/endpoint/windows_command_and_scripting_interpreter_hunting_path_traversal.yml +++ b/detections/endpoint/windows_command_and_scripting_interpreter_hunting_path_traversal.yml @@ -1,17 +1,18 @@ name: Windows Command and Scripting Interpreter Hunting Path Traversal id: d0026380-b3c4-4da0-ac8e-02790063ff6b -version: 1 -date: '2022-06-01' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies path traversal command-line execution - and should be used to tune and driver other more higher fidelity analytics. This - technique was seen in malicious document that execute malicious code using msdt.exe - and path traversal technique that serve as defense evasion. This Hunting query is - a good pivot to look for possible suspicious process and command-line that runs - execute path traversal technique to run malicious code. This may help you to find - possible downloaded malware or other lolbin execution. +description: The following analytic identifies path traversal command-line executions, + leveraging data from Endpoint Detection and Response (EDR) agents. It detects patterns + in command-line arguments indicative of path traversal techniques, such as multiple + instances of "/..", "\..", or "\\..". This activity is significant as it often indicates + attempts to evade defenses by executing malicious code, such as through msdt.exe. + If confirmed malicious, this behavior could allow attackers to execute arbitrary + code, potentially leading to system compromise, data exfiltration, or further lateral + movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/path_traversal/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/path_traversal/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_command_and_scripting_interpreter_path_traversal_exec.yml b/detections/endpoint/windows_command_and_scripting_interpreter_path_traversal_exec.yml index 777d71c9a1..5158e43544 100644 --- a/detections/endpoint/windows_command_and_scripting_interpreter_path_traversal_exec.yml +++ b/detections/endpoint/windows_command_and_scripting_interpreter_path_traversal_exec.yml @@ -1,16 +1,18 @@ name: Windows Command and Scripting Interpreter Path Traversal Exec id: 58fcdeb1-728d-415d-b0d7-3ab18a275ec2 -version: 2 -date: '2022-06-01' +version: 3 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies path traversal command-line execution. - This technique was seen in malicious document that execute malicious code using - msdt.exe and path traversal technique that serve as defense evasion. This TTP is - a good pivot to look for more suspicious process and command-line that runs before - and after this execution. This may help you to find possible downloaded malware - or other lolbin execution. +description: The following analytic detects path traversal command-line execution, + often used in malicious documents to execute code via msdt.exe for defense evasion. + It leverages Endpoint Detection and Response (EDR) data, focusing on specific patterns + in process paths. This activity is significant as it can indicate an attempt to + bypass security controls and execute unauthorized code. If confirmed malicious, + this behavior could lead to code execution, privilege escalation, or persistence + within the environment, potentially allowing attackers to deploy malware or leverage + other living-off-the-land binaries (LOLBins). data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/path_traversal/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/path_traversal/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_command_shell_dcrat_forkbomb_payload.yml b/detections/endpoint/windows_command_shell_dcrat_forkbomb_payload.yml index 77158c2297..3c450a831b 100644 --- a/detections/endpoint/windows_command_shell_dcrat_forkbomb_payload.yml +++ b/detections/endpoint/windows_command_shell_dcrat_forkbomb_payload.yml @@ -1,16 +1,18 @@ name: Windows Command Shell DCRat ForkBomb Payload id: 2bb1a362-7aa8-444a-92ed-1987e8da83e1 -version: 1 -date: '2022-07-28' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies DCRat "forkbomb" payload feature. This - technique was seen in dark crystal RAT backdoor capabilities where it will execute - several cmd child process executing "notepad.exe & pause". The following analytic detects - the multiple cmd.exe and child process notepad.exe execution using batch script - in the targeted host within 30s timeframe. this TTP can be a good pivot to check - DCRat infection. +description: The following analytic detects the execution of a DCRat "forkbomb" payload, + which spawns multiple cmd.exe processes that launch notepad.exe instances in quick + succession. This detection leverages Endpoint Detection and Response (EDR) data, + focusing on the rapid creation of cmd.exe and notepad.exe processes within a 30-second + window. This activity is significant as it indicates a potential DCRat infection, + a known Remote Access Trojan (RAT) with destructive capabilities. If confirmed malicious, + this behavior could lead to system instability, resource exhaustion, and potential + disruption of services. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -76,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_forkbomb/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_forkbomb/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_command_shell_fetch_env_variables.yml b/detections/endpoint/windows_command_shell_fetch_env_variables.yml index f379ffb58a..657cb15392 100644 --- a/detections/endpoint/windows_command_shell_fetch_env_variables.yml +++ b/detections/endpoint/windows_command_shell_fetch_env_variables.yml @@ -1,17 +1,18 @@ name: Windows Command Shell Fetch Env Variables id: 048839e4-1eaa-43ff-8a22-86d17f6fcc13 -version: 1 -date: '2022-10-27' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP description: The following analytic identifies a suspicious process command line fetching - the environment variables with a non-shell parent process. This technique was seen - in qakbot malware where it fetches the environment variable in the target or compromised - host. This TTP detection is a good pivot of possible malicious behavior since the - command line is executed by a common non-shell process like cmd.exe , powershell.exe - and many more. This can also be a good sign that the parent process has a malicious - code injected to it to execute this command. + environment variables with a non-shell parent process. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on command-line executions and parent + process names. This activity is significant as it is commonly associated with malware + like Qakbot, which uses this technique to gather system information. If confirmed + malicious, this behavior could indicate that the parent process has been compromised, + potentially allowing attackers to execute arbitrary commands, escalate privileges, + or persist within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr/sysmon_wermgr.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr/sysmon_wermgr.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_common_abused_cmd_shell_risk_behavior.yml b/detections/endpoint/windows_common_abused_cmd_shell_risk_behavior.yml index 2550616e04..2e491afdbf 100644 --- a/detections/endpoint/windows_common_abused_cmd_shell_risk_behavior.yml +++ b/detections/endpoint/windows_common_abused_cmd_shell_risk_behavior.yml @@ -1,21 +1,19 @@ name: Windows Common Abused Cmd Shell Risk Behavior id: e99fcc4f-c6b0-4443-aa2a-e3c85126ec9a -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Correlation data_source: [] -description: The following correlation identifies instances where four or more distinct - detection analytics are associated with malicious command line behavior that is - known to be exploited by multiple threat actors, adversaries, or red teamers on - a specific host. By leveraging the Command Line Interface (CLI), attackers can execute - malicious commands, gain access to sensitive data, install backdoors, and engage - in various nefarious activities. The impact of such compromise can be severe, as - attackers may gain unauthorized control over the compromised system, enabling them - to exfiltrate valuable information, escalate privileges, or launch further attacks - within the network. If this detection is triggered, there is a high level of confidence - in the occurrence of suspicious command line activities on the host. +description: The following analytic identifies instances where four or more distinct + detection analytics are associated with malicious command line behavior on a specific + host. This detection leverages the Command Line Interface (CLI) data from various + sources to identify suspicious activities. This behavior is significant as it often + indicates attempts to execute malicious commands, access sensitive data, install + backdoors, or perform other nefarious actions. If confirmed malicious, attackers + could gain unauthorized control, exfiltrate information, escalate privileges, or + launch further attacks within the network, leading to severe compromise. search: '| 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 @@ -90,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/risk_behavior/abused_commandline/risk_recon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/risk_behavior/abused_commandline/risk_recon.log source: risk sourcetype: stash diff --git a/detections/endpoint/windows_computer_account_created_by_computer_account.yml b/detections/endpoint/windows_computer_account_created_by_computer_account.yml index 04dc959ff9..1d2617f73f 100644 --- a/detections/endpoint/windows_computer_account_created_by_computer_account.yml +++ b/detections/endpoint/windows_computer_account_created_by_computer_account.yml @@ -1,20 +1,25 @@ name: Windows Computer Account Created by Computer Account id: 97a8dc5f-8a7c-4fed-9e3e-ec407fd0268a -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifes a Computer Account creating a new Computer - Account with specific a Service Principle Name - "RestrictedKrbHost". The RestrictedKrbHost - service class allows client applications to use Kerberos authentication when they - do not have the identity of the service but have the server name. +description: The following analytic identifies a computer account creating a new computer + account with a specific Service Principal Name (SPN) "RestrictedKrbHost". This detection + leverages Windows Security Event Logs, specifically EventCode 4741, to identify + such activities. This behavior is significant as it may indicate an attempt to establish + unauthorized Kerberos authentication channels, potentially leading to lateral movement + or privilege escalation. If confirmed malicious, this activity could allow an attacker + to impersonate services, access sensitive information, or maintain persistence within + the network. data_source: - Windows Event Log Security 4741 -search: '`wineventlog_security` EventCode=4741 user_type=computer SubjectDomainName!="NT AUTHORITY" ServicePrincipalNames=*RestrictedKrbHost* - | stats count min(_time) as firstTime max(_time) as lastTime by dest, subject, action ,src_user, user, user_type, SubjectUserName,SubjectDomainName - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_computer_account_created_by_computer_account_filter`' +search: '`wineventlog_security` EventCode=4741 user_type=computer SubjectDomainName!="NT + AUTHORITY" ServicePrincipalNames=*RestrictedKrbHost* | stats count min(_time) as + firstTime max(_time) as lastTime by dest, subject, action ,src_user, user, user_type, + SubjectUserName,SubjectDomainName | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_computer_account_created_by_computer_account_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4741 EventCode enabled. The Windows TA is also required. @@ -30,7 +35,8 @@ tags: asset_type: Endpoint confidence: 60 impact: 50 - message: A Computer Account on $dest$ created by a computer account (possibly indicative of Kerberos relay attack). + message: A Computer Account on $dest$ created by a computer account (possibly indicative + of Kerberos relay attack). mitre_attack_id: - T1558 observable: @@ -57,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/windows_computer_account_created_by_computer_account/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/windows_computer_account_created_by_computer_account/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_conhost_with_headless_argument.yml b/detections/endpoint/windows_conhost_with_headless_argument.yml index f47fe647e5..3c99f93275 100644 --- a/detections/endpoint/windows_conhost_with_headless_argument.yml +++ b/detections/endpoint/windows_conhost_with_headless_argument.yml @@ -1,20 +1,38 @@ name: Windows ConHost with Headless Argument id: d5039508-998d-4cfc-8b5e-9dcd679d9a62 -version: 1 -date: '2023-11-01' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: 'The following analytic detects the unusual use of the Windows Console Host process (conhost.exe) with the undocumented --headless parameter to spawn a new process. This behavior is highly unusual and indicative of suspicious activity, as the --headless parameter is not commonly used in legitimate operations. The analytic identifies this behavior by looking for instances where conhost.exe is invoked with the --headless argument. This behavior is worth identifying for a Security Operations Center (SOC) as it could indicate an attacker''s attempt to execute commands or scripts in a stealthy manner, potentially to establish persistence, perform lateral movement, or carry out other malicious activities. If a true positive is identified, it suggests that an attacker has gained a foothold in the environment and is attempting to further their attack, which could lead to serious consequences such as data exfiltration, system compromise, or deployment of ransomware. Potential false positives could arise from legitimate administrative activity, hence it is important to validate the context of the detected behavior during triage.' +description: 'The following analytic detects the unusual invocation of the Windows + Console Host process (conhost.exe) with the undocumented --headless parameter. This + detection leverages Endpoint Detection and Response (EDR) telemetry, specifically + monitoring for command-line executions where conhost.exe is executed with the --headless + argument. This activity is significant for a SOC as it is not commonly used in legitimate + operations and may indicate an attacker''s attempt to execute commands stealthily. + If confirmed malicious, this behavior could lead to persistence, lateral movement, + or other malicious activities, potentially resulting in data exfiltration or system + compromise.' search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=conhost.exe Processes.process="*--headless *" by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_conhost_with_headless_argument_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives may be present if the application is legitimately used, filter by user or endpoint as needed. + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_conhost_with_headless_argument_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: False positives may be present if the application is legitimately + used, filter by user or endpoint as needed. references: - https://x.com/embee_research/status/1559410767564181504?s=20 - https://x.com/GroupIB_TI/status/1719675754886131959?s=20 @@ -55,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1564.003/headless/4688_conhost_headless.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1564.003/headless/4688_conhost_headless.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_credential_access_from_browser_password_store.yml b/detections/endpoint/windows_credential_access_from_browser_password_store.yml index ae1038466b..18dc559f24 100644 --- a/detections/endpoint/windows_credential_access_from_browser_password_store.yml +++ b/detections/endpoint/windows_credential_access_from_browser_password_store.yml @@ -1,7 +1,7 @@ name: Windows Credential Access From Browser Password Store id: 72013a8e-5cea-408a-9d51-5585386b4d69 version: 2 -date: '2024-02-20' +date: '2024-05-29' author: Teoderick Contreras, Bhavin Patel Splunk data_source: - Windows Event Log Security 4663 @@ -23,18 +23,24 @@ search: '`wineventlog_security` EventCode=4663 | `windows_credential_access_from_browser_password_store_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in - Group Policy. Then check the two boxes listed for both "Success" and "Failure." This search may trigger on a browser application that is not included in the browser_app_list lookup file. -known_false_positives: The lookup file `browser_app_list` may not contain all the browser applications that are allowed to access the browser user data profiles. Consider updating the lookup files to add allowed object paths for the browser applications that are not included in the lookup file. + Group Policy. Then check the two boxes listed for both "Success" and "Failure." + This search may trigger on a browser application that is not included in the browser_app_list + lookup file. +known_false_positives: The lookup file `browser_app_list` may not contain all the + browser applications that are allowed to access the browser user data profiles. + Consider updating the lookup files to add allowed object paths for the browser applications + that are not included in the lookup file. references: - - https://malpedia.caad.fkie.fraunhofer.de/details/win.404keylogger - - https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-malware/snake-keylogger-malware/ +- https://malpedia.caad.fkie.fraunhofer.de/details/win.404keylogger +- https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-malware/snake-keylogger-malware/ tags: analytic_story: - Snake Keylogger asset_type: Endpoint confidence: 50 impact: 50 - message: A non-common browser process $process_name$ accessing browser user data folder on $dest$ + message: A non-common browser process $process_name$ accessing browser user data + folder on $dest$ mitre_attack_id: - T1012 observable: @@ -60,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_credential_dumping_lsass_memory_createdump.yml b/detections/endpoint/windows_credential_dumping_lsass_memory_createdump.yml index db8319b2db..81aa7093f0 100644 --- a/detections/endpoint/windows_credential_dumping_lsass_memory_createdump.yml +++ b/detections/endpoint/windows_credential_dumping_lsass_memory_createdump.yml @@ -1,14 +1,17 @@ name: Windows Credential Dumping LSASS Memory Createdump id: b3b7ce35-fce5-4c73-85f4-700aeada81a9 -version: 1 -date: '2023-01-23' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of CreateDump.exe being used - to perform a process dump. This particular binary is not native to Windows, but - is found to be brought in my many different third party applications including PowerShell - 7. +description: The following analytic detects the use of CreateDump.exe to perform a + process dump. This binary is not native to Windows and is often introduced by third-party + applications, including PowerShell 7. The detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, GUIDs, and complete + command-line executions. This activity is significant as it may indicate an attempt + to dump LSASS memory, which can be used to extract credentials. If confirmed malicious, + this could lead to unauthorized access and lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/createdump_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/createdump_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_credentials_from_password_stores_chrome_extension_access.yml b/detections/endpoint/windows_credentials_from_password_stores_chrome_extension_access.yml index 4009521b51..e340082a93 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_chrome_extension_access.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_chrome_extension_access.yml @@ -1,21 +1,19 @@ name: Windows Credentials from Password Stores Chrome Extension Access id: 2e65afe0-9a75-4487-bd87-ada9a9f1b9af -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: This analytic focuses on identifying non-chrome processes that attempt - to access the Chrome extensions file. This file contains crucial settings and information - related to the browser's extensions installed on the computer. Adversaries and malware - authors have been known to exploit this file to extract sensitive information from - the Chrome browser on targeted hosts. Detecting such anomalous behavior provides - valuable insights for analyzing suspicious processes beyond the commonly observed - chrome.exe and explorer.exe executables. By monitoring for access to the Chrome - extensions file by non-chrome processes, we can enhance our ability to detect potential - threats and protect sensitive information stored within the browser. +description: The following analytic detects non-Chrome processes attempting to access + the Chrome extensions file. It leverages Windows Security Event logs, specifically + event code 4663, to identify this behavior. This activity is significant because + adversaries may exploit this file to extract sensitive information from the Chrome + browser, posing a security risk. If confirmed malicious, this could lead to unauthorized + access to stored credentials and other sensitive data, potentially compromising + the security of the affected system and broader network. search: '`wineventlog_security` EventCode=4663 object_file_path="*\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Local Extension Settings\\*" AND NOT (process_path IN ("*:\\Windows\\explorer.exe", "*\\chrome.exe")) | stats count min(_time) as firstTime max(_time) as lastTime by @@ -67,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/browser_ext_access/security-ext-raw.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/browser_ext_access/security-ext-raw.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_credentials_from_password_stores_chrome_localstate_access.yml b/detections/endpoint/windows_credentials_from_password_stores_chrome_localstate_access.yml index 740e85b594..fa7a0cbff2 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_chrome_localstate_access.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_chrome_localstate_access.yml @@ -1,28 +1,30 @@ name: Windows Credentials from Password Stores Chrome LocalState Access id: 3b1d09a8-a26f-473e-a510-6c6613573657 -version: 1 -date: '2023-04-26' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: This analytic is designed to detect non-chrome processes accessing the Chrome user data file called "local state." - This file contains important settings and information related to the browser's operations on the computer. Threat actors, - adversaries, and malware authors have been known to exploit this file in attempts to extract the encrypted master key used for - decrypting passwords saved in the Chrome browser. Detecting access to the "local state" file by non-chrome processes serves as - a valuable pivot for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. - By monitoring for this anomaly, we can improve our ability to identify potential threats and safeguard sensitive information stored within the browser. -search: '`wineventlog_security` EventCode=4663 object_file_path="*\\AppData\\Local\\Google\\Chrome\\User Data\\Local State" - NOT (process_name IN ("*\\chrome.exe","*:\\Windows\\explorer.exe")) - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_credentials_from_password_stores_chrome_localstate_access_filter`' +description: The following analytic detects non-Chrome processes accessing the Chrome + "Local State" file, which contains critical settings and information. It leverages + Windows Security Event logs, specifically event code 4663, to identify this behavior. + This activity is significant because threat actors can exploit this file to extract + the encrypted master key used for decrypting saved passwords in Chrome. If confirmed + malicious, this could lead to unauthorized access to sensitive information, posing + a severe security risk. Monitoring this anomaly helps identify potential threats + and safeguard browser-stored data. +search: '`wineventlog_security` EventCode=4663 object_file_path="*\\AppData\\Local\\Google\\Chrome\\User + Data\\Local State" NOT (process_name IN ("*\\chrome.exe","*:\\Windows\\explorer.exe")) + | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name + object_file_path process_name process_path process_id EventCode dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_credentials_from_password_stores_chrome_localstate_access_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." -known_false_positives: Uninstall chrome application may access this file and folder path to removed chrome installation in target host. Filter is needed. +known_false_positives: Uninstall chrome application may access this file and folder + path to removed chrome installation in target host. Filter is needed. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer tags: @@ -37,7 +39,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A non-chrome process $process_name$ accessing "Chrome\\User Data\\Local State" file on $dest$ + message: A non-chrome process $process_name$ accessing "Chrome\\User Data\\Local + State" file on $dest$ mitre_attack_id: - T1012 observable: @@ -63,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/chrome_local_state_simulate_access/redline-localstate-smalldata-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/chrome_local_state_simulate_access/redline-localstate-smalldata-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_credentials_from_password_stores_chrome_login_data_access.yml b/detections/endpoint/windows_credentials_from_password_stores_chrome_login_data_access.yml index 5bac7c13c0..729c15e631 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_chrome_login_data_access.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_chrome_login_data_access.yml @@ -1,28 +1,31 @@ name: Windows Credentials from Password Stores Chrome Login Data Access id: 0d32ba37-80fc-4429-809c-0ba15801aeaf -version: 1 -date: '2023-04-27' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: This analytic is designed to identify non-chrome processes accessing the Chrome user data file called "login data." - This SQLite database file contains important information related to the browser's operations on the computer. Threat actors, adversaries, - and malware authors have been known to exploit this file in attempts to extract and decrypt passwords saved in the Chrome browser. - Detecting access to the "login data" file by non-chrome processes serves as a valuable pivot for analyzing suspicious processes - beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for this anomaly, we can enhance our ability - to detect potential threats and protect sensitive information stored within the browser. -search: '`wineventlog_security` EventCode=4663 object_file_path="*\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Login Data" - AND NOT (process_path IN ("*:\\Windows\\explorer.exe", "*:\\Windows\\System32\\dllhost.exe", "*\\chrome.exe")) - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_credentials_from_password_stores_chrome_login_data_access_filter`' +description: The following analytic identifies non-Chrome processes accessing the + Chrome user data file "login data." This file is an SQLite database containing sensitive + information, including saved passwords. The detection leverages Windows Security + Event logs, specifically event code 4663, to monitor access attempts. This activity + is significant as it may indicate attempts by threat actors to extract and decrypt + stored passwords, posing a risk to user credentials. If confirmed malicious, attackers + could gain unauthorized access to sensitive accounts and escalate their privileges + within the environment. +search: '`wineventlog_security` EventCode=4663 object_file_path="*\\AppData\\Local\\Google\\Chrome\\User + Data\\Default\\Login Data" AND NOT (process_path IN ("*:\\Windows\\explorer.exe", + "*:\\Windows\\System32\\dllhost.exe", "*\\chrome.exe")) | stats count min(_time) + as firstTime max(_time) as lastTime by object_file_name object_file_path process_name + process_path process_id EventCode dest | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `windows_credentials_from_password_stores_chrome_login_data_access_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." -known_false_positives: Uninstall application may access this registry to remove the entry of the target application. filter is needed. +known_false_positives: Uninstall application may access this registry to remove the + entry of the target application. filter is needed. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer tags: @@ -37,7 +40,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A non-chrome process $process_name$ accessing Chrome "Login Data" file on $dest$ + message: A non-chrome process $process_name$ accessing Chrome "Login Data" file + on $dest$ mitre_attack_id: - T1012 observable: @@ -63,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/chrome_login_data_simulate_access/redline-login-data-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/chrome_login_data_simulate_access/redline-login-data-security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_credentials_from_password_stores_creation.yml b/detections/endpoint/windows_credentials_from_password_stores_creation.yml index f72a2cd1a1..ee120e6d34 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_creation.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_creation.yml @@ -1,25 +1,27 @@ name: Windows Credentials from Password Stores Creation id: c0c5a479-bf57-4ca0-af3a-4c7081e5ba05 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a process execution of Windows OS cmdkey.exe - tool. This tool is being abused or used by several post exploitation tool and malware such as - Darkgate malware to create stored user names, passwords - or credentials in the targeted Windows OS host. This information can be used by - the attacker to gain privilege escalation and persistence in the targeted hosts - for further attacks. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name="cmdkey.exe" OR Processes.original_file_name = "cmdkey.exe" AND Processes.process = "*/generic*" Processes.process IN ("*/user*", "*/password*") - by Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.process_guid Processes.parent_process_name Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of the Windows OS tool cmdkey.exe, + which is used to create stored usernames, passwords, or credentials. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + execution logs and command-line arguments. This activity is significant because + cmdkey.exe is often abused by post-exploitation tools and malware, such as Darkgate, + to gain unauthorized access. If confirmed malicious, this behavior could allow attackers + to escalate privileges and maintain persistence on the targeted host, facilitating + further attacks and potential data breaches. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name="cmdkey.exe" + OR Processes.original_file_name = "cmdkey.exe" AND Processes.process = "*/generic*" + Processes.process IN ("*/user*", "*/password*") by Processes.process_name Processes.original_file_name + Processes.process Processes.process_id Processes.process_guid Processes.parent_process_name + Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_credentials_from_password_stores_creation_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -71,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/cmdkey_create_credential_store/cmdkey_gen_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/cmdkey_create_credential_store/cmdkey_gen_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_credentials_from_password_stores_deletion.yml b/detections/endpoint/windows_credentials_from_password_stores_deletion.yml index 073acf2aa2..756e14a4d0 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_deletion.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_deletion.yml @@ -1,26 +1,27 @@ name: Windows Credentials from Password Stores Deletion id: 46d676aa-40c6-4fe6-b917-d23b621f0f89 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a process execution of Windows OS cmdkey.exe - tool. This tool is being abused or used by several post exploitation tool and malware such as - Darkgate malware to delete stored user names, passwords - or credentials in the targeted Windows OS host. This information can be used by - the attacker to gain privilege escalation and persistence in the targeted hosts - for further attacks. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name="cmdkey.exe" OR Processes.original_file_name = "cmdkey.exe" AND Processes.process = "*/delete*" +description: The following analytic detects the execution of the Windows OS tool cmdkey.exe + with the /delete parameter. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs and command-line arguments. + The activity is significant because cmdkey.exe can be used by attackers to delete + stored credentials, potentially leading to privilege escalation and persistence. + If confirmed malicious, this behavior could allow attackers to remove stored user + credentials, hindering incident response efforts and enabling further unauthorized + access to the compromised system. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name="cmdkey.exe" + OR Processes.original_file_name = "cmdkey.exe" AND Processes.process = "*/delete*" by Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.process_guid Processes.parent_process_name Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_credentials_from_password_stores_deletion_filter`' + Processes.process_guid Processes.parent_process_name Processes.parent_process Processes.parent_process_guid + Processes.dest Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_credentials_from_password_stores_deletion_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -71,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/cmdkey_delete_credentials_store/cmdkey_del_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1555/cmdkey_delete_credentials_store/cmdkey_del_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_credentials_from_password_stores_query.yml b/detections/endpoint/windows_credentials_from_password_stores_query.yml index 3c9a39c0b0..085ac15b7f 100644 --- a/detections/endpoint/windows_credentials_from_password_stores_query.yml +++ b/detections/endpoint/windows_credentials_from_password_stores_query.yml @@ -1,16 +1,18 @@ name: Windows Credentials from Password Stores Query id: db02d6b4-5d5b-4c33-8d8f-f0577516a8c7 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process execution of Windows OS cmdkey.exe - tool. This tool is being abused or used by several post exploitation tool such as - winpeas that being used by ransomware prestige to list stored user names, passwords - or credentials in the targeted Windows OS host. This information can be used by - the attacker to gain privilege escalation and persistence in the targeted hosts - for further attacks. +description: The following analytic detects the execution of the Windows OS tool cmdkey.exe, + which is often abused by post-exploitation tools like winpeas, commonly used in + ransomware attacks to list stored usernames, passwords, or credentials. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + execution logs. This activity is significant as it indicates potential credential + harvesting, which can lead to privilege escalation and persistence. If confirmed + malicious, attackers could gain unauthorized access to sensitive information and + maintain control over compromised systems for further exploitation. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_cmdkeylist/cmdkey-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_cmdkeylist/cmdkey-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_credentials_in_registry_reg_query.yml b/detections/endpoint/windows_credentials_in_registry_reg_query.yml index c3a7ba9c0b..206d4627e5 100644 --- a/detections/endpoint/windows_credentials_in_registry_reg_query.yml +++ b/detections/endpoint/windows_credentials_in_registry_reg_query.yml @@ -1,17 +1,18 @@ name: Windows Credentials in Registry Reg Query id: a8b3124e-2278-4b73-ae9c-585117079fb2 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line related to the - discovery of possible password or credentials in the registry. This technique is - being abused by adversaries or post exploitation tools like winpeas to steal credentials - in the registry in the targeted host. Registry can contain several sensitive information - like username and credentials that can be used for privilege escalation, persistence - or even in lateral movement. This Anomaly detection can be a good pivot to detect - a suspicious process querying a registry related to password or private keys. +description: The following analytic identifies processes querying the registry for + potential passwords or credentials. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command-line executions that access specific + registry paths known to store sensitive information. This activity is significant + as it may indicate credential theft attempts, often used by adversaries or post-exploitation + tools like winPEAS. If confirmed malicious, this behavior could lead to privilege + escalation, persistence, or lateral movement within the network, posing a severe + security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -78,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_pwd/query-putty-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_pwd/query-putty-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_curl_download_to_suspicious_path.yml b/detections/endpoint/windows_curl_download_to_suspicious_path.yml index cdf86a9e3d..7b943a9259 100644 --- a/detections/endpoint/windows_curl_download_to_suspicious_path.yml +++ b/detections/endpoint/windows_curl_download_to_suspicious_path.yml @@ -1,18 +1,18 @@ name: Windows Curl Download to Suspicious Path id: c32f091e-30db-11ec-8738-acde48001122 -version: 1 -date: '2021-10-19' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the use of Windows Curl.exe downloading - a file to a suspicious location. - - -O or --output is used when a file is to be downloaded and placed in a specified - location. - - During triage, review parallel processes for further behavior. In addition, identify - if the download was successful. If a file was downloaded, capture and analyze.' +description: 'The following analytic detects the use of Windows Curl.exe to download + a file to a suspicious location, such as AppData, ProgramData, or Public directories. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + command-line executions that include the -O or --output options. This activity is + significant because downloading files to these locations can indicate an attempt + to bypass security controls or establish persistence. If confirmed malicious, this + behavior could lead to unauthorized code execution, data exfiltration, or further + compromise of the system.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon_curl.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon_curl.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_curl_upload_to_remote_destination.yml b/detections/endpoint/windows_curl_upload_to_remote_destination.yml index 53cb82f67f..3c5a338023 100644 --- a/detections/endpoint/windows_curl_upload_to_remote_destination.yml +++ b/detections/endpoint/windows_curl_upload_to_remote_destination.yml @@ -1,28 +1,17 @@ name: Windows Curl Upload to Remote Destination id: 42f8f1a2-4228-11ec-aade-acde48001122 -version: 1 -date: '2021-11-10' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the use of Windows Curl.exe uploading - a file to a remote destination. - - `-T` or `--upload-file` is used when a file is to be uploaded to a remotge destination. - - - `-d` or `--data` POST is the HTTP method that was invented to send data to a receiving - web application, and it is, for example, how most common HTML forms on the web work. - - - HTTP multipart formposts are done with `-F`, but this appears to not be compatible - with the Windows version of Curl. Will update if identified adversary tradecraft. - - - Adversaries may use one of the three methods based on the remote destination and - what they are attempting to upload (zip vs txt). During triage, review parallel - processes for further behavior. In addition, identify if the upload was successful - in network logs. If a file was uploaded, isolate the endpoint and review.' +description: 'The following analytic detects the use of Windows Curl.exe to upload + a file to a remote destination. It identifies command-line arguments such as `-T`, + `--upload-file`, `-d`, `--data`, and `-F` in process execution logs. This activity + is significant because adversaries may use Curl to exfiltrate data or upload malicious + payloads. If confirmed malicious, this could lead to data breaches or further compromise + of the system. Analysts should review parallel processes and network logs to determine + if the upload was successful and isolate the endpoint if necessary.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -95,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon_curl_upload.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/windows-sysmon_curl_upload.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_data_destruction_recursive_exec_files_deletion.yml b/detections/endpoint/windows_data_destruction_recursive_exec_files_deletion.yml index 3e7c67923c..9832d05ab5 100644 --- a/detections/endpoint/windows_data_destruction_recursive_exec_files_deletion.yml +++ b/detections/endpoint/windows_data_destruction_recursive_exec_files_deletion.yml @@ -1,31 +1,32 @@ name: Windows Data Destruction Recursive Exec Files Deletion id: 3596a799-6320-4a2f-8772-a9e98ddb2960 -version: 2 -date: '2023-03-05' +version: 3 +date: '2024-05-24' author: Teoderick Contreras, Splunk, Steven Dick status: production type: TTP -description: This analytic identifies a suspicious process that is recursively deleting - files on a compromised host. This behavior has been observed in several types of destructive malware, - such as CaddyWiper, DoubleZero, and SwiftSlicer, which delete or overwrite - files with randomly generated strings to make recovery impossible. Additionally, this analytic can - detect potential recursive file writes across multiple files using Sysmon Event - 23 or 26. Sysmon considers a file as deleted as soon as it is overwritten. - This analytic serves as a strong indicator of potential destructive malware activity - on a host machine or the uninstallation of a large software application. +description: The following analytic identifies a suspicious process that is recursively + deleting executable files on a compromised host. It leverages Sysmon Event Codes + 23 and 26 to detect this activity by monitoring for a high volume of deletions or + overwrites of files with extensions like .exe, .sys, and .dll. This behavior is + significant as it is commonly associated with destructive malware such as CaddyWiper, + DoubleZero, and SwiftSlicer, which aim to make file recovery impossible. If confirmed + malicious, this activity could lead to significant data loss and system instability, + severely impacting business operations. data_source: - Sysmon EventID 23 - Sysmon EventID 26 -search: '`sysmon` EventCode IN ("23","26") TargetFilename IN ("*.exe", "*.sys", "*.dll") - | bin _time span=2m - | stats count, values(TargetFilename) as deleted_files, min(_time) as firstTime, max(_time) as lastTime by user, dest, signature, signature_id, Image, process_name, process_guid - | rename Image as process - | where count >=500 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_data_destruction_recursive_exec_files_deletion_filter`' -how_to_implement: To successfully implement this search, you need to ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. -known_false_positives: The uninstallation of a large software application or the use of cleanmgr.exe may trigger this detection. A filter is necessary to reduce false positives. +search: '`sysmon` EventCode IN ("23","26") TargetFilename IN ("*.exe", "*.sys", "*.dll") + | bin _time span=2m | stats count, values(TargetFilename) as deleted_files, min(_time) + as firstTime, max(_time) as lastTime by user, dest, signature, signature_id, Image, + process_name, process_guid | rename Image as process | where count >=500 | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_data_destruction_recursive_exec_files_deletion_filter`' +how_to_implement: To successfully implement this search, you need to ingest logs that + include the process name, TargetFilename, and ProcessID executions from your endpoints. + If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. +known_false_positives: The uninstallation of a large software application or the use + of cleanmgr.exe may trigger this detection. A filter is necessary to reduce false + positives. references: - https://www.welivesecurity.com/2023/01/27/swiftslicer-new-destructive-wiper-malware-ukraine/ tags: @@ -35,7 +36,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 80 - message: The process $process_name$ has removed a significant quantity of executable files, totaling [$count$], from the destination $dest$. + message: The process $process_name$ has removed a significant quantity of executable + files, totaling [$count$], from the destination $dest$. mitre_attack_id: - T1485 observable: @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/swift_slicer/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/swift_slicer/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_debugger_tool_execution.yml b/detections/endpoint/windows_debugger_tool_execution.yml new file mode 100644 index 0000000000..48e3b65ec4 --- /dev/null +++ b/detections/endpoint/windows_debugger_tool_execution.yml @@ -0,0 +1,74 @@ +name: Windows Debugger Tool Execution +id: e14d94a3-07fb-4b47-8406-f5e37180d422 +version: 1 +date: '2024-06-07' +author: Teoderick Contreras, Splunk +data_source: [] +type: Hunting +status: production +description: This analysis detects the use of debugger tools within a production environment. + While these tools are legitimate for file analysis and debugging, they are abused by malware + like PlugX and DarkGate for malicious DLL side-loading. The hunting query aids Security Operations Centers (SOCs) + in identifying potentially suspicious tool executions, particularly for non-technical users in the production network. +search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes + where Processes.process_name = "x32dbg.exe" OR Processes.process_name = "x64dbg.exe" OR Processes.process_name = "windbg.exe" + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `windows_debugger_tool_execution_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: administrator or IT professional may execute this application for verifying files or debugging application. +references: +- https://www.splunk.com/en_us/blog/security/enter-the-gates-an-analysis-of-the-darkgate-autoit-loader.html +- https://www.trendmicro.com/en_us/research/23/b/investigating-the-plugx-trojan-disguised-as-a-legitimate-windows.html +tags: + analytic_story: + - DarkGate Malware + - PlugX + asset_type: Endpoint + confidence: 30 + impact: 30 + message: a debugger $process_name$ is executed in $dest$ + mitre_attack_id: + - T1036 + observable: + - name: dest + type: Endpoint + role: + - Victim + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Processes.parent_process_name + - Processes.parent_process + - Processes.process_name + - Processes.process_id + - Processes.process + - Processes.dest + - Processes.user + - Processes.process_id + - Processes.parent_process_id + risk_score: 9 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036/debugger_execution/debugger.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defacement_modify_transcodedwallpaper_file.yml b/detections/endpoint/windows_defacement_modify_transcodedwallpaper_file.yml index f79e244c2f..4d56e2db30 100644 --- a/detections/endpoint/windows_defacement_modify_transcodedwallpaper_file.yml +++ b/detections/endpoint/windows_defacement_modify_transcodedwallpaper_file.yml @@ -1,16 +1,18 @@ name: Windows Defacement Modify Transcodedwallpaper File id: e11c3d90-5bc7-42ad-94cd-ba75db10d897 -version: 1 -date: '2022-08-25' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a modification to the Transcodedwallpaper - file in the wallpaper theme directory to change the wallpaper of the host machine. - This technique was seen in adversaries attempting to deface or change the desktop - wallpaper of the targeted host. During our testing, the common process that affects - or changes the wallpaper if a user changes it via desktop personalized setting is - explorer.exe. +description: The following analytic identifies modifications to the TranscodedWallpaper + file in the wallpaper theme directory, excluding changes made by explorer.exe. This + detection leverages the Endpoint.Processes and Endpoint.Filesystem data models to + correlate process activity with file modifications. This activity is significant + as it may indicate an adversary attempting to deface or change the desktop wallpaper + of a targeted host, a tactic often used to signal compromise or deliver a message. + If confirmed malicious, this could be a sign of unauthorized access and tampering, + potentially leading to further system compromise or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/wallpaper_via_transcodedwallpaper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/wallpaper_via_transcodedwallpaper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_default_group_policy_object_modified.yml b/detections/endpoint/windows_default_group_policy_object_modified.yml index c8376387ef..712adb5d73 100644 --- a/detections/endpoint/windows_default_group_policy_object_modified.yml +++ b/detections/endpoint/windows_default_group_policy_object_modified.yml @@ -1,22 +1,21 @@ name: Windows Default Group Policy Object Modified id: fe6a6cc4-9e0d-4d66-bcf4-2c7f44860876 -version: 1 -date: '2023-03-28' +version: 2 +date: '2024-05-26' author: Mauricio Velazco, Splunk status: production type: TTP data_source: - Windows Event Log Security 5136 -description: The following analytic leverages Event ID 5136 to identify the modification - of a default Group Policy Object. A fresh installation of an Active Directory network - will typically contain two default group policy objects `Default Domain Controllers - Policy` and `Default Domain Policy`. The default domain controllers policy is used - to enforce and set policies to all the domain controllers within the domain environment. - The default domain policy is linked to all users and computers by default. An adversary - who has obtained privileged access to an Active Directory network may modify the - default group policy objects to obtain further access, deploy persistence or execute - malware across a large number of hosts. Security teams should monitor the modification - of the default GPOs. +description: The following analytic detects modifications to default Group Policy + Objects (GPOs) using Event ID 5136. It monitors changes to the `Default Domain Controllers + Policy` and `Default Domain Policy`, which are critical for enforcing security settings + across domain controllers and all users/computers, respectively. This activity is + significant because unauthorized changes to these GPOs can indicate an adversary + with privileged access attempting to deploy persistence mechanisms or execute malware + across the network. If confirmed malicious, such modifications could lead to widespread + compromise, allowing attackers to maintain control and execute arbitrary code on + numerous hosts. search: ' `wineventlog_security` EventCode=5136 ObjectClass=groupPolicyContainer AttributeLDAPDisplayName=versionNumber (ObjectDN="CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=POLICIES,CN=SYSTEM,DC=*" OR ObjectDN="CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=POLICIES,CN=SYSTEM,DC=*") @@ -73,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_default_group_policy_object_modified_with_gpme.yml b/detections/endpoint/windows_default_group_policy_object_modified_with_gpme.yml index 48ced2ba59..8899947e04 100644 --- a/detections/endpoint/windows_default_group_policy_object_modified_with_gpme.yml +++ b/detections/endpoint/windows_default_group_policy_object_modified_with_gpme.yml @@ -1,22 +1,20 @@ name: Windows Default Group Policy Object Modified with GPME id: eaf688b3-bb8f-454d-b105-920a862cd8cb -version: 1 -date: '2023-04-24' +version: 2 +date: '2024-05-24' author: Mauricio Velazco, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic leverages the Endpoint datamodel to identify the - potential edition of a default Group Policy Object. A fresh installation of an Active - Directory network will typically contain two default group policy objects `Default - Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers - policy is used to enforce and set policies to all the domain controllers within - the domain environment. The default domain policy is linked to all users and computers - by default. An adversary who has obtained privileged access to an Active Directory - network may modify the default group policy objects to obtain further access, deploy - persistence or execute malware across a large number of hosts. Security teams should - monitor the edition of the default GPOs. +description: The following analytic detects modifications to default Group Policy + Objects (GPOs) using the Group Policy Management Editor (GPME). It leverages the + Endpoint data model to identify processes where `mmc.exe` executes `gpme.msc` with + specific GUIDs related to default GPOs. This activity is significant because default + GPOs, such as the `Default Domain Controllers Policy` and `Default Domain Policy`, + are critical for enforcing security policies across the domain. If malicious, such + modifications could allow an attacker to gain further access, establish persistence, + or deploy malware across numerous hosts, severely compromising the network's security. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=mmc.exe (Processes.process =*gpme.msc*) AND (Processes.process = "*31B2F340-016D-11D2-945F-00C04FB984F9*" @@ -88,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/default_domain_policy_modified/windows-security.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_asr_audit_events.yml b/detections/endpoint/windows_defender_asr_audit_events.yml index 1e15ad34e2..ea86b39227 100644 --- a/detections/endpoint/windows_defender_asr_audit_events.yml +++ b/detections/endpoint/windows_defender_asr_audit_events.yml @@ -1,7 +1,7 @@ name: Windows Defender ASR Audit Events id: 0e4d46b1-22bd-4f0e-8337-ca6f60ad4bea -version: 1 -date: '2023-11-27' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: Anomaly @@ -9,7 +9,7 @@ data_source: - Windows Event Log Defender 1122 - Windows Event Log Defender 1125 - Windows Event Log Defender 1126 -- Windows Event Log Defender 1132 +- Windows Event Log Defender 1132 - Windows Event Log Defender 1134 description: 'This detection searches for Windows Defender ASR audit events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR audit events that are generated when a process or application attempts to perform an action that would be blocked by an ASR rule, but is allowed to proceed for auditing purposes.' search: '`ms_defender` EventCode IN (1122, 1125, 1126, 1132, 1134) @@ -28,7 +28,7 @@ tags: atomic_guid: [] confidence: 50 impact: 10 - message: ASR audit event, $ASR_Rule$, was triggered on $dest$. + message: ASR audit event, $ASR_Rule$, was triggered on $dest$. mitre_attack_id: - T1059 - T1566.001 @@ -58,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_audit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_audit.log source: WinEventLog:Microsoft-Windows-Windows Defender/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_asr_block_events.yml b/detections/endpoint/windows_defender_asr_block_events.yml index a4d50aa676..7fefbb6800 100644 --- a/detections/endpoint/windows_defender_asr_block_events.yml +++ b/detections/endpoint/windows_defender_asr_block_events.yml @@ -1,7 +1,7 @@ name: Windows Defender ASR Block Events id: 026f5f4e-e99f-4155-9e63-911ba587300b -version: 1 -date: '2023-11-27' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: Anomaly @@ -9,7 +9,7 @@ data_source: - Windows Event Log Defender 1121 - Windows Event Log Defender 1126 - Windows Event Log Defender 1129 -- Windows Event Log Defender 1131 +- Windows Event Log Defender 1131 - Windows Event Log Defender 1133 description: 'This detection searches for Windows Defender ASR block events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR block events that are generated when a process or application attempts to perform an action that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.' search: '`ms_defender` EventCode IN (1121, 1126, 1129, 1131, 1133) @@ -58,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_block.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_block.log source: WinEventLog:Microsoft-Windows-Windows Defender/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_asr_registry_modification.yml b/detections/endpoint/windows_defender_asr_registry_modification.yml index 4209be0617..b354f2a3a5 100644 --- a/detections/endpoint/windows_defender_asr_registry_modification.yml +++ b/detections/endpoint/windows_defender_asr_registry_modification.yml @@ -1,13 +1,20 @@ name: Windows Defender ASR Registry Modification id: 6a1b6cbe-6612-44c3-92b9-1a1bd77412eb -version: 1 -date: '2023-11-27' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: Hunting data_source: - Windows Event Log Defender 5007 -description: 'This detection searches for Windows Defender ASR registry modification events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR registry modification events that are generated when a process or application attempts to modify a registry key that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.' +description: 'The following analytic detects modifications to Windows Defender Attack + Surface Reduction (ASR) registry settings. It leverages Windows Defender Operational + logs, specifically EventCode 5007, to identify changes in ASR rules. This activity + is significant because ASR rules are designed to block actions commonly used by + malware to exploit systems. Unauthorized modifications to these settings could indicate + an attempt to weaken system defenses. If confirmed malicious, this could allow an + attacker to bypass security measures, leading to potential system compromise and + data breaches.' search: '`ms_defender` EventCode IN (5007) | rex field=New_Value "0x(?\\d+)$" | rex field=Old_Value "0x(?\\d+)$" @@ -18,8 +25,15 @@ search: '`ms_defender` EventCode IN (5007) | lookup asr_rules ID AS ASR_ID OUTPUT ASR_Rule | `security_content_ctime(firstTime)`| rename host as dest | `security_content_ctime(lastTime)` | `windows_defender_asr_registry_modification_filter`' -how_to_implement: The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. -known_false_positives: False positives are expected from legitimate applications generating events that are similar to those generated by malicious activity. For example, Event ID 5007 is generated when a process attempts to modify a registry key that is related to ASR rules. This can be triggered by legitimate applications that attempt to modify registry keys that are not blocked by ASR rules. +how_to_implement: The following analytic requires collection of Windows Defender Operational + logs in either XML or multi-line. To collect, setup a new input for the Windows + Defender Operational logs. In addition, it does require a lookup that maps the ID + to ASR Rule name. +known_false_positives: False positives are expected from legitimate applications generating + events that are similar to those generated by malicious activity. For example, Event + ID 5007 is generated when a process attempts to modify a registry key that is related + to ASR rules. This can be triggered by legitimate applications that attempt to modify + registry keys that are not blocked by ASR rules. references: - https://asrgen.streamlit.app/ tags: @@ -57,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_registry.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_registry.log source: WinEventLog:Microsoft-Windows-Windows Defender/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_asr_rule_disabled.yml b/detections/endpoint/windows_defender_asr_rule_disabled.yml index a5dd4127ef..04693b4cf6 100644 --- a/detections/endpoint/windows_defender_asr_rule_disabled.yml +++ b/detections/endpoint/windows_defender_asr_rule_disabled.yml @@ -1,7 +1,7 @@ name: Windows Defender ASR Rule Disabled id: 429d611b-3183-49a7-b235-fc4203c4e1cb -version: 1 -date: '2023-11-27' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP @@ -57,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_disabled_registry.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_disabled_registry.log source: WinEventLog:Microsoft-Windows-Windows Defender/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_asr_rules_stacking.yml b/detections/endpoint/windows_defender_asr_rules_stacking.yml index 43ae285088..9ef8f5ab7b 100644 --- a/detections/endpoint/windows_defender_asr_rules_stacking.yml +++ b/detections/endpoint/windows_defender_asr_rules_stacking.yml @@ -1,23 +1,29 @@ name: Windows Defender ASR Rules Stacking id: 425a6657-c5e4-4cbb-909e-fc9e5d326f01 -version: 1 -date: '2023-11-20' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: Hunting -data_source: +data_source: - Windows Event Log Defender 1121 - Windows Event Log Defender 1122 - Windows Event Log Defender 1125 - Windows Event Log Defender 1126 - Windows Event Log Defender 1129 -- Windows Event Log Defender 1131 +- Windows Event Log Defender 1131 - Windows Event Log Defender 1133 - Windows Event Log Defender 1134 - Windows Event Log Defender 5007 -description: This hunting analytic targets a range of security events from Microsoft Defender, focusing on the Exploit Guard and Attack Surface Reduction (ASR) features. It monitors specific Event IDs - Event IDs 1121 and 1126 indicate active blocking of unauthorized operations or dangerous network connections, whereas Event IDs 1122 and 1125 represent audit logs for similar activities. Event ID 1129 shows user overrides on blocked operations. For ASR-related activities, Event IDs 1131 and 1133 signal blocked operations, while 1132 and 1134 are audit logs. Event ID 5007 alerts on configuration changes, possibly indicating security breaches. - - Additionally, the analytic utilizes a lookup to correlate ASR rule GUIDs with their descriptive names, enhancing understanding of the context behind these security alerts. This includes rules for blocking vulnerable drivers, restricting actions of Adobe Reader and Office applications, and protecting against various malware and unauthorized system changes. This comprehensive approach aids in assessing policy enforcement and potential security risks. +description: The following analytic identifies security events from Microsoft Defender, + focusing on Exploit Guard and Attack Surface Reduction (ASR) features. It detects + Event IDs 1121, 1126, 1131, and 1133 for blocked operations, and Event IDs 1122, + 1125, 1132, and 1134 for audit logs. Event ID 1129 indicates user overrides, while + Event ID 5007 signals configuration changes. This detection uses a lookup to correlate + ASR rule GUIDs with descriptive names. Monitoring these events is crucial for identifying + unauthorized operations, potential security breaches, and policy enforcement issues. + If confirmed malicious, attackers could bypass security measures, execute unauthorized + actions, or alter system configurations. search: '`ms_defender` EventCode IN (1121, 1122, 1125, 1126, 1129, 1131, 1132, 1133, 1134, 5007) | stats count min(_time) as firstTime max(_time) as lastTime by host Parent_Commandline, Process_Name, Path, ID, EventCode @@ -25,8 +31,17 @@ search: '`ms_defender` | fillnull value=NULL | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| rename host as dest | `windows_defender_asr_rules_stacking_filter`' -how_to_implement: The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore the analytic will need to be modified for each type of event. The analytic can be modified to look for specific ASR rules, or to look for specific Event IDs. EventID 5007 is a change in the registry, and may be a false positive. This can be removed from the search if desired. -known_false_positives: False positives are not expected with this analytic, since it is a hunting analytic. It is meant to show the use of ASR rules and how they can be used to detect malicious activity. +how_to_implement: The following analytic requires collection of Windows Defender Operational + logs in either XML or multi-line. To collect, setup a new input for the Windows + Defender Operational logs. In addition, it does require a lookup that maps the ID + to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore + the analytic will need to be modified for each type of event. The analytic can be + modified to look for specific ASR rules, or to look for specific Event IDs. EventID + 5007 is a change in the registry, and may be a false positive. This can be removed + from the search if desired. +known_false_positives: False positives are not expected with this analytic, since + it is a hunting analytic. It is meant to show the use of ASR rules and how they + can be used to detect malicious activity. references: - https://asrgen.streamlit.app/ - https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction?view=o365-worldwide @@ -67,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_defender_operational.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/defender/asr_defender_operational.log source: WinEventLog:Microsoft-Windows-Windows Defender/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_defender_exclusion_registry_entry.yml b/detections/endpoint/windows_defender_exclusion_registry_entry.yml index 38bad499ca..bd11dc18c9 100644 --- a/detections/endpoint/windows_defender_exclusion_registry_entry.yml +++ b/detections/endpoint/windows_defender_exclusion_registry_entry.yml @@ -1,23 +1,25 @@ name: Windows Defender Exclusion Registry Entry id: 13395a44-4dd9-11ec-9df7-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-21' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will detect a suspicious process that modify a registry - related to windows defender exclusion feature. This registry is abused by adversaries, - malware author and red teams to bypassed Windows Defender Anti-Virus product by - excluding folder path, file path, process, extensions and etc. from its real time - or schedule scan to execute their malicious code. This is a good indicator for a - defense evasion and to look further for events after this behavior. +description: The following analytic detects modifications to the Windows Defender + exclusion registry entries. It leverages endpoint registry data to identify changes + in the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Exclusions\\*". + This activity is significant because adversaries often modify these entries to bypass + Windows Defender, allowing malicious code to execute without detection. If confirmed + malicious, this behavior could enable attackers to evade antivirus defenses, maintain + persistence, and execute further malicious activities undetected. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Exclusions\\*") - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` + BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_defender_exclusion_registry_entry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -38,7 +40,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 80 - message: Exclusion registry $registry_path$ modified or added on $dest$ for Windows Defender + message: Exclusion registry $registry_path$ modified or added on $dest$ for Windows + Defender mitre_attack_id: - T1562.001 - T1562 @@ -67,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/defender_exclusion_sysmon/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/defender_exclusion_sysmon/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_delete_or_modify_system_firewall.yml b/detections/endpoint/windows_delete_or_modify_system_firewall.yml index d5c88db747..aa99fe8e6f 100644 --- a/detections/endpoint/windows_delete_or_modify_system_firewall.yml +++ b/detections/endpoint/windows_delete_or_modify_system_firewall.yml @@ -1,23 +1,25 @@ name: Windows Delete or Modify System Firewall id: b188d11a-eba7-419d-b8b6-cc265b4f2c4f -version: 1 -date: '2023-09-08' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This analytic identifies potentially malicious 'netsh' processes that manipulate firewall configurations. - This behavior has been observed in the NJRAT malware, which deletes its added firewall rules as part of its cleanup process. - Leveraging this anomaly detection can be a valuable approach for detecting malware, such as NJRAT, - that makes alterations to firewall configurations as a component of its malicious activities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where `process_netsh` Processes.process = "* firewall *" Processes.process = "* delete *" - by Processes.parent_process Processes.parent_process_name Processes.process_name Processes.process_id Processes.process_guid Processes.process Processes.user Processes.dest - | `drop_dm_object_name("Processes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_delete_or_modify_system_firewall_filter`' +description: The following analytic identifies 'netsh' processes that delete or modify + firewall configurations. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on command-line executions containing specific keywords. + This activity is significant because it can indicate malware, such as NJRAT, attempting + to alter firewall settings to evade detection or remove traces. If confirmed malicious, + this behavior could allow an attacker to disable security measures, facilitating + further compromise and persistence within the network. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where `process_netsh` Processes.process + = "* firewall *" Processes.process = "* delete *" by Processes.parent_process Processes.parent_process_name + Processes.process_name Processes.process_id Processes.process_guid Processes.process + Processes.user Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_delete_or_modify_system_firewall_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -64,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/njrat_delete_firewall/njrat_delete_firewall.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/njrat_delete_firewall/njrat_delete_firewall.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_deleted_registry_by_a_non_critical_process_file_path.yml b/detections/endpoint/windows_deleted_registry_by_a_non_critical_process_file_path.yml index ebbdd17b10..f681d34702 100644 --- a/detections/endpoint/windows_deleted_registry_by_a_non_critical_process_file_path.yml +++ b/detections/endpoint/windows_deleted_registry_by_a_non_critical_process_file_path.yml @@ -1,17 +1,17 @@ name: Windows Deleted Registry By A Non Critical Process File Path id: 15e70689-f55b-489e-8a80-6d0cd6d8aad2 -version: 2 -date: '2023-04-14' +version: 3 +date: '2024-05-16' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect deletion of registry with suspicious process - file path. This technique was seen in Double Zero wiper malware where it will delete - all the subkey in HKLM, HKCU and HKU registry hive as part of its destructive payload - to the targeted hosts. This anomaly detections can catch possible malware or advesaries - deleting registry as part of defense evasion or even payload impact but can also - catch for third party application updates or installation. In this scenario false - positive filter is needed. +description: The following analytic detects the deletion of registry keys by non-critical + processes. It leverages Endpoint Detection and Response (EDR) data, focusing on + registry deletion events and correlating them with processes not typically associated + with system or program files. This activity is significant as it may indicate malware, + such as the Double Zero wiper, attempting to evade defenses or cause destructive + payload impacts. If confirmed malicious, this behavior could lead to significant + system damage, loss of critical configurations, and potential disruption of services. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -46,7 +46,8 @@ tags: asset_type: Endpoint confidence: 60 impact: 60 - message: The registry was deleted by a suspicious process named $process_name$ with the process path $process_path$ on dest $dest$. + message: The registry was deleted by a suspicious process named $process_name$ with + the process path $process_path$ on dest $dest$. mitre_attack_id: - T1112 observable: @@ -79,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/doublezero_wiper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/doublezero_wiper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_change_password_through_registry.yml b/detections/endpoint/windows_disable_change_password_through_registry.yml index 021121d5aa..c561835edc 100644 --- a/detections/endpoint/windows_disable_change_password_through_registry.yml +++ b/detections/endpoint/windows_disable_change_password_through_registry.yml @@ -1,19 +1,19 @@ name: Windows Disable Change Password Through Registry id: 0df33e1a-9ef6-11ec-a1ad-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-19' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to disable - change password feature of the windows host. This registry modification may disables - the Change Password button on the Windows Security dialog box (which appears when - you press Ctrl+Alt+Del). As a result, users cannot change their Windows password - on demand. This technique was seen in some malware family like ransomware to prevent - the user to change the password after ownning the network or a system during attack. - This windows feature may implemented by administrator to prevent normal user to - change the password of a critical host or server, In this type of scenario filter - is needed to minimized false positive. +description: The following analytic detects a suspicious registry modification that + disables the Change Password feature on a Windows host. It identifies changes to + the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableChangePassword" + with a value of "0x00000001". This activity is significant as it can prevent users + from changing their passwords, a tactic often used by ransomware to maintain control + over compromised systems. If confirmed malicious, this could hinder user response + to an attack, allowing the attacker to persist and potentially escalate their access + within the network. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -64,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_lock_workstation_feature_through_registry.yml b/detections/endpoint/windows_disable_lock_workstation_feature_through_registry.yml index 4d02edfa7e..24eb798ef3 100644 --- a/detections/endpoint/windows_disable_lock_workstation_feature_through_registry.yml +++ b/detections/endpoint/windows_disable_lock_workstation_feature_through_registry.yml @@ -1,22 +1,26 @@ name: Windows Disable Lock Workstation Feature Through Registry id: c82adbc6-9f00-11ec-a81f-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-25' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to disable - Lock Computer windows features. This registry modification prevent the user from - locking its screen or computer that are being abused by several malware for example - ransomware. This technique was used by threat actor to make its payload more impactful - to the compromised host. +description: The following analytic detects a suspicious registry modification that + disables the Lock Computer feature in Windows. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableLockWorkstation" + with a value of "0x00000001". This activity is significant because it prevents users + from locking their screens, a tactic often used by malware, including ransomware, + to maintain control over compromised systems. If confirmed malicious, this could + allow attackers to sustain their presence and execute further malicious actions + without user interruption. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableLockWorkstation" - Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_disable_lock_workstation_feature_through_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -60,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_logoff_button_through_registry.yml b/detections/endpoint/windows_disable_logoff_button_through_registry.yml index 128d762c72..62e6d17639 100644 --- a/detections/endpoint/windows_disable_logoff_button_through_registry.yml +++ b/detections/endpoint/windows_disable_logoff_button_through_registry.yml @@ -1,28 +1,27 @@ name: Windows Disable LogOff Button Through Registry id: b2fb6830-9ed1-11ec-9fcb-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-30' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to disable - logoff feature in windows host. This registry when enable will prevent users to - log off of the system by using any method, including programs run from the command - line, such as scripts. It also disables or removes all menu items and buttons that - log the user off of the system. This technique was seen abused by ransomware malware - to make the compromised host un-useful and hard to remove other registry modification - made on the machine that needs restart to take effect. This windows feature may - implement by administrator in some server where shutdown is critical. In that scenario - filter of machine and users that can modify this registry is needed. +description: The following analytic detects a suspicious registry modification that + disables the logoff feature on a Windows host. It leverages data from the Endpoint.Registry + data model to identify changes to specific registry values associated with logoff + functionality. This activity is significant because it can indicate ransomware attempting + to make the compromised host unusable and hinder remediation efforts. If confirmed + malicious, this action could prevent users from logging off, complicate incident + response, and allow attackers to maintain persistence and control over the affected + system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\*" Registry.registry_value_name IN ("NoLogOff", "StartMenuLogOff") Registry.registry_value_data - = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name - Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_disable_logoff_button_through_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -67,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_memory_crash_dump.yml b/detections/endpoint/windows_disable_memory_crash_dump.yml index 21c1f1311d..e587837d60 100644 --- a/detections/endpoint/windows_disable_memory_crash_dump.yml +++ b/detections/endpoint/windows_disable_memory_crash_dump.yml @@ -1,16 +1,18 @@ name: Windows Disable Memory Crash Dump id: 59e54602-9680-11ec-a8a6-acde48001122 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a process that is attempting to disable - the ability on Windows to generate a memory crash dump. This was recently identified - being utilized by HermeticWiper. To disable crash dumps, the value must be set to - 0. This feature is typically modified to perform a memory crash dump when a computer - stops unexpectedly because of a Stop error (also known as a blue screen, system - crash, or bug check). +description: The following analytic detects attempts to disable the memory crash dump + feature on Windows systems by setting the registry value to 0. It leverages data + from the Endpoint.Registry datamodel, specifically monitoring changes to the CrashDumpEnabled + registry key. This activity is significant because disabling crash dumps can hinder + forensic analysis and incident response efforts. If confirmed malicious, this action + could be part of a broader attack strategy, such as data destruction or system destabilization, + as seen with HermeticWiper, potentially leading to significant operational disruptions + and data loss. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -19,9 +21,7 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint AND Registry.registry_value_data="0x00000000" by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.registry_key_name | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_disable_memory_crash_dump_filter`' + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_disable_memory_crash_dump_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` and `Registry` @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_notification_center.yml b/detections/endpoint/windows_disable_notification_center.yml index 3873de7f53..45cef9986b 100644 --- a/detections/endpoint/windows_disable_notification_center.yml +++ b/detections/endpoint/windows_disable_notification_center.yml @@ -1,15 +1,17 @@ name: Windows Disable Notification Center id: 1cd983c8-8fd6-11ec-a09d-acde48001122 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-28' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: The following search identifies a modification of registry to disable - the windows notification center feature in a windows host machine. This registry - modification removes notification and action center from the notification area on - the task bar. This modification are seen in RAT malware to cover their tracks upon - downloading other of its component or other payload. +description: The following analytic detects the modification of the Windows registry + to disable the Notification Center on a host machine. It leverages data from the + Endpoint.Registry data model, specifically looking for changes to the "DisableNotificationCenter" + registry value set to "0x00000001." This activity is significant because disabling + the Notification Center can be a tactic used by RAT malware to hide its presence + and subsequent actions. If confirmed malicious, this could allow an attacker to + operate stealthily, potentially leading to further system compromise and data exfiltration. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -62,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/disable_notif_center/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/disable_notif_center/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml b/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml index 0f78726686..762b4cfe59 100644 --- a/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml +++ b/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml @@ -1,22 +1,26 @@ name: Windows Disable or Modify Tools Via Taskkill id: a43ae66f-c410-4b3d-8741-9ce1ad17ddb0 -version: 1 -date: '2023-09-13' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This analytic is designed to identify potentially malicious processes that terminate other processes using taskkill.exe. - This technique has been observed in various malware instances, employed by adversaries and red teamers alike, to forcibly terminate - other processes whether they be security products or other legitimate applications as part of their malicious activities. - Detecting this anomaly serves as a valuable alert mechanism to identify suspicious processes or malware attempting to evade detection and disrupt system stability. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name = "taskkill.exe" Processes.process IN ("* /f*", "* /t*") Processes.process IN ("* /im*", "* /pid*") - by Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.process_guid Processes.user Processes.dest - | `drop_dm_object_name("Processes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the use of taskkill.exe to forcibly + terminate processes. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on command-line executions that include specific taskkill parameters. + This activity is significant because it can indicate attempts to disable security + tools or disrupt legitimate applications, a common tactic in malware operations. + If confirmed malicious, this behavior could allow attackers to evade detection, + disrupt system stability, and potentially gain further control over the compromised + system. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name = "taskkill.exe" + Processes.process IN ("* /f*", "* /t*") Processes.process IN ("* /im*", "* /pid*") + by Processes.parent_process_name Processes.parent_process Processes.process_name + Processes.process Processes.process_id Processes.process_guid Processes.user Processes.dest + | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_disable_or_modify_tools_via_taskkill_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -27,7 +31,8 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: Network administrator can use this application to kill process during audit or investigation. +known_false_positives: Network administrator can use this application to kill process + during audit or investigation. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat tags: @@ -73,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/taskkill/taskkill_im.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/taskkill/taskkill_im.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_shutdown_button_through_registry.yml b/detections/endpoint/windows_disable_shutdown_button_through_registry.yml index f634c6b352..a34a9efea4 100644 --- a/detections/endpoint/windows_disable_shutdown_button_through_registry.yml +++ b/detections/endpoint/windows_disable_shutdown_button_through_registry.yml @@ -1,25 +1,26 @@ name: Windows Disable Shutdown Button Through Registry id: 55fb2958-9ecd-11ec-a06a-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-19' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to disable - shutdown button on the logon user. This technique was seen in several malware especially - in ransomware family like killdisk malware variant to make the compromised host - un-useful and hard to remove other registry modification made on the machine that - needs restart to take effect. This windows feature may implement by administrator - in some server where shutdown is critical. In that scenario filter of machine and - users that can modify this registry is needed. +description: The following analytic detects suspicious registry modifications that + disable the shutdown button on a user's logon screen. It leverages data from the + Endpoint.Registry data model, specifically monitoring changes to registry paths + associated with shutdown policies. This activity is significant because it is a + tactic used by malware, particularly ransomware like KillDisk, to hinder system + usability and prevent the removal of malicious changes. If confirmed malicious, + this could impede system recovery efforts, making it difficult to restart the machine + and remove other harmful modifications. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE ((Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\shutdownwithoutlogon" Registry.registry_value_data = "0x00000000") OR (Registry.registry_path="*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoClose" - Registry.registry_value_data = "0x00000001")) BY _time span=1h Registry.dest Registry.user Registry.registry_path - Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.registry_value_data = "0x00000001")) BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_disable_shutdown_button_through_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting @@ -63,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disable_windows_group_policy_features_through_registry.yml b/detections/endpoint/windows_disable_windows_group_policy_features_through_registry.yml index bef9adc5a3..3870d1fb51 100644 --- a/detections/endpoint/windows_disable_windows_group_policy_features_through_registry.yml +++ b/detections/endpoint/windows_disable_windows_group_policy_features_through_registry.yml @@ -1,17 +1,18 @@ name: Windows Disable Windows Group Policy Features Through Registry id: 63a449ae-9f04-11ec-945e-acde48001122 -version: 4 -date: '2023-12-27' +version: 5 +date: '2024-05-27' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to disable - windows features. These techniques are seen in several ransomware malware to impair - the compromised host to make it hard for analyst to mitigate or response from the - attack. Disabling these known features make the analysis and forensic response more - hard. Disabling these feature is not so common but can still be implemented by the - administrator for security purposes. In this scenario filters for users that are - allowed doing this is needed. +description: The following analytic detects suspicious registry modifications aimed + at disabling Windows Group Policy features. It leverages data from the Endpoint.Registry + data model, focusing on specific registry paths and values associated with disabling + key Windows functionalities. This activity is significant because it is commonly + used by ransomware to hinder mitigation and forensic response efforts. If confirmed + malicious, this behavior could severely impair the ability of security teams to + analyze and respond to the attack, allowing the attacker to maintain control and + persist within the compromised environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -68,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_disableantispyware_registry.yml b/detections/endpoint/windows_disableantispyware_registry.yml index 56f4760159..55092c52fa 100644 --- a/detections/endpoint/windows_disableantispyware_registry.yml +++ b/detections/endpoint/windows_disableantispyware_registry.yml @@ -1,16 +1,19 @@ name: Windows DisableAntiSpyware Registry id: 23150a40-9301-4195-b802-5bb4f43067fb -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-28' author: Rod Soto, Jose Hernandez, Michael Haag, Splunk status: production type: TTP -description: The search looks for the Registry Key DisableAntiSpyware set to disable. - This is consistent with Ryuk infections across a fleet of endpoints. This particular - behavior is typically executed when an ransomware actor gains access to an endpoint - and beings to perform execution. Usually, a batch (.bat) will be executed and multiple - registry and scheduled task modifications will occur. During triage, review parallel - processes and identify any further file modifications. Endpoint should be isolated. +description: The following analytic detects the modification of the Windows Registry + key "DisableAntiSpyware" being set to disable. This detection leverages data from + the Endpoint.Registry datamodel, specifically looking for the registry value name + "DisableAntiSpyware" with a value of "0x00000001". This activity is significant + as it is commonly associated with Ryuk ransomware infections, indicating potential + malicious intent to disable Windows Defender. If confirmed malicious, this action + could allow attackers to disable critical security defenses, facilitating further + malicious activities such as data encryption, exfiltration, or additional system + compromise. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_diskcryptor_usage.yml b/detections/endpoint/windows_diskcryptor_usage.yml index 423664785b..c47287a5e0 100644 --- a/detections/endpoint/windows_diskcryptor_usage.yml +++ b/detections/endpoint/windows_diskcryptor_usage.yml @@ -1,15 +1,18 @@ name: Windows DiskCryptor Usage id: d56fe0c8-4650-11ec-a8fa-acde48001122 -version: 1 -date: '2021-11-15' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic identifies DiskCryptor process name of dcrypt.exe - or internal name dcinst.exe. This utility has been utilized by adversaries to encrypt - disks manually during an operation. In addition, during install, a dcrypt.sys driver - is installed and requires a reboot in order to take effect. There are no command-line - arguments used. +description: The following analytic detects the execution of DiskCryptor, identified + by the process names "dcrypt.exe" or "dcinst.exe". This detection leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + original file names. DiskCryptor is significant because adversaries use it to manually + encrypt disks during an operation, potentially leading to data inaccessibility. + If confirmed malicious, this activity could result in complete disk encryption, + causing data loss and operational disruption. Immediate investigation is required + to mitigate potential ransomware attacks. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1486/dcrypt/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1486/dcrypt/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_diskshadow_proxy_execution.yml b/detections/endpoint/windows_diskshadow_proxy_execution.yml index d526eef206..dcfe3f0c2a 100644 --- a/detections/endpoint/windows_diskshadow_proxy_execution.yml +++ b/detections/endpoint/windows_diskshadow_proxy_execution.yml @@ -1,16 +1,17 @@ name: Windows Diskshadow Proxy Execution id: 58adae9e-8ea3-11ec-90f6-acde48001122 -version: 1 -date: '2022-02-15' +version: 2 +date: '2024-05-18' author: Lou Stella, Splunk status: production type: TTP -description: DiskShadow.exe is a Microsoft Signed binary present on Windows Server. - It has a scripting mode intended for complex scripted backup operations. This feature - also allows for execution of arbitrary unsigned code. This analytic looks for the - usage of the scripting mode flags in executions of DiskShadow. During triage, compare - to known backup behavior in your environment and then review the scripts called - by diskshadow. +description: The following analytic detects the use of DiskShadow.exe in scripting + mode, which can execute arbitrary unsigned code. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on command-line executions with scripting + mode flags. This activity is significant because DiskShadow.exe is typically used + for legitimate backup operations, but its misuse can indicate an attempt to execute + unauthorized code. If confirmed malicious, this could lead to unauthorized code + execution, potentially compromising the system and allowing further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -66,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/diskshadow/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218/diskshadow/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_dll_search_order_hijacking_hunt_with_sysmon.yml b/detections/endpoint/windows_dll_search_order_hijacking_hunt_with_sysmon.yml index b03c8ce6da..d023af11cf 100644 --- a/detections/endpoint/windows_dll_search_order_hijacking_hunt_with_sysmon.yml +++ b/detections/endpoint/windows_dll_search_order_hijacking_hunt_with_sysmon.yml @@ -1,26 +1,30 @@ name: Windows DLL Search Order Hijacking Hunt with Sysmon id: 79c7d1fc-64c7-91be-a616-ccda752efe81 -version: 4 -date: '2024-03-17' +version: 5 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: Hunting -description: This hunting analytic identifies known Windows libraries - potentially used in DLL search order hijacking or DLL Sideloading scenarios. Such cases - may necessitate recompiling the DLL, relocating the DLL, or moving the vulnerable process. The - query searches for any processes running outside of system32 or syswow64 directories. Certain libraries - inherently operate from different application paths and must be added to the exclusion list - as required. The lookup includes Microsoft native libraries cataloged in the - Hijacklibs.net project. +description: The following analytic identifies potential DLL search order hijacking + or DLL sideloading by detecting known Windows libraries loaded from non-standard + directories. It leverages Sysmon EventCode 7 to monitor DLL loads and cross-references + them with a lookup of known hijackable libraries. This activity is significant as + it may indicate an attempt to execute malicious code by exploiting DLL search order + vulnerabilities. If confirmed malicious, this could allow attackers to gain code + execution, escalate privileges, or maintain persistence within the environment. data_source: - Sysmon EventID 7 -search: '`sysmon` EventCode=7 NOT (process_path IN ("*\\system32\\*", "*\\syswow64\\*","*\\winsxs\\*","*\\wbem\\*")) - | lookup hijacklibs library AS loaded_file OUTPUT islibrary - | search islibrary = True - | stats count min(_time) as firstTime max(_time) as lastTime values(process_name) as process_name by _time dest loaded_file | `windows_dll_search_order_hijacking_hunt_with_sysmon_filter`' -how_to_implement: The search is written against the latest Sysmon TA 4.0 https://splunkbase.splunk.com/app/5709. For this specific event ID 7, the sysmon TA will extract the ImageLoaded name to the loaded_file field which is used in the search to compare against the hijacklibs lookup. +search: '`sysmon` EventCode=7 NOT (process_path IN ("*\\system32\\*", "*\\syswow64\\*","*\\winsxs\\*","*\\wbem\\*")) + | lookup hijacklibs library AS loaded_file OUTPUT islibrary | search islibrary = + True | stats count min(_time) as firstTime max(_time) as lastTime values(process_name) + as process_name by _time dest loaded_file | `windows_dll_search_order_hijacking_hunt_with_sysmon_filter`' +how_to_implement: The search is written against the latest Sysmon TA 4.0 https://splunkbase.splunk.com/app/5709. + For this specific event ID 7, the sysmon TA will extract the ImageLoaded name to + the loaded_file field which is used in the search to compare against the hijacklibs + lookup. known_false_positives: False positives will be present based on paths. Filter or add - other paths to the exclusion as needed. Some applications may legitimately load libraries from non-standard paths. + other paths to the exclusion as needed. Some applications may legitimately load + libraries from non-standard paths. references: - https://hijacklibs.net tags: @@ -54,7 +58,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_dll_search_order_hijacking_with_iscsicpl.yml b/detections/endpoint/windows_dll_search_order_hijacking_with_iscsicpl.yml index 060f1aa821..dd0dea9bce 100644 --- a/detections/endpoint/windows_dll_search_order_hijacking_with_iscsicpl.yml +++ b/detections/endpoint/windows_dll_search_order_hijacking_with_iscsicpl.yml @@ -1,17 +1,18 @@ name: Windows DLL Search Order Hijacking with iscsicpl id: f39ee679-3b1e-4f47-841c-5c3c580acda2 -version: 1 -date: '2022-07-29' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a recently disclosed search ordler - DLL hijack in iscsicpl.exe. The malicious DLL must be in a new path and iscsicpl.exe, - upon load, will execute the payload. The analytic is restricted to Windows shells. - Two proof of concepts were identified and utilized to determine the behavior. The - command-line is an option to go after, but most likely identifying a child process - off iscsicpl.exe will be more effective. Monitoring for suspicious DLL loads is - also an option. +description: The following analytic detects DLL search order hijacking involving iscsicpl.exe. + It identifies when iscsicpl.exe loads a malicious DLL from a new path, triggering + the payload execution. This detection leverages data from Endpoint Detection and + Response (EDR) agents, focusing on child processes spawned by iscsicpl.exe. This + activity is significant as it indicates a potential attempt to execute unauthorized + code via DLL hijacking. If confirmed malicious, this could allow an attacker to + execute arbitrary code, escalate privileges, or maintain persistence within the + environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -84,7 +85,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.001/iscsicpl/iscsicpl-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.001/iscsicpl/iscsicpl-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_dll_side_loading_in_calc.yml b/detections/endpoint/windows_dll_side_loading_in_calc.yml index 5bf3f1def2..358f90443f 100644 --- a/detections/endpoint/windows_dll_side_loading_in_calc.yml +++ b/detections/endpoint/windows_dll_side_loading_in_calc.yml @@ -1,16 +1,18 @@ name: Windows DLL Side-Loading In Calc id: af01f6db-26ac-440e-8d89-2793e303f137 -version: 1 -date: '2022-10-24' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies suspicious DLL modules loaded by calc.exe - that are not in windows %systemroot%\system32 or %systemroot%\sysWoW64 folder. This - technique is well used by Qakbot malware to execute its malicious DLL file via dll - side loading technique in calc process execution. This TTP detection is a good indicator - that a suspicious dll was loaded in a public or non-common installation folder of - Windows Operating System that needs further investigation. +description: The following analytic detects suspicious DLL modules loaded by calc.exe + that are not located in the %systemroot%\system32 or %systemroot%\sysWoW64 directories. + This detection leverages Sysmon EventCode 7 to identify DLL side-loading, a technique + often used by Qakbot malware to execute malicious DLLs. This activity is significant + as it indicates potential malware execution through a trusted process, which can + bypass security controls. If confirmed malicious, this could allow attackers to + execute arbitrary code, maintain persistence, and escalate privileges within the + environment. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 Image = "*\calc.exe" AND NOT (Image IN ("*:\\windows\\system32\\*", @@ -63,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_dll_side_loading_process_child_of_calc.yml b/detections/endpoint/windows_dll_side_loading_process_child_of_calc.yml index 5e6232623e..7e98507043 100644 --- a/detections/endpoint/windows_dll_side_loading_process_child_of_calc.yml +++ b/detections/endpoint/windows_dll_side_loading_process_child_of_calc.yml @@ -1,19 +1,20 @@ name: Windows DLL Side-Loading Process Child Of Calc id: 295ca9ed-e97b-4520-90f7-dfb6469902e1 -version: 1 -date: '2022-10-20' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: The following analytic identifies the suspicious child process of calc.exe - due to dll side loading technique to execute another executable. This technique - was seen in qakbot malware that uses dll side loading technique to calc applications - to load its malicious dll code. The malicious dll that abuses dll side loading technique - will load the actual qakbot loader dll using regsvr32.exe application. This TTP - is a good indicator of qakbot since the calc.exe will not load other child processes - aside from win32calc.exe. +description: The following analytic identifies suspicious child processes spawned + by calc.exe, indicative of DLL side-loading techniques. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process GUIDs, + names, and parent processes. This activity is significant as it is commonly associated + with Qakbot malware, which uses calc.exe to load malicious DLLs via regsvr32.exe. + If confirmed malicious, this behavior could allow attackers to execute arbitrary + code, maintain persistence, and escalate privileges, posing a severe threat to the + environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.parent_process_name = "calc.exe") AND Processes.process_name != "win32calc.exe" by Processes.parent_process @@ -69,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_dns_gather_network_info.yml b/detections/endpoint/windows_dns_gather_network_info.yml index b183293b5e..2837575cb7 100644 --- a/detections/endpoint/windows_dns_gather_network_info.yml +++ b/detections/endpoint/windows_dns_gather_network_info.yml @@ -1,21 +1,19 @@ name: Windows DNS Gather Network Info id: 347e0892-e8f3-4512-afda-dc0e3fa996f3 -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk type: Anomaly status: production data_source: - Sysmon EventID 1 -description: The following analytic identifies a process command line used to enumerate - DNS records. Adversaries, threat actors, or red teamers may employ this technique - to gather information about a victim's DNS, which can be utilized during targeting. - This method was also observed as part of a tool used by the Sandworm APT group in - a geopolitical cyber warfare attack. By using the dnscmd.exe Windows application, - an attacker can enumerate DNS records for specific domains within the targeted network, - potentially aiding in further attacks. This anomaly detection can serve as a valuable - starting point for identifying users and hostnames that may be compromised or targeted - by adversaries seeking to collect data information. +description: The following analytic detects the use of the dnscmd.exe command to enumerate + DNS records. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process command-line executions. This activity is significant as it + may indicate an adversary gathering network information, a common precursor to more + targeted attacks. If confirmed malicious, this behavior could enable attackers to + map the network, identify critical assets, and plan subsequent actions, potentially + leading to data exfiltration or further compromise of the network. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = "dnscmd.exe" Processes.process = "* /enumrecords *" by Processes.parent_process Processes.process_name @@ -73,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1590.002/enum_dns_record/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1590.002/enum_dns_record/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_dnsadmins_new_member_added.yml b/detections/endpoint/windows_dnsadmins_new_member_added.yml index 46e3cc6784..a4559e7d79 100644 --- a/detections/endpoint/windows_dnsadmins_new_member_added.yml +++ b/detections/endpoint/windows_dnsadmins_new_member_added.yml @@ -1,22 +1,29 @@ name: Windows DnsAdmins New Member Added id: 27e600aa-77f8-4614-bc80-2662a67e2f48 -version: 3 -date: '2023-11-07' +version: 4 +date: '2024-05-29' author: Mauricio Velazco, Splunk status: production type: TTP data_source: - Windows Event Log Security 4732 -description: The following analytic leverages Event ID 4732 to identify the addition of a new member to the DnsAdmins group within Active Directory. . Members of the DnsAdmin group can manage - the DNS service which most of the times runs on the Domain Controller. By abusing legitimate DNS management functionality, a member of the DnsAdmins group can escalate privileges by - executing malicious code on a Domain Controller as SYSTEM. Security teams should monitor the modification of the DnsAdmins group and validate the changes are legitimate. -search: ' `wineventlog_security` EventCode=4732 TargetUserName=DnsAdmins | stats min(_time) as firstTime max(_time) as lastTime values(TargetUserName) as target_users_added values(user) as user by dest src_user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the addition of a new member to the DnsAdmins + group in Active Directory by leveraging Event ID 4732. This detection uses security + event logs to identify changes to this high-privilege group. Monitoring this activity + is crucial because members of the DnsAdmins group can manage the DNS service, often + running on Domain Controllers, and potentially execute malicious code with SYSTEM + privileges. If confirmed malicious, this activity could allow an attacker to escalate + privileges and gain control over critical domain services, posing a significant + security risk. +search: ' `wineventlog_security` EventCode=4732 TargetUserName=DnsAdmins | stats min(_time) + as firstTime max(_time) as lastTime values(TargetUserName) as target_users_added + values(user) as user by dest src_user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_dnsadmins_new_member_added_filter`' -how_to_implement: To successfully implement this search, Domain Controller events need to be ingested. The Advanced Security Audit policy setting `Audit Security Group Management` - within `Account Management` needs to be enabled. -known_false_positives: New members can be added to the DnsAdmins group as part of legitimate administrative tasks. Filter as needed. +how_to_implement: To successfully implement this search, Domain Controller events + need to be ingested. The Advanced Security Audit policy setting `Audit Security + Group Management` within `Account Management` needs to be enabled. +known_false_positives: New members can be added to the DnsAdmins group as part of + legitimate administrative tasks. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/ - https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/from-dnsadmins-to-system-to-domain-compromise @@ -53,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dnsadmins_member_added/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/dnsadmins_member_added/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_domain_account_discovery_via_get_netcomputer.yml b/detections/endpoint/windows_domain_account_discovery_via_get_netcomputer.yml index 8e78873549..ad82cbcb87 100644 --- a/detections/endpoint/windows_domain_account_discovery_via_get_netcomputer.yml +++ b/detections/endpoint/windows_domain_account_discovery_via_get_netcomputer.yml @@ -1,26 +1,30 @@ name: Windows Domain Account Discovery Via Get-NetComputer id: a7fbbc4e-4571-424a-b627-6968e1c939e4 -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Powershell Script Block Logging 4104 -description: The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetComputer. - This technique was seen used in the context of PowerView's Get-NetUser cmdlet as a filter or parameter - to query Active Directory user account's "samccountname", "accountexpires", "lastlogon" and so on. This hunting query is a good pivot to look for suspicious process - or malware that gather user account information in a host or within network system. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetComputer*" ScriptBlockText IN ("*samaccountname*", "*accountexpires*", "*lastlogon*", "*lastlogoff*", "*pwdlastset*", "*logoncount*") - | rename Computer as dest, UserID as user - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_domain_account_discovery_via_get_netcomputer_filter`' +description: The following analytic detects the execution of the PowerView PowerShell + cmdlet Get-NetComputer, which is used to query Active Directory for user account + details such as "samaccountname," "accountexpires," "lastlogon," and more. It leverages + Event ID 4104 from PowerShell Script Block Logging to identify this activity. This + behavior is significant as it may indicate an attempt to gather user account information, + which is often a precursor to further malicious actions. If confirmed malicious, + this activity could lead to unauthorized access, privilege escalation, or lateral + movement within the network. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-NetComputer*" ScriptBlockText + IN ("*samaccountname*", "*accountexpires*", "*lastlogon*", "*lastlogoff*", "*pwdlastset*", + "*logoncount*") | rename Computer as dest, UserID as user | stats count min(_time) + as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_domain_account_discovery_via_get_netcomputer_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Administrators may leverage PowerView for legitimate purposes, filter as needed. +known_false_positives: Administrators may leverage PowerView for legitimate purposes, + filter as needed. references: - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a tags: @@ -53,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/powerview_get_netuser_preauthnotrequire/get-netuser-not-require-pwh.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_domain_admin_impersonation_indicator.yml b/detections/endpoint/windows_domain_admin_impersonation_indicator.yml index f70354e62c..5d572bb1d3 100644 --- a/detections/endpoint/windows_domain_admin_impersonation_indicator.yml +++ b/detections/endpoint/windows_domain_admin_impersonation_indicator.yml @@ -1,7 +1,7 @@ name: Windows Domain Admin Impersonation Indicator id: 10381f93-6d38-470a-9c30-d25478e3bd3f version: 2 -date: '2023-10-06' +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP @@ -28,7 +28,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 80 - message: $TargetUserName$ may be impersonating a Domain Administrator through a forged Kerberos ticket. + message: $TargetUserName$ may be impersonating a Domain Administrator through a + forged Kerberos ticket. mitre_attack_id: - T1558 observable: @@ -51,6 +52,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/diamond_ticket/security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/diamond_ticket/security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_dotnet_binary_in_non_standard_path.yml b/detections/endpoint/windows_dotnet_binary_in_non_standard_path.yml index 6eba7d2344..3592aa6915 100644 --- a/detections/endpoint/windows_dotnet_binary_in_non_standard_path.yml +++ b/detections/endpoint/windows_dotnet_binary_in_non_standard_path.yml @@ -1,28 +1,29 @@ name: Windows DotNet Binary in Non Standard Path id: fddf3b56-7933-11ec-98a6-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies native .net binaries within the Windows - operating system that may be abused by adversaries by moving it to a new directory. - The analytic identifies the .net binary by using a lookup and compares the process - name and original file name (internal name). The analytic utilizes a lookup with - the is_net_windows_file_macro macro to identify the binary process name and original file - name. if one or the other matches an alert will be generated. Adversaries abuse - these binaries as they are native to windows and native DotNet. Note that not all - SDK (post install of Windows) are captured in the lookup. +description: The following analytic detects the execution of native .NET binaries + from non-standard directories within the Windows operating system. It leverages + Endpoint Detection and Response (EDR) telemetry, comparing process names and original + file names against a predefined lookup using the `is_net_windows_file_macro` macro. + This activity is significant because adversaries may move .NET binaries to unconventional + paths to evade detection and execute malicious code. If confirmed malicious, this + behavior could allow attackers to execute arbitrary code, escalate privileges, or + maintain persistence within the environment, posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where NOT (Processes.process_path IN ("*\\Windows\\ADWS\\*","*\\Windows\\SysWOW64*", "*\\Windows\\system32*", "*\\Windows\\NetworkController\\*", "*\\Windows\\SystemApps\\*", "*\\WinSxS\\*", "*\\Windows\\Microsoft.NET\\*")) by - Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process - Processes.original_file_name Processes.process_path Processes.process_id Processes.parent_process_id - | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `is_net_windows_file_macro` | `windows_dotnet_binary_in_non_standard_path_filter`' + Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.process_name Processes.process Processes.original_file_name Processes.process_path + Processes.process_id Processes.parent_process_id | `drop_dm_object_name("Processes")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `is_net_windows_file_macro` + | `windows_dotnet_binary_in_non_standard_path_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -97,6 +98,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon_installutil_path.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon_installutil_path.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_driver_inventory.yml b/detections/endpoint/windows_driver_inventory.yml index 07510dc9cc..4998c8378d 100644 --- a/detections/endpoint/windows_driver_inventory.yml +++ b/detections/endpoint/windows_driver_inventory.yml @@ -1,15 +1,16 @@ name: Windows Driver Inventory id: f87aa96b-369b-4a3e-9021-1bbacbfcb8fb -version: 1 -date: '2023-02-03' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: experimental type: Hunting -description: The following hunting / inventory query assists defenders in identifying - Drivers being loaded across the fleet. This query relies upon a PowerShell script - input to be deployed to critical systems and beyond. If capturing all via the input, - this will provide retrospection into drivers persisting. Note, that this is not - perfect across a large fleet. Modify the query as you need to view the data differently. +description: The following analytic identifies drivers being loaded across the fleet. + It leverages a PowerShell script input deployed to critical systems to capture driver + data. This detection is significant as it helps monitor for unauthorized or malicious + drivers that could compromise system integrity. If confirmed malicious, such drivers + could allow attackers to execute arbitrary code, escalate privileges, or maintain + persistence within the environment. data_source: [] search: '`driverinventory` | stats values(Path) min(_time) as firstTime max(_time) as lastTime count by host DriverType | rename host as dest | `security_content_ctime(firstTime)` @@ -48,7 +49,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/driver_inventory.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/driver_inventory.log source: PwSh:DriverInventory sourcetype: PwSh:DriverInventory update_timestamp: true diff --git a/detections/endpoint/windows_driver_load_non_standard_path.yml b/detections/endpoint/windows_driver_load_non_standard_path.yml index 59c74b59c2..9dd0aacff0 100644 --- a/detections/endpoint/windows_driver_load_non_standard_path.yml +++ b/detections/endpoint/windows_driver_load_non_standard_path.yml @@ -1,69 +1,70 @@ name: Windows Driver Load Non-Standard Path id: 9216ef3d-066a-4958-8f27-c84589465e62 -version: 2 -date: "2023-02-24" +version: 3 +date: "2024-05-22" author: Michael Haag, Splunk status: production type: TTP -description: - The following analytic uses Windows EventCode 7045 to identify new Kernel - Mode Drivers being loaded in Windows from a non-standard path. Note that, adversaries - may move malicious or vulnerable drivers into these paths and load up. The idea - is that this analytic provides visibility into drivers loading in non-standard file - paths. +description: The following analytic detects the loading of new Kernel Mode Drivers + from non-standard paths using Windows EventCode 7045. It identifies drivers not + located in typical directories like Windows, Program Files, or SystemRoot. This + activity is significant because adversaries may use these non-standard paths to + load malicious or vulnerable drivers, potentially bypassing security controls. If + confirmed malicious, this could allow attackers to execute code at the kernel level, + escalate privileges, or maintain persistence within the environment, posing a severe + threat to system integrity and security. data_source: - - Windows Event Log System 7045 -search: '`wineventlog_system` EventCode=7045 ServiceType="kernel mode driver" NOT (ImagePath IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", "system32\*")) - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ImagePath ServiceName ServiceType | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_driver_load_non_standard_path_filter`' -how_to_implement: - To implement this analytic, the Windows EventCode 7045 will need +- Windows Event Log System 7045 +search: '`wineventlog_system` EventCode=7045 ServiceType="kernel mode driver" NOT + (ImagePath IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", + "system32\*")) | stats count min(_time) as firstTime max(_time) as lastTime by Computer + EventCode ImagePath ServiceName ServiceType | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_driver_load_non_standard_path_filter`' +how_to_implement: To implement this analytic, the Windows EventCode 7045 will need to be logged. The Windows TA for Splunk is also recommended. -known_false_positives: - False positives may be present based on legitimate third party +known_false_positives: False positives may be present based on legitimate third party applications needing to install drivers. Filter, or allow list known good drivers consistently being installed in these paths. references: - - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/ - - https://attack.mitre.org/techniques/T1014/ - - https://www.fuzzysecurity.com/tutorials/28.html +- https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/ +- https://attack.mitre.org/techniques/T1014/ +- https://www.fuzzysecurity.com/tutorials/28.html tags: - analytic_story: - - Windows Drivers - - CISA AA22-320A - - AgentTesla - - BlackByte Ransomware + analytic_story: + - Windows Drivers + - CISA AA22-320A + - AgentTesla + - BlackByte Ransomware asset_type: Endpoint confidence: 60 impact: 60 message: A kernel mode driver was loaded from a non-standard path on $dest$. mitre_attack_id: - - T1014 - - T1068 + - T1014 + - T1068 observable: - - name: dest - type: Endpoint - role: - - Victim + - name: dest + type: Endpoint + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - Computer - - EventCode - - ImagePath - - ServiceName - - ServiceType + - _time + - Computer + - EventCode + - ImagePath + - ServiceName + - ServiceType risk_score: 36 security_domain: endpoint tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/xml7045_windows-system.log - source: XmlWinEventLog:System - sourcetype: XmlWinEventLog - update_timestamp: true \ No newline at end of file +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/xml7045_windows-system.log + source: XmlWinEventLog:System + sourcetype: XmlWinEventLog + update_timestamp: true diff --git a/detections/endpoint/windows_drivers_loaded_by_signature.yml b/detections/endpoint/windows_drivers_loaded_by_signature.yml index cd1d824d2e..1f813a27d6 100644 --- a/detections/endpoint/windows_drivers_loaded_by_signature.yml +++ b/detections/endpoint/windows_drivers_loaded_by_signature.yml @@ -1,21 +1,22 @@ name: Windows Drivers Loaded by Signature id: d2d4af6a-6c2b-4d79-80c5-fc2cf12a2f68 -version: 1 -date: '2022-03-30' +version: 2 +date: '2024-05-10' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic assists with viewing all drivers being loaded - by using Sysmon EventCode 6 (Driver Load). Sysmon provides some simple fields to - assist with identifying suspicious drivers. Use this analytic to look at prevalence - of driver (count), path of driver, signature status and hash. Review these fields - with scrutiny until the ability to prove the driver is legitimate and has a purpose - in the environment. +description: The following analytic identifies all drivers being loaded on Windows + systems using Sysmon EventCode 6 (Driver Load). It leverages fields such as driver + path, signature status, and hash to detect potentially suspicious drivers. This + activity is significant for a SOC as malicious drivers can be used to gain kernel-level + access, bypass security controls, or persist in the environment. If confirmed malicious, + this activity could allow an attacker to execute arbitrary code with high privileges, + leading to severe system compromise and potential data exfiltration. data_source: - Sysmon EventID 6 search: '`sysmon` EventCode=6 | stats min(_time) as firstTime max(_time) as lastTime - values(ImageLoaded) count by dest Signed Signature service_signature_verified - service_signature_exists Hashes | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + values(ImageLoaded) count by dest Signed Signature service_signature_verified service_signature_exists + Hashes | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_drivers_loaded_by_signature_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your @@ -64,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1014/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1014/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml index 2a58edf0eb..f457c864d3 100644 --- a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml +++ b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml @@ -1,21 +1,40 @@ name: Windows Enable Win32 ScheduledJob via Registry id: 12c80db8-ef62-4456-92df-b23e1b3219f6 -version: 1 -date: '2023-03-27' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk type: Anomaly status: production data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: 'This analytic searches for a registry modification that enables the use of the at.exe or wmi Win32_ScheduledJob command to add scheduled tasks on a Windows endpoint. Specifically, it looks for the creation of a new DWORD value named "EnableAt" in the following registry path: "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration". If this value is set to 1, it enables the at.exe and wmi Win32_ScheduledJob commands to schedule tasks on the system. Detecting this registry modification is important because it may indicate that an attacker has enabled the ability to add scheduled tasks to the system, which can be used to execute malicious code at specific times or intervals.' +description: 'The following analytic detects the creation of a new DWORD value named + "EnableAt" in the registry path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration". + This modification enables the use of the at.exe or wmi Win32_ScheduledJob commands + to add scheduled tasks on a Windows endpoint. The detection leverages registry event + data from the Endpoint datamodel. This activity is significant because it may indicate + that an attacker is enabling the ability to schedule tasks, potentially to execute + malicious code at specific times or intervals. If confirmed malicious, this could + allow persistent code execution on the system.' search: '| tstats `security_content_summariesonly` count values(Registry.registry_key_name) as registry_key_name values(Registry.registry_path) as registry_path min(_time) - as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\CurrentVersion\\Schedule\\Configuration*" Registry.registry_value_name=EnableAt by - Registry.dest, Registry.user, Registry.registry_value_name, Registry.registry_value_type | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` + as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\CurrentVersion\\Schedule\\Configuration*" + Registry.registry_value_name=EnableAt by Registry.dest, Registry.user, Registry.registry_value_name, + Registry.registry_value_type | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` | `windows_enable_win32_scheduledjob_via_registry_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: In some cases, an automated script or system may enable this setting continuously, leading to false positives. To avoid such situations, it is recommended to monitor the frequency and context of the registry modification and modify or filter the detection rules as needed. This can help to reduce the number of false positives and ensure that only genuine threats are identified. Additionally, it is important to investigate any detected instances of this modification and analyze them in the broader context of the system and network to determine if further action is necessary. +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: In some cases, an automated script or system may enable this + setting continuously, leading to false positives. To avoid such situations, it is + recommended to monitor the frequency and context of the registry modification and + modify or filter the detection rules as needed. This can help to reduce the number + of false positives and ensure that only genuine threats are identified. Additionally, + it is important to investigate any detected instances of this modification and analyze + them in the broader context of the system and network to determine if further action + is necessary. references: - https://securityonline.info/wmiexec-regout-get-outputdata-response-from-registry/ - https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob @@ -26,7 +45,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A process has modified the schedule task registry value - EnableAt - on endpoint $dest$ by user $user$. + message: A process has modified the schedule task registry value - EnableAt - on + endpoint $dest$ by user $user$. mitre_attack_id: - T1053.005 observable: @@ -44,7 +64,7 @@ tags: - Splunk Cloud required_fields: - _time - - Registry.registry_path + - Registry.registry_path - Registry.dest - Registry.user - Registry.registry_value_name @@ -54,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_event_for_service_disabled.yml b/detections/endpoint/windows_event_for_service_disabled.yml index 55b752efdc..400e0541d9 100644 --- a/detections/endpoint/windows_event_for_service_disabled.yml +++ b/detections/endpoint/windows_event_for_service_disabled.yml @@ -1,18 +1,22 @@ name: Windows Event For Service Disabled id: 9c2620a8-94a1-11ec-b40c-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic will identify suspicious system event of services that - was modified from start to disabled. This technique is seen where the adversary - attempts to disable security app services, other malware services to evade the defense - systems on the compromised host +description: The following analytic detects when a Windows service is modified from + a start type to disabled. It leverages system event logs, specifically EventCode + 7040, to identify this change. This activity is significant because adversaries + often disable security or other critical services to evade detection and maintain + control over a compromised host. If confirmed malicious, this action could allow + attackers to bypass security defenses, leading to further exploitation and persistence + within the environment. data_source: - Windows Event Log System 7040 -search: '`wineventlog_system` EventCode=7040 EventData_Xml="*disabled*" | stats count min(_time) as firstTime max(_time) as lastTime - by Computer EventCode Name UserID service ServiceName | rename Computer as dest | `security_content_ctime(firstTime)` +search: '`wineventlog_system` EventCode=7040 EventData_Xml="*disabled*" | stats count + min(_time) as firstTime max(_time) as lastTime by Computer EventCode Name UserID + service ServiceName | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_event_for_service_disabled_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type @@ -53,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/windows_excessive_disabled_services_event/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/windows_excessive_disabled_services_event/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_event_log_cleared.yml b/detections/endpoint/windows_event_log_cleared.yml index 8707301fa0..eb3a155337 100644 --- a/detections/endpoint/windows_event_log_cleared.yml +++ b/detections/endpoint/windows_event_log_cleared.yml @@ -1,16 +1,17 @@ name: Windows Event Log Cleared id: ad517544-aff9-4c96-bd99-d6eb43bfbb6a -version: 7 -date: '2024-04-26' +version: 8 +date: '2024-05-12' author: Rico Valdez, Michael Haag, Splunk status: production type: TTP -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. +description: The following analytic detects the clearing of Windows event logs by + identifying Windows Security Event ID 1102 or System log event 104. This detection + leverages Windows event logs to monitor for log clearing activities. Such behavior + is significant as it may indicate an attempt to cover tracks after malicious activities. + If confirmed malicious, this action could hinder forensic investigations and allow + attackers to persist undetected, making it crucial to investigate further and correlate + with other alerts and data sources. data_source: - Windows Event Log Security 1102 - Windows Event Log System 104 @@ -57,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/windows_event_log_cleared/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/windows_event_log_cleared/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_event_triggered_image_file_execution_options_injection.yml b/detections/endpoint/windows_event_triggered_image_file_execution_options_injection.yml index 6f01cc52be..66c6eae42d 100644 --- a/detections/endpoint/windows_event_triggered_image_file_execution_options_injection.yml +++ b/detections/endpoint/windows_event_triggered_image_file_execution_options_injection.yml @@ -1,20 +1,18 @@ name: Windows Event Triggered Image File Execution Options Injection id: f7abfab9-12ea-44e8-8745-475f9ca6e0a4 -version: 1 -date: '2022-09-08' +version: 2 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic identifies EventCode 3000 in Application - channel indicating a process exit. This behavior is based on process names being - added to the Image File Execution Options under HKLM \SOFTWARE\Microsoft\Windows - NT\CurrentVersion\Image File Execution Options\ and \SOFTWARE\Microsoft\Windows - NT\CurrentVersion\SilentProcessExit. Once these are set for a process, an eventcode - 3000 will generate. The example used is from Thinkst Canary where a CanaryToken - is setup to monitor for a commonly abused living off the land binary (ex. Klist.exe) - and generate an event when it occurs. This can be seen as settings traps to monitor - for suspicious behavior. Monitor and tune this hunting analytic and setup traps - across your organization and begin monitoring. +description: The following analytic identifies the creation or modification of Image + File Execution Options (IFEO) registry keys, detected via EventCode 3000 in the + Application channel. This detection leverages Windows Event Logs to monitor for + process names added to IFEO under specific registry paths. This activity is significant + as it can indicate attempts to set traps for process monitoring or debugging, often + used by attackers for persistence or evasion. If confirmed malicious, this could + allow an attacker to execute arbitrary code or manipulate process behavior, leading + to potential system compromise. data_source: - Windows Event Log Application 3000 search: '`wineventlog_application` EventCode=3000 | rename param1 AS "Process" param2 @@ -58,7 +56,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.012/atomic_red_team/windows-application.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.012/atomic_red_team/windows-application.log source: XmlWinEventLog:Application sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_excessive_disabled_services_event.yml b/detections/endpoint/windows_excessive_disabled_services_event.yml index d4c4bb6a54..3ec5426f6f 100644 --- a/detections/endpoint/windows_excessive_disabled_services_event.yml +++ b/detections/endpoint/windows_excessive_disabled_services_event.yml @@ -1,23 +1,24 @@ name: Windows Excessive Disabled Services Event id: c3f85976-94a5-11ec-9a58-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will identify suspicious excessive number of system events - of services that was modified from start to disabled. This technique is seen where - the adversary attempts to disable security app services, other malware services - oer serve as an destructive impact to complete the objective on the compromised - system. One good example for this scenario is Olympic destroyer where it disable - all active services in the compromised host as part of its destructive impact and - defense evasion. +description: The following analytic identifies an excessive number of system events + where services are modified from start to disabled. It leverages Windows Event Logs + (EventCode 7040) to detect multiple service state changes on a single host. This + activity is significant as it may indicate an adversary attempting to disable security + applications or other critical services, potentially leading to defense evasion + or destructive actions. If confirmed malicious, this behavior could allow attackers + to disable security defenses, disrupt system operations, and achieve their objectives + on the compromised system. data_source: - Windows Event Log System 7040 -search: '`wineventlog_system` EventCode=7040 "disabled" | stats count values(EventData_Xml) as MessageList dc(EventData_Xml) as MessageCount min(_time) as firstTime max(_time) as lastTime by Computer EventCode UserID | rename Computer as dest - | where count >=10 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`wineventlog_system` EventCode=7040 "disabled" | stats count values(EventData_Xml) + as MessageList dc(EventData_Xml) as MessageCount min(_time) as firstTime max(_time) + as lastTime by Computer EventCode UserID | rename Computer as dest | where count + >=10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_excessive_disabled_services_event_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type @@ -32,7 +33,8 @@ tags: asset_type: Endpoint confidence: 90 impact: 90 - message: An excessive number (Count - $MessageCount$) of Windows services were disabled on dest - $dest$. + message: An excessive number (Count - $MessageCount$) of Windows services were disabled + on dest - $dest$. mitre_attack_id: - T1562.001 - T1562 @@ -58,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/windows_excessive_disabled_services_event/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/windows_excessive_disabled_services_event/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_executable_in_loaded_modules.yml b/detections/endpoint/windows_executable_in_loaded_modules.yml index ad7666e3f2..d50c4786ac 100644 --- a/detections/endpoint/windows_executable_in_loaded_modules.yml +++ b/detections/endpoint/windows_executable_in_loaded_modules.yml @@ -1,29 +1,30 @@ name: Windows Executable in Loaded Modules id: 3e27af56-fcf0-4113-988d-24969b062be7 -version: 1 -date: '2023-09-12' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 7 -description: This analytic identifies potentially malicious 'ImageLoaded' events, particularly when they involve executable files. - This behavior was observed in NjRAT instances, where, during each instance of loading a module from its C2 server onto the compromised host, - Sysmon recorded the path of the actual Image or Process as an 'ImageLoaded' event, rather than the typical tracking of dynamically loaded DLL modules in memory. - This event holds significance because it tracks processes that load modules and libraries, which are typically in the .dll format rather than .exe. - Leveraging this 'Time-To-Perform' (TTP) detection method can prove invaluable for the identification of NjRAT malware or - other malicious software instances that introduce executable files as modules within a targeted host. -search: '`sysmon` EventCode=7 ImageLoaded= *.exe - | stats count min(_time) as firstTime max(_time) as lastTime by Image ImageLoaded Signed SignatureStatus OriginalFileName process_name Computer EventCode ProcessId Hashes IMPHASH - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_executable_in_loaded_modules_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. - If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. +description: The following analytic identifies instances where executable files (.exe) + are loaded as modules, detected through 'ImageLoaded' events in Sysmon logs. This + method leverages Sysmon EventCode 7 to track unusual module loading behavior, which + is significant as it deviates from the norm of loading .dll files. This activity + is crucial for SOC monitoring because it can indicate the presence of malware like + NjRAT, which uses this technique to load malicious modules. If confirmed malicious, + this behavior could allow attackers to execute arbitrary code, maintain persistence, + and further compromise the host system. +search: '`sysmon` EventCode=7 ImageLoaded= *.exe | stats count min(_time) as firstTime + max(_time) as lastTime by Image ImageLoaded Signed SignatureStatus OriginalFileName + process_name Computer EventCode ProcessId Hashes IMPHASH | rename Computer as dest + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_executable_in_loaded_modules_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + logs with the process name and imageloaded executions from your endpoints. If you + are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. known_false_positives: unknown. references: - - https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat +- https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat tags: analytic_story: - NjRAT @@ -45,21 +46,22 @@ tags: risk_score: 64 required_fields: - _time - - Image - - ImageLoaded - - Signed - - SignatureStatus - - OriginalFileName - - process_name - - Computer - - EventCode - - ProcessId - - Hashes - - IMPHASH + - Image + - ImageLoaded + - Signed + - SignatureStatus + - OriginalFileName + - process_name + - Computer + - EventCode + - ProcessId + - Hashes + - IMPHASH security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1129/executable_shared_modules/image_loaded_exe.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1129/executable_shared_modules/image_loaded_exe.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_execute_arbitrary_commands_with_msdt.yml b/detections/endpoint/windows_execute_arbitrary_commands_with_msdt.yml index 7c42d56102..698fe4bfd8 100644 --- a/detections/endpoint/windows_execute_arbitrary_commands_with_msdt.yml +++ b/detections/endpoint/windows_execute_arbitrary_commands_with_msdt.yml @@ -1,15 +1,18 @@ name: Windows Execute Arbitrary Commands with MSDT id: e1d5145f-38fe-42b9-a5d5-457796715f97 -version: 3 -date: '2022-06-29' +version: 4 +date: '2024-05-19' author: Michael Haag, Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a recently disclosed arbitraty command - execution using Windows msdt.exe - a Diagnostics Troubleshooting Wizard. The sample - identified will use the ms-msdt:/ protocol handler to load msdt.exe to retrieve - a remote payload. During triage, review file modifications for html. Identify parallel - process execution that may be related, including an Office Product. +description: The following analytic detects arbitrary command execution using Windows + msdt.exe, a Diagnostics Troubleshooting Wizard. It leverages Endpoint Detection + and Response (EDR) data to identify instances where msdt.exe is invoked via the + ms-msdt:/ protocol handler to retrieve a remote payload. This activity is significant + as it can indicate an exploitation attempt leveraging msdt.exe to execute arbitrary + commands, potentially leading to unauthorized code execution. If confirmed malicious, + this could allow an attacker to execute arbitrary code, escalate privileges, or + persist within the environment, posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -89,7 +92,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/msdt.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/msdt.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_exfiltration_over_c2_via_invoke_restmethod.yml b/detections/endpoint/windows_exfiltration_over_c2_via_invoke_restmethod.yml index a43ee186f0..bbdf5110a0 100644 --- a/detections/endpoint/windows_exfiltration_over_c2_via_invoke_restmethod.yml +++ b/detections/endpoint/windows_exfiltration_over_c2_via_invoke_restmethod.yml @@ -1,18 +1,25 @@ name: Windows Exfiltration Over C2 Via Invoke RestMethod id: 06ade821-f6fa-40d0-80af-15bc1d45b3ba -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies the potential exfiltration of data using PowerShell's Invoke-RestMethod. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Invoke-RestMethod *" AND ScriptBlockText = "* -Uri *" AND ScriptBlockText = "* -Method *" AND ScriptBlockText = "* Post *" AND ScriptBlockText = "* -InFile *" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_exfiltration_over_c2_via_invoke_restmethod_filter`' +description: The following analytic detects potential data exfiltration using PowerShell's + Invoke-RestMethod. It leverages PowerShell Script Block Logging to identify scripts + that attempt to upload files via HTTP POST requests. This activity is significant + as it may indicate an attacker is exfiltrating sensitive data, such as desktop screenshots + or files, to an external command and control (C2) server. If confirmed malicious, + this could lead to data breaches, loss of sensitive information, and further compromise + of the affected systems. Immediate investigation is recommended to determine the + intent and scope of the activity. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Invoke-RestMethod *" AND + ScriptBlockText = "* -Uri *" AND ScriptBlockText = "* -Method *" AND ScriptBlockText + = "* Post *" AND ScriptBlockText = "* -InFile *" | stats count min(_time) as firstTime + max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_exfiltration_over_c2_via_invoke_restmethod_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -26,7 +33,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A PowerShell script on $Computer$ is attempting to transfer files to a remote URL. + message: A PowerShell script on $Computer$ is attempting to transfer files to a + remote URL. mitre_attack_id: - T1041 observable: @@ -49,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_exfiltration/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_exfiltration/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_exfiltration_over_c2_via_powershell_uploadstring.yml b/detections/endpoint/windows_exfiltration_over_c2_via_powershell_uploadstring.yml index c6c320a1cb..cf10e3a8e9 100644 --- a/detections/endpoint/windows_exfiltration_over_c2_via_powershell_uploadstring.yml +++ b/detections/endpoint/windows_exfiltration_over_c2_via_powershell_uploadstring.yml @@ -1,18 +1,24 @@ name: Windows Exfiltration Over C2 Via Powershell UploadString id: 59e8bf41-7472-412a-90d3-00f3afa452e9 -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies potential data exfiltration using the PowerShell net.webclient command. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Net.webclient*" AND ScriptBlockText = "*.UploadString*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_exfiltration_over_c2_via_powershell_uploadstring_filter`' +description: The following analytic identifies potential data exfiltration using the + PowerShell `net.webclient` command with the `UploadString` method. It leverages + PowerShell Script Block Logging to detect instances where this command is executed. + This activity is significant as it may indicate an attempt to upload sensitive data, + such as desktop screenshots or files, to an external or internal URI, often associated + with malware like Winter-Vivern. If confirmed malicious, this could lead to unauthorized + data transfer, compromising sensitive information and potentially leading to further + exploitation of the compromised host. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Net.webclient*" AND ScriptBlockText + = "*.UploadString*" | stats count min(_time) as firstTime max(_time) as lastTime + by EventCode ScriptBlockText Computer UserID | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_exfiltration_over_c2_via_powershell_uploadstring_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -26,7 +32,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A PowerShell script on $Computer$ is attempting to transfer files to a remote URL. + message: A PowerShell script on $Computer$ is attempting to transfer files to a + remote URL. mitre_attack_id: - T1041 observable: @@ -49,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_uploadstring/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_uploadstring/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_export_certificate.yml b/detections/endpoint/windows_export_certificate.yml index 8236df3628..7b7b8813e6 100644 --- a/detections/endpoint/windows_export_certificate.yml +++ b/detections/endpoint/windows_export_certificate.yml @@ -1,17 +1,16 @@ name: Windows Export Certificate id: d8ddfa9b-b724-4df9-9dbe-f34cc0936714 -version: 2 -date: '2023-02-11' +version: 3 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies when a certificate is exported from - the Windows Certificate Store. This analytic utilizes the Certificates Lifecycle - log channel event ID 1007. EventID 1007 is focused on the Export of a certificate - from the local certificate store. In addition, review the ProcessName field as it - will help to determine automation/Admin or adversary extracting the certificate. - Depending on the organization, the certificate may be used for authentication to - the VPN or private resources. +description: The following analytic detects the export of a certificate from the Windows + Certificate Store. It leverages the Certificates Lifecycle log channel, specifically + event ID 1007, to identify this activity. Monitoring certificate exports is crucial + as certificates can be used for authentication to VPNs or private resources. If + malicious actors export certificates, they could potentially gain unauthorized access + to sensitive systems or data, leading to significant security breaches. data_source: - Windows Event Log CertificateServicesClient 1007 search: '`certificateservices_lifecycle` EventCode=1007 | xmlkv UserData_Xml | stats @@ -55,7 +54,9 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/certificateservices-lifecycle.log - source: XmlWinEventLog:Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/certificateservices-lifecycle.log + source: + XmlWinEventLog:Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_file_share_discovery_with_powerview.yml b/detections/endpoint/windows_file_share_discovery_with_powerview.yml index 230d672891..6300157fa4 100644 --- a/detections/endpoint/windows_file_share_discovery_with_powerview.yml +++ b/detections/endpoint/windows_file_share_discovery_with_powerview.yml @@ -1,24 +1,29 @@ name: Windows File Share Discovery With Powerview id: a44c0be1-d7ab-41e4-92fd-aa9af4fe232c -version: 1 -date: '2023-03-20' +version: 2 +date: '2024-05-18' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies the use of the Invoke-ShareFinder PowerShell commandlet part of PowerView. This module obtains the list of all - active domain computers and lists the active shares on each computer. Network file shares in Active Directory environments may contain sensitive information - like backups, scripts, credentials, etc. Adversaries who have obtained a foothold in an AD network may leverage PowerView to identify secrets and leverage them - for Privilege Escalation or Lateral Movement. -search: '`powershell` EventCode=4104 (ScriptBlockText=Invoke-ShareFinder*) - | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of the Invoke-ShareFinder + PowerShell cmdlet from PowerView. This detection leverages PowerShell Script Block + Logging to identify instances where this specific command is executed. Monitoring + this activity is crucial as it indicates an attempt to enumerate network file shares, + which may contain sensitive information such as backups, scripts, and credentials. + If confirmed malicious, this activity could enable an attacker to escalate privileges + or move laterally within the network, potentially compromising additional systems + and sensitive data. +search: '`powershell` EventCode=4104 (ScriptBlockText=Invoke-ShareFinder*) | stats + count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode + ScriptBlockText | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_file_share_discovery_with_powerview_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Security teams may leverage PowerView proactively to identify and remediate sensitive file shares. Filter as needed. +known_false_positives: Security teams may leverage PowerView proactively to identify + and remediate sensitive file shares. Filter as needed. references: - https://github.com/PowerShellEmpire/PowerTools/blob/master/PowerView/powerview.ps1 - https://thedfirreport.com/2023/01/23/sharefinder-how-threat-actors-discover-file-shares/ @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/powerview_sharefinder/windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/powerview_sharefinder/windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_file_transfer_protocol_in_non_common_process_path.yml b/detections/endpoint/windows_file_transfer_protocol_in_non_common_process_path.yml index e107be25c3..fc788f5756 100644 --- a/detections/endpoint/windows_file_transfer_protocol_in_non_common_process_path.yml +++ b/detections/endpoint/windows_file_transfer_protocol_in_non_common_process_path.yml @@ -1,23 +1,25 @@ name: Windows File Transfer Protocol In Non-Common Process Path id: 0f43758f-1fe9-470a-a9e4-780acc4d5407 -version: 1 -date: '2022-09-16' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a possible windows application having - a FTP connection in a non common installation path in windows operating system.This - network protocol is being used by adversaries, threat actors and malware like AgentTesla - as a Command And Control communication to transfer its collected stolen information - like the desktop screenshots, browser information and system information of a targeted - or compromised host. +description: The following analytic detects FTP connections initiated by processes + located in non-standard installation paths on Windows systems. It leverages Sysmon + EventCode 3 to identify network connections where the process image path does not + match common directories like "Program Files" or "Windows\System32". This activity + is significant as FTP is often used by adversaries and malware, such as AgentTesla, + for Command and Control (C2) communications to exfiltrate stolen data. If confirmed + malicious, this could lead to unauthorized data transfer, exposing sensitive information + and compromising the integrity of the affected host. data_source: - Sysmon EventID 3 search: '`sysmon` EventCode=3 NOT(Image IN("*\\program files*", "*\\windows\\system32\\*","*\\windows\\SysWOW64\\*")) (DestinationPortName="ftp" OR DestinationPort=21) | stats count min(_time) as firstTime max(_time) as lastTime by Image DestinationPort DestinationPortName DestinationHostname - DestinationIp SourcePort SourcePortName Protocol SourceHostname dest user | - `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_file_transfer_protocol_in_non_common_process_path_filter`' + DestinationIp SourcePort SourcePortName Protocol SourceHostname dest user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_file_transfer_protocol_in_non_common_process_path_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 3 connection events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -65,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_ftp/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_ftp/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_file_without_extension_in_critical_folder.yml b/detections/endpoint/windows_file_without_extension_in_critical_folder.yml index 531f194953..53286281b3 100644 --- a/detections/endpoint/windows_file_without_extension_in_critical_folder.yml +++ b/detections/endpoint/windows_file_without_extension_in_critical_folder.yml @@ -1,16 +1,17 @@ name: Windows File Without Extension In Critical Folder id: 0dbcac64-963c-11ec-bf04-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Bhavin Patel, Splunk status: production type: TTP -description: This analytic is to look for suspicious file creation in the critical - folder like "System32\Drivers" folder without file extension. This artifacts was - seen in latest hermeticwiper where it drops its driver component in Driver Directory - both the compressed(without file extension) and the actual driver component (with - .sys file extension). This TTP is really a good indication that a host might be - compromised by this destructive malware that wipes the boot sector of the system. +description: The following analytic detects the creation of files without extensions + in critical folders like "System32\Drivers." It leverages data from the Endpoint.Filesystem + datamodel, focusing on file paths and creation times. This activity is significant + as it may indicate the presence of destructive malware, such as HermeticWiper, which + drops driver components in these directories. If confirmed malicious, this behavior + could lead to severe system compromise, including boot sector wiping, resulting + in potential data loss and system inoperability. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Filesystem @@ -66,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_files_and_dirs_access_rights_modification_via_icacls.yml b/detections/endpoint/windows_files_and_dirs_access_rights_modification_via_icacls.yml index 896725f530..76c347c84d 100644 --- a/detections/endpoint/windows_files_and_dirs_access_rights_modification_via_icacls.yml +++ b/detections/endpoint/windows_files_and_dirs_access_rights_modification_via_icacls.yml @@ -1,21 +1,20 @@ name: Windows Files and Dirs Access Rights Modification Via Icacls id: c76b796c-27e1-4520-91c4-4a58695c749e -version: 1 -date: '2023-06-06' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This analytic aims to identify potential adversaries who manipulate the - security permissions of specific files or directories. This technique is frequently - observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. - By modifying the security permissions, adversaries seek to evade detection and impede - access to their component files. Such actions indicate a deliberate effort to maintain - control over compromised systems and hinder investigation or remediation efforts. - Detecting these security permission changes can serve as a valuable indicator of - an ongoing attack and enable timely response to mitigate the impact of the adversary's - activities. +description: The following analytic identifies the modification of security permissions + on files or directories using tools like icacls.exe, cacls.exe, or xcacls.exe. It + leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific + command-line executions. This activity is significant as it is commonly used by + Advanced Persistent Threats (APTs) and coinminer scripts to evade detection and + maintain control over compromised systems. If confirmed malicious, this behavior + could allow attackers to hinder investigation, impede remediation efforts, and maintain + persistent access to the compromised environment. search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name IN( "icacls.exe", "cacls.exe","xcacls.exe") AND Processes.process IN ("*:R*", "*:W*", "*:F*", "*:C*",, @@ -79,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/amadey/access_permission/amadey_sysmon2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/amadey/access_permission/amadey_sysmon2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_find_domain_organizational_units_with_getdomainou.yml b/detections/endpoint/windows_find_domain_organizational_units_with_getdomainou.yml index 42ba573c02..28a1e72c69 100644 --- a/detections/endpoint/windows_find_domain_organizational_units_with_getdomainou.yml +++ b/detections/endpoint/windows_find_domain_organizational_units_with_getdomainou.yml @@ -1,19 +1,29 @@ name: Windows Find Domain Organizational Units with GetDomainOU id: 0ada2f82-b7af-40cc-b1d7-1e5985afcb4e -version: 1 -date: '2023-08-31' +version: 2 +date: '2024-05-17' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-DomainOU` commandlet. `Get-DomainOU` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Identifying the use of `Get-DomainOU` is crucial as adversaries and Red Teams might employ it to gain insights into organizational units within Active Directory, potentially aiding in lateral movement or privilege escalation strategies. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-DomainOU*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_find_domain_organizational_units_with_getdomainou_filter`' -how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. -known_false_positives: Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. +description: The following analytic detects the execution of the `Get-DomainOU` cmdlet, + a part of the PowerView toolkit used for Windows domain enumeration. It leverages + PowerShell Script Block Logging (EventCode=4104) to identify this activity. Detecting + `Get-DomainOU` usage is significant as adversaries may use it to gather information + about organizational units within Active Directory, which can facilitate lateral + movement or privilege escalation. If confirmed malicious, this activity could allow + attackers to map the domain structure, aiding in further exploitation and persistence + within the network. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-DomainOU*" | stats count + min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer + UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_find_domain_organizational_units_with_getdomainou_filter`' +how_to_implement: The following Hunting analytic requires PowerShell operational logs + to be imported. Modify the powershell macro as needed to match the sourcetype or + add index. This analytic is specific to 4104, or PowerShell Script Block Logging. +known_false_positives: Administrators may leverage PowerSploit tools for legitimate + reasons, filter as needed. references: - https://powersploit.readthedocs.io/en/latest/Recon/Get-DomainOU/ - https://attack.mitre.org/techniques/T1087/002/ @@ -24,8 +34,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious PowerShell Get-DomainOU was identified on endpoint $dest$ - by user $user$. + message: Suspicious PowerShell Get-DomainOU was identified on endpoint $dest$ by + user $user$. mitre_attack_id: - T1087 - T1087.002 @@ -53,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-DomainOU-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-DomainOU-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_find_interesting_acl_with_findinterestingdomainacl.yml b/detections/endpoint/windows_find_interesting_acl_with_findinterestingdomainacl.yml index c1d15ac066..5cf2bf2017 100644 --- a/detections/endpoint/windows_find_interesting_acl_with_findinterestingdomainacl.yml +++ b/detections/endpoint/windows_find_interesting_acl_with_findinterestingdomainacl.yml @@ -1,19 +1,28 @@ name: Windows Find Interesting ACL with FindInterestingDomainAcl id: e4a96dfd-667a-4487-b942-ccef5a1e81e8 -version: 1 -date: '2023-08-31' +version: 2 +date: '2024-05-28' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-InterestingDomainAcl` commandlet. `Find-InterestingDomainAcl` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-InterestingDomainAcl` is crucial as adversaries and Red Teams might employ it to identify unusual or misconfigured Access Control Lists (ACLs) within the domain. Such ACLs can provide attackers with insights into potential privilege escalation opportunities or weak security postures within Active Directory. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Find-InterestingDomainAcl*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_find_interesting_acl_with_findinterestingdomainacl_filter`' -how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. -known_false_positives: Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. +description: The following analytic detects the execution of the `Find-InterestingDomainAcl` + cmdlet, part of the PowerView toolkit, using PowerShell Script Block Logging (EventCode=4104). + This detection leverages logs to identify when this command is run, which is significant + as adversaries may use it to find misconfigured or unusual Access Control Lists + (ACLs) within a domain. If confirmed malicious, this activity could allow attackers + to identify privilege escalation opportunities or weak security configurations in + Active Directory, potentially leading to unauthorized access or further exploitation. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Find-InterestingDomainAcl*" + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_find_interesting_acl_with_findinterestingdomainacl_filter`' +how_to_implement: The following Hunting analytic requires PowerShell operational logs + to be imported. Modify the powershell macro as needed to match the sourcetype or + add index. This analytic is specific to 4104, or PowerShell Script Block Logging. +known_false_positives: Administrators may leverage PowerSploit tools for legitimate + reasons, filter as needed. references: - https://powersploit.readthedocs.io/en/latest/Recon/Find-InterestingDomainAcl/ - https://attack.mitre.org/techniques/T1087/002/ @@ -24,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious PowerShell Find-InterestingDomainAcl was identified on endpoint $dest$ by user $user$. + message: Suspicious PowerShell Find-InterestingDomainAcl was identified on endpoint + $dest$ by user $user$. mitre_attack_id: - T1087 - T1087.002 @@ -52,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-interestingACL-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-interestingACL-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_findstr_gpp_discovery.yml b/detections/endpoint/windows_findstr_gpp_discovery.yml index 77d6e4f33f..92960180a5 100644 --- a/detections/endpoint/windows_findstr_gpp_discovery.yml +++ b/detections/endpoint/windows_findstr_gpp_discovery.yml @@ -1,20 +1,20 @@ name: Windows Findstr GPP Discovery id: 1631ac2d-f2a9-42fa-8a59-d6e210d472f5 -version: 1 -date: '2023-03-16' +version: 2 +date: '2024-05-29' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Sysmon EventID 1 -description: The following analytic identifies the use of the findstr command employed - to search for unsecured credentials Group Policy Preferences (GPP). GPP are tools - that allow administrators to create domain policies with embedded credentials. These - policies allow administrators to set local accounts. These group policies are stored - in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL - share and decrypt the password (using the AES key that has been made public). While - Microsoft released a patch that impedes Administrators to create unsecure credentials, - existing Group Policy Preferences files with passwords are not removed from SYSVOL. +description: The following analytic detects the use of the findstr command to search + for unsecured credentials in Group Policy Preferences (GPP). It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on command-line executions + involving findstr.exe with references to SYSVOL and cpassword. This activity is + significant because it indicates an attempt to locate and potentially decrypt embedded + credentials in GPP, which could lead to unauthorized access. If confirmed malicious, + this could allow an attacker to escalate privileges or gain access to sensitive + systems and data within the domain. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_name=findstr.exe AND Processes.process=*sysvol* AND Processes.process=*cpassword*) by Processes.dest @@ -80,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.006/findstr_gpp_discovery/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.006/findstr_gpp_discovery/windows-security.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_forest_discovery_with_getforestdomain.yml b/detections/endpoint/windows_forest_discovery_with_getforestdomain.yml index fd45cb8e53..625c6836f4 100644 --- a/detections/endpoint/windows_forest_discovery_with_getforestdomain.yml +++ b/detections/endpoint/windows_forest_discovery_with_getforestdomain.yml @@ -1,19 +1,28 @@ name: Windows Forest Discovery with GetForestDomain id: a14803b2-4bd9-4c08-8b57-c37980edebe8 -version: 1 -date: '2023-08-31' +version: 2 +date: '2024-05-16' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: This analytic utilizes PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-ForestDomain` commandlet. `Get-ForestDomain` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Get-ForestDomain` is essential as adversaries and Red Teams might employ it to gain insights into the forest and domain configurations of an Active Directory environment. Such information can provide attackers with a broader understanding of the domain structure and potential avenues for lateral movement or privilege escalation. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-ForestDomain*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_forest_discovery_with_getforestdomain_filter`' -how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. -known_false_positives: Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. +description: The following analytic detects the execution of the `Get-ForestDomain` + cmdlet, a component of the PowerView toolkit used for Windows domain enumeration. + It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. + Detecting `Get-ForestDomain` is significant because adversaries and Red Teams use + it to gather detailed information about Active Directory forest and domain configurations. + If confirmed malicious, this activity could enable attackers to understand the domain + structure, facilitating lateral movement or privilege escalation within the environment. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-ForestDomain*" | stats + count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_forest_discovery_with_getforestdomain_filter`' +how_to_implement: The following Hunting analytic requires PowerShell operational logs + to be imported. Modify the powershell macro as needed to match the sourcetype or + add index. This analytic is specific to 4104, or PowerShell Script Block Logging. +known_false_positives: Administrators may leverage PowerSploit tools for legitimate + reasons, filter as needed. references: - https://powersploit.readthedocs.io/en/latest/Recon/Get-ForestDomain/ - https://attack.mitre.org/techniques/T1087/002/ @@ -24,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious PowerShell Get-ForestDomain was identified on endpoint $dest$ by user $user$. + message: Suspicious PowerShell Get-ForestDomain was identified on endpoint $dest$ + by user $user$. mitre_attack_id: - T1087 - T1087.002 @@ -52,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-ForestDomain-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-ForestDomain-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_gather_victim_host_information_camera.yml b/detections/endpoint/windows_gather_victim_host_information_camera.yml index b213ca5955..0db4ac23ef 100644 --- a/detections/endpoint/windows_gather_victim_host_information_camera.yml +++ b/detections/endpoint/windows_gather_victim_host_information_camera.yml @@ -1,26 +1,30 @@ name: Windows Gather Victim Host Information Camera id: e4df4676-ea41-4397-b160-3ee0140dc332 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic detects a powershell script that enumerate camera - mounted to the targeted host. This technique was seen in DCRat malware, where it - runs a powershell command to look for camera information that will be pass on to - its C2 server. This anomaly detection can be a good pivot to check who and why this - enumeration is needed and what parent process execute this powershell script command. +description: The following analytic detects a PowerShell script that enumerates camera + devices on the targeted host. This detection leverages PowerShell Script Block Logging, + specifically looking for commands querying Win32_PnPEntity for camera-related information. + This activity is significant as it is commonly observed in DCRat malware, which + collects camera data to send to its command-and-control server. If confirmed malicious, + this behavior could indicate an attempt to gather sensitive visual information from + the host, potentially leading to privacy breaches or further exploitation. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText= "* Win32_PnPEntity *" ScriptBlockText= "*SELECT*" ScriptBlockText= "*WHERE*" ScriptBlockText = "*PNPClass*" ScriptBlockText IN ("*Image*", "*Camera*") | stats count min(_time) as firstTime max(_time) as lastTime - by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_gather_victim_host_information_camera_filter`' + by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename + UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_gather_victim_host_information_camera_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: Administrators may execute this powershell command to get hardware information related to camera on $dest$. +known_false_positives: Administrators may execute this powershell command to get hardware + information related to camera on $dest$. references: - https://cert.gov.ua/article/405538 - https://malpedia.caad.fkie.fraunhofer.de/details/win.dcrat @@ -58,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_enum_camera/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_enum_camera/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_gather_victim_identity_sam_info.yml b/detections/endpoint/windows_gather_victim_identity_sam_info.yml index ef7a117f63..98025e0495 100644 --- a/detections/endpoint/windows_gather_victim_identity_sam_info.yml +++ b/detections/endpoint/windows_gather_victim_identity_sam_info.yml @@ -1,15 +1,17 @@ name: Windows Gather Victim Identity SAM Info id: a18e85d7-8b98-4399-820c-d46a1ca3516f -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process that loads the samlib.dll - module. This module is being abused by adversaries, threat actors and red teamers - to access information of SAM objects or access credentials information in DC. This - hunting query can be a good indicator that a process is capable of accessing the - SAM object. +description: The following analytic detects processes loading the samlib.dll or samcli.dll + modules, which are often abused to access Security Account Manager (SAM) objects + or credentials on domain controllers. This detection leverages Sysmon EventCode + 7 to identify these DLLs being loaded outside typical system directories. Monitoring + this activity is crucial as it may indicate attempts to gather sensitive identity + information. If confirmed malicious, this behavior could allow attackers to obtain + credentials, escalate privileges, or further infiltrate the network. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 (ImageLoaded = "*\\samlib.dll" AND OriginalFileName @@ -32,8 +34,8 @@ tags: asset_type: Endpoint confidence: 30 impact: 30 - message: An instance of $dest$ that loads $ImageLoaded$ that are related to - accessing to SAM object information. + message: An instance of $dest$ that loads $ImageLoaded$ that are related to accessing + to SAM object information. mitre_attack_id: - T1589.001 - T1589 @@ -59,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/loading_samlib/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/loading_samlib/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_gather_victim_network_info_through_ip_check_web_services.yml b/detections/endpoint/windows_gather_victim_network_info_through_ip_check_web_services.yml index 329e912c37..ed1ca881f8 100644 --- a/detections/endpoint/windows_gather_victim_network_info_through_ip_check_web_services.yml +++ b/detections/endpoint/windows_gather_victim_network_info_through_ip_check_web_services.yml @@ -1,23 +1,26 @@ name: Windows Gather Victim Network Info Through Ip Check Web Services id: 70f7c952-0758-46d6-9148-d8969c4481d1 -version: 2 -date: '2024-02-15' +version: 3 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies process that attempts to connect to - a known IP web services. This technique is commonly used by trickbot and other malware - to perform reconnaissance against the infected machine and look for its IP address. +description: The following analytic detects processes attempting to connect to known + IP check web services. This behavior is identified using Sysmon EventCode 22 logs, + specifically monitoring DNS queries to services like "wtfismyip.com" and "ipinfo.io". + This activity is significant as it is commonly used by malware, such as Trickbot, + for reconnaissance to determine the infected machine's IP address. If confirmed + malicious, this could allow attackers to gather network information, aiding in further + attacks or lateral movement within the network. data_source: - Sysmon EventID 22 -search: '`sysmon` EventCode=22 QueryName IN ("*wtfismyip.com", "*checkip.*", "*ipecho.net", "*ipinfo.io", - "*api.ipify.org", "*icanhazip.com", "*ip.anysrc.com","*api.ip.sb", "ident.me", "www.myexternalip.com", - "*zen.spamhaus.org", "*cbl.abuseat.org", "*b.barracudacentral.org", "*dnsbl-1.uceprotect.net", - "*spam.dnsbl.sorbs.net", "*iplogger.org*", "*ip-api.com*", "*geoip.*") - | stats min(_time) as firstTime max(_time) as lastTime count by Image ProcessId QueryName QueryStatus QueryResults EventCode Computer - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`sysmon` EventCode=22 QueryName IN ("*wtfismyip.com", "*checkip.*", "*ipecho.net", + "*ipinfo.io", "*api.ipify.org", "*icanhazip.com", "*ip.anysrc.com","*api.ip.sb", + "ident.me", "www.myexternalip.com", "*zen.spamhaus.org", "*cbl.abuseat.org", "*b.barracudacentral.org", + "*dnsbl-1.uceprotect.net", "*spam.dnsbl.sorbs.net", "*iplogger.org*", "*ip-api.com*", + "*geoip.*") | stats min(_time) as firstTime max(_time) as lastTime count by Image + ProcessId QueryName QueryStatus QueryResults EventCode Computer | rename Computer + as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_gather_victim_network_info_through_ip_check_web_services_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from @@ -63,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_get_adcomputer_unconstrained_delegation_discovery.yml b/detections/endpoint/windows_get_adcomputer_unconstrained_delegation_discovery.yml index b4ac05d7b3..872b578c88 100644 --- a/detections/endpoint/windows_get_adcomputer_unconstrained_delegation_discovery.yml +++ b/detections/endpoint/windows_get_adcomputer_unconstrained_delegation_discovery.yml @@ -1,20 +1,24 @@ name: Windows Get-AdComputer Unconstrained Delegation Discovery id: c8640777-469f-4638-ab44-c34a3233ffac -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-13' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the Get-ADComputer commandlet used with specific parameters to discover - Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries - alike may leverage use this technique for situational awareness and Active Directory - Discovery. +description: The following analytic detects the use of the Get-ADComputer cmdlet with + parameters indicating a search for Windows endpoints with Kerberos Unconstrained + Delegation. It leverages PowerShell Script Block Logging (EventCode=4104) to identify + this specific activity. This behavior is significant as it may indicate an attempt + by adversaries or Red Teams to gain situational awareness and perform Active Directory + discovery. If confirmed malicious, this activity could allow attackers to identify + high-value targets for further exploitation, potentially leading to privilege escalation + or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 -search: ' `powershell` EventCode=4104 (ScriptBlockText = "*Get-ADComputer*" AND ScriptBlockText = - "*TrustedForDelegation*") | stats count min(_time) as firstTime max(_time) as lastTime - by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` +search: ' `powershell` EventCode=4104 (ScriptBlockText = "*Get-ADComputer*" AND ScriptBlockText + = "*TrustedForDelegation*") | stats count min(_time) as firstTime max(_time) as + lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest + | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_get_adcomputer_unconstrained_delegation_discovery_filter`' how_to_implement: The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add @@ -54,12 +58,13 @@ tags: - EventCode - ScriptBlockText - Computer - - User + - UserID risk_score: 35 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_get_adcomputer_unconstrained_delegation_discovery/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_get_adcomputer_unconstrained_delegation_discovery/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_get_local_admin_with_findlocaladminaccess.yml b/detections/endpoint/windows_get_local_admin_with_findlocaladminaccess.yml index 0ef82b749c..d77f2be686 100644 --- a/detections/endpoint/windows_get_local_admin_with_findlocaladminaccess.yml +++ b/detections/endpoint/windows_get_local_admin_with_findlocaladminaccess.yml @@ -1,22 +1,29 @@ name: Windows Get Local Admin with FindLocalAdminAccess id: d2988160-3ce9-4310-b59d-905334920cdd -version: 1 -date: '2023-08-31' +version: 2 +date: '2024-05-22' author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-LocalAdminAccess` commandlet. `Find-LocalAdminAccess` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-LocalAdminAccess` is vital as adversaries and Red Teams might employ it to identify machines where the current user context has local administrator access. Such information can provide attackers with potential targets for lateral movement or privilege escalation within the network. -search: '`powershell` EventCode=4104 ScriptBlockText = "*Find-LocalAdminAccess*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_get_local_admin_with_findlocaladminaccess_filter`' +description: The following analytic detects the execution of the `Find-LocalAdminAccess` + cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is part + of PowerView, a toolkit for Windows domain enumeration. Identifying the use of `Find-LocalAdminAccess` + is crucial as adversaries may use it to find machines where the current user has + local administrator access, facilitating lateral movement or privilege escalation. + If confirmed malicious, this activity could allow attackers to target and compromise + additional systems within the network, significantly increasing their control and + access to sensitive information. +search: '`powershell` EventCode=4104 ScriptBlockText = "*Find-LocalAdminAccess*" | + stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_get_local_admin_with_findlocaladminaccess_filter`' how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. -known_false_positives: Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. +known_false_positives: Administrators may leverage PowerSploit tools for legitimate + reasons, filter as needed. references: - https://powersploit.readthedocs.io/en/latest/Recon/Find-LocalAdminAccess/ - https://attack.mitre.org/techniques/T1087/002/ @@ -27,8 +34,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Suspicious PowerShell Find-LocalAdminAccess was identified on endpoint $dest$ - by user $user$. + message: Suspicious PowerShell Find-LocalAdminAccess was identified on endpoint + $dest$ by user $user$. mitre_attack_id: - T1087 - T1087.002 @@ -56,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-LocalAdminAccess-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/AD_discovery/windows-powershell-LocalAdminAccess-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_group_policy_object_created.yml b/detections/endpoint/windows_group_policy_object_created.yml index c2f1c30233..16771eae70 100644 --- a/detections/endpoint/windows_group_policy_object_created.yml +++ b/detections/endpoint/windows_group_policy_object_created.yml @@ -1,21 +1,20 @@ name: Windows Group Policy Object Created id: 23add2a8-ea22-4fd4-8bc0-8c0b822373a1 -version: 1 -date: '2023-03-27' +version: 2 +date: '2024-05-17' author: Mauricio Velazco status: production type: TTP data_source: - Windows Event Log Security 5136 - Windows Event Log Security 5137 -description: The following analytic leverages Event IDs 5136 and 51137 to identify - the creation of a new Group Policy Object. With GPOs, system administrators can - manage and configure applications, software operations, and user settings throughout - an entire organization. GPOs can be abused and leveraged by adversaries to escalate - privileges or deploy malware across an Active Directory network. As an example, - the Lockbit ransomware malware will create new group policies on the domain controller - that are then pushed out to every device on the network. Security teams should monitor - the creation of new Group Policy Objects. +description: The following analytic detects the creation of a new Group Policy Object + (GPO) by leveraging Event IDs 5136 and 5137. This detection uses directory service + change events to identify when a new GPO is created. Monitoring GPO creation is + crucial as adversaries can exploit GPOs to escalate privileges or deploy malware + across an Active Directory network. If confirmed malicious, this activity could + allow attackers to control system configurations, deploy ransomware, or propagate + malware, leading to widespread compromise and significant operational disruption. search: ' `wineventlog_security` EventCode=5137 OR (EventCode=5136 AttributeValue!="New Group Policy Object" AND (AttributeLDAPDisplayName=displayName OR AttributeLDAPDisplayName=gPCFileSysPath) ) ObjectClass=groupPolicyContainer | stats values(AttributeValue) as details values(SubjectUserSid) @@ -71,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/group_policy_created/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.001/group_policy_created/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_hidden_schedule_task_settings.yml b/detections/endpoint/windows_hidden_schedule_task_settings.yml index 073d1c0d32..ba483a22a0 100644 --- a/detections/endpoint/windows_hidden_schedule_task_settings.yml +++ b/detections/endpoint/windows_hidden_schedule_task_settings.yml @@ -1,11 +1,18 @@ name: Windows Hidden Schedule Task Settings id: 0b730470-5fe8-4b13-93a7-fe0ad014d0cc -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects creation of hidden scheculed tasks such that it this task is not visible on the UI. Such behavior is indicative of certain malware, such as Industroyer2, or attacks leveraging living-off-the-land binaries (LOLBINs) to download additional payloads to a compromised machine. This analytic relies on the Windows Security EventCode 4698, indicating the creation of a scheduled task. The search focuses on identifying instances where the 'Hidden' setting is enabled, signaling potential nefarious activity. To implement this search, you need to ingest logs with task scheduling details from your endpoints. As false positives are currently unknown, it is advised to tune and filter based on the known use of task scheduling in your environment. This analytic provides crucial visibility into stealthy, potentially harmful scheduled tasks on Windows systems. +description: The following analytic detects the creation of hidden scheduled tasks + on Windows systems, which are not visible in the UI. It leverages Windows Security + EventCode 4698 to identify tasks where the 'Hidden' setting is enabled. This behavior + is significant as it may indicate malware activity, such as Industroyer2, or the + use of living-off-the-land binaries (LOLBINs) to download additional payloads. If + confirmed malicious, this activity could allow attackers to execute code stealthily, + maintain persistence, or further compromise the system by downloading additional + malicious payloads. data_source: - Windows Event Log Security 4698 search: '`wineventlog_security` EventCode=4698 | xmlkv Message | search Hidden = true @@ -55,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053/hidden_schedule_task/security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053/hidden_schedule_task/security.log source: WinEventLog:Security sourcetype: WinEventLog diff --git a/detections/endpoint/windows_hide_notification_features_through_registry.yml b/detections/endpoint/windows_hide_notification_features_through_registry.yml index cba318106a..27f2dd8bb8 100644 --- a/detections/endpoint/windows_hide_notification_features_through_registry.yml +++ b/detections/endpoint/windows_hide_notification_features_through_registry.yml @@ -1,16 +1,17 @@ name: Windows Hide Notification Features Through Registry id: cafa4bce-9f06-11ec-a7b2-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-26' author: Steven Dick, Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious registry modification to hide - common windows notification feature from compromised host. This technique was seen - in some ransomware family to add more impact to its payload that are visually seen - by user aside from the encrypted files and ransomware notes. Even this a good anomaly - detection, administrator may implement this changes for auditing or security reason. - In this scenario filter is needed. +description: The following analytic detects suspicious registry modifications aimed + at hiding common Windows notification features on a compromised host. It leverages + data from the Endpoint.Registry data model, focusing on specific registry paths + and values. This activity is significant as it is often used by ransomware to obscure + visual indicators, increasing the impact of the attack. If confirmed malicious, + this could prevent users from noticing critical system alerts, thereby aiding the + attacker in maintaining persistence and furthering their malicious activities undetected. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -18,9 +19,10 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\*" Registry.registry_value_name IN ("HideClock", "HideSCAHealth", "HideSCANetwork", "HideSCAPower", "HideSCAVolume") Registry.registry_value_data = "0x00000001") BY - _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_hide_notification_features_through_registry_filter`' + _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_hide_notification_features_through_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -61,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/ransomware_disable_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_high_file_deletion_frequency.yml b/detections/endpoint/windows_high_file_deletion_frequency.yml index c9a123204f..8e3e59f1e3 100644 --- a/detections/endpoint/windows_high_file_deletion_frequency.yml +++ b/detections/endpoint/windows_high_file_deletion_frequency.yml @@ -1,26 +1,35 @@ name: Windows High File Deletion Frequency id: 45b125c4-866f-11eb-a95a-acde48001122 -version: 2 -date: '2024-03-05' +version: 3 +date: '2024-05-18' author: Teoderick Contreras, Splunk, Steven Dick status: production type: Anomaly -description: This search identifies a high frequency of file deletions relative to the process - name and process ID. Such events typically occur when ransomware attempts to encrypt - files with specific extensions, leading Sysmon to treat the original files - as deleted as soon as they are replaced with encrypted data. +description: The following analytic identifies a high frequency of file deletions + by monitoring Sysmon EventCodes 23 and 26 for specific file extensions. This detection + leverages Sysmon logs to track deleted target filenames, process names, and process + IDs. Such activity is significant as it often indicates ransomware behavior, where + files are encrypted and the originals are deleted. If confirmed malicious, this + activity could lead to extensive data loss and operational disruption, as ransomware + can render critical files inaccessible, demanding a ransom for their recovery. data_source: - Sysmon EventID 23 - Sysmon EventID 26 -search: '`sysmon` EventCode IN ("23","26") TargetFilename IN ("*.cmd", "*.ini","*.gif", "*.jpg", "*.jpeg", "*.db", "*.ps1", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", "*.pptx", "*.bmp","*.zip", "*.rar", "*.7z", "*.chm", "*.png", "*.log", "*.vbs", "*.js", "*.vhd", "*.bak", "*.wbcat", "*.bkf" , "*.backup*", "*.dsk", "*.win") NOT TargetFilename IN ("*\\INetCache\\Content.Outlook\\*") - | stats count, values(TargetFilename) as deleted_files, min(_time) as firstTime, max(_time) as lastTime by user, dest, signature, signature_id, Image, process_name, process_guid - | rename Image as process - | where count >=100 - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +search: '`sysmon` EventCode IN ("23","26") TargetFilename IN ("*.cmd", "*.ini","*.gif", + "*.jpg", "*.jpeg", "*.db", "*.ps1", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", + "*.pptx", "*.bmp","*.zip", "*.rar", "*.7z", "*.chm", "*.png", "*.log", "*.vbs", + "*.js", "*.vhd", "*.bak", "*.wbcat", "*.bkf" , "*.backup*", "*.dsk", "*.win") NOT + TargetFilename IN ("*\\INetCache\\Content.Outlook\\*") | stats count, values(TargetFilename) + as deleted_files, min(_time) as firstTime, max(_time) as lastTime by user, dest, + signature, signature_id, Image, process_name, process_guid | rename Image as process + | where count >=100 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_high_file_deletion_frequency_filter`' -how_to_implement: To successfully implement this search, you need to ingest logs that include the deleted target file name, process name, and process ID from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. -known_false_positives: Users may delete a large number of pictures or files in a folder, which could trigger this detection. Additionally, heavy usage of PowerBI and Outlook may also result in false positives. +how_to_implement: To successfully implement this search, you need to ingest logs that + include the deleted target file name, process name, and process ID from your endpoints. + If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. +known_false_positives: Users may delete a large number of pictures or files in a folder, + which could trigger this detection. Additionally, heavy usage of PowerBI and Outlook + may also result in false positives. references: - https://www.mandiant.com/resources/fin11-email-campaigns-precursor-for-ransomware-data-theft - https://blog.virustotal.com/2020/11/keep-your-friends-close-keep-ransomware.html @@ -36,7 +45,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 90 - message: Elevated file deletion rate observed from process [$process_name$] on machine $dest$ + message: Elevated file deletion rate observed from process [$process_name$] on machine + $dest$ mitre_attack_id: - T1485 observable: @@ -55,7 +65,7 @@ tags: - name: process_name type: Process role: - - Attacker + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security @@ -73,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/clop/clop_a/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_hijack_execution_flow_version_dll_side_load.yml b/detections/endpoint/windows_hijack_execution_flow_version_dll_side_load.yml index db76da9959..c65837e084 100644 --- a/detections/endpoint/windows_hijack_execution_flow_version_dll_side_load.yml +++ b/detections/endpoint/windows_hijack_execution_flow_version_dll_side_load.yml @@ -1,17 +1,18 @@ name: Windows Hijack Execution Flow Version Dll Side Load id: 8351340b-ac0e-41ec-8b07-dd01bf32d6ea -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a process loading version.dll that is not - in %windir%\\system32 or %windir%\\syswow64 dir path. This event is seen in ransomware - and APT malware that executes malicious version.dll placed in the same folder of - onedrive application that will execute that module. This technique is known to be - DLL side loading. This technique was used to execute an agent of Brute Ratel C4 - red teaming tools to serve as remote admin tool to collect and compromise target - host. +description: The following analytic detects a process loading a version.dll file from + a directory other than %windir%\system32 or %windir%\syswow64. This detection leverages + Sysmon EventCode 7 to identify instances where an unsigned or improperly located + version.dll is loaded. This activity is significant as it is a common technique + used in ransomware and APT malware campaigns, including Brute Ratel C4, to execute + malicious code via DLL side loading. If confirmed malicious, this could allow attackers + to execute arbitrary code, maintain persistence, and potentially compromise the + target host. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 ImageLoaded = "*\\version.dll" AND (Signed = "false" @@ -58,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_hunting_system_account_targeting_lsass.yml b/detections/endpoint/windows_hunting_system_account_targeting_lsass.yml index 94614cdbec..13c7c899e9 100644 --- a/detections/endpoint/windows_hunting_system_account_targeting_lsass.yml +++ b/detections/endpoint/windows_hunting_system_account_targeting_lsass.yml @@ -1,15 +1,17 @@ name: Windows Hunting System Account Targeting Lsass id: 1c6abb08-73d1-11ec-9ca0-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic identifies all processes requesting access - into Lsass.exe. his behavior may be related to credential dumping or applications - requiring access to credentials. Triaging this event will require understanding - the GrantedAccess from the SourceImage. In addition, whether the account is privileged - or not. Review the process requesting permissions and review parallel processes. +description: The following analytic identifies processes attempting to access Lsass.exe, + which may indicate credential dumping or applications needing credential access. + It leverages Sysmon EventCode 10 to detect such activities by analyzing fields like + TargetImage, GrantedAccess, and SourceImage. This behavior is significant as unauthorized + access to Lsass.exe can lead to credential theft, posing a severe security risk. + If confirmed malicious, attackers could gain access to sensitive credentials, potentially + leading to privilege escalation and further compromise of the environment. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe | stats count min(_time) as @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_identify_protocol_handlers.yml b/detections/endpoint/windows_identify_protocol_handlers.yml index 2e3ce8bb68..00d46a92f7 100644 --- a/detections/endpoint/windows_identify_protocol_handlers.yml +++ b/detections/endpoint/windows_identify_protocol_handlers.yml @@ -1,25 +1,26 @@ name: Windows Identify Protocol Handlers id: bd5c311e-a6ea-48ae-a289-19a3398e3648 -version: 2 -date: '2022-09-13' +version: 3 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following hunting analytic will identify any protocol handlers utilized - on the command-line. A protocol handler is an application that knows how to handle - particular types of links: for example, a mail client is a protocol handler for - "mailto:" links. When the user clicks a "mailto:" link, the browser opens the application - selected as the handler for the "mailto:" protocol (or offers them a choice of handlers, - depending on their settings). To identify protocol handlers we can use NirSoft https://www.nirsoft.net/utils/url_protocol_view.html - URLProtocolView or query the registry using PowerShell.' +description: 'The following analytic identifies the use of protocol handlers executed + via the command line. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process and command-line telemetry. This activity is significant + because protocol handlers can be exploited to execute arbitrary commands or launch + applications, potentially leading to unauthorized actions. If confirmed malicious, + an attacker could use this technique to gain code execution, escalate privileges, + or maintain persistence within the environment, posing a significant security risk.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Processes.process) as process values(Processes.parent_process) - as parent_process from datamodel=Endpoint.Processes by Processes.dest Processes.parent_process_name Processes.user - Processes.process_name Processes.process | `security_content_ctime(firstTime)` | - `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | lookup windows_protocol_handlers - handler AS process OUTPUT handler ishandler | where ishandler="TRUE" | `windows_identify_protocol_handlers_filter`' + as parent_process from datamodel=Endpoint.Processes by Processes.dest Processes.parent_process_name + Processes.user Processes.process_name Processes.process | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | lookup + windows_protocol_handlers handler AS process OUTPUT handler ishandler | where ishandler="TRUE" + | `windows_identify_protocol_handlers_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -90,7 +91,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/protocol_handlers/protocolhandlers.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/protocol_handlers/protocolhandlers.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_iis_components_add_new_module.yml b/detections/endpoint/windows_iis_components_add_new_module.yml index 6a160a2077..48273b9ffe 100644 --- a/detections/endpoint/windows_iis_components_add_new_module.yml +++ b/detections/endpoint/windows_iis_components_add_new_module.yml @@ -1,16 +1,18 @@ name: Windows IIS Components Add New Module id: 38fe731c-1f13-43d4-b878-a5bbe44807e3 -version: 1 -date: '2022-12-19' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the process AppCmd.exe installing a - new module into IIS. AppCmd is a utility to manage IIS web sites and App Pools. - An adversary may run this command to install a webshell or backdoor. This has been - found to be used for credit card scraping, persistence, and further post-exploitation. - An administrator may run this to install new modules for a web site or during IIS - updates. +description: The following analytic detects the execution of AppCmd.exe to install + a new module in IIS. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant as adversaries may use it to install webshells or backdoors, leading + to credit card scraping, persistence, and further post-exploitation. If confirmed + malicious, this could allow attackers to maintain persistent access, execute arbitrary + code, and potentially exfiltrate sensitive information from the compromised web + server. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -88,7 +90,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/appcmd_install-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/appcmd_install-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_iis_components_module_failed_to_load.yml b/detections/endpoint/windows_iis_components_module_failed_to_load.yml index c83ffff4a7..bf64fbbb77 100644 --- a/detections/endpoint/windows_iis_components_module_failed_to_load.yml +++ b/detections/endpoint/windows_iis_components_module_failed_to_load.yml @@ -1,15 +1,18 @@ name: Windows IIS Components Module Failed to Load id: 40c2ba5b-dd6a-496b-9e6e-c9524d0be167 -version: 1 -date: '2022-12-20' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic utilizes EventCode 2282 which generates when a - Module DLL could not be loaded due to a configuration problem. This typically occurs - when a IIS module is installed but is failing to load. This typically results in - thousands of events until the issue is resolved. Review the module that is failing - and determine if it is legitimate or not. +description: The following analytic detects when an IIS Module DLL fails to load due + to a configuration problem, identified by EventCode 2282. This detection leverages + Windows Application event logs to identify repeated failures in loading IIS modules. + Such failures can indicate misconfigurations or potential tampering with IIS components. + If confirmed malicious, this activity could lead to service disruptions or provide + an attacker with opportunities to exploit vulnerabilities within the IIS environment. + Immediate investigation is required to determine the legitimacy of the failing module + and to mitigate any potential security risks. data_source: - Windows Event Log Application 2282 search: '`wineventlog_application` EventCode=2282 | stats count min(_time) as firstTime @@ -57,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/2282_windows-application.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/2282_windows-application.log source: XmlWinEventLog:Application sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_iis_components_new_module_added.yml b/detections/endpoint/windows_iis_components_new_module_added.yml index c5a1fdaa7d..753d10b9bf 100644 --- a/detections/endpoint/windows_iis_components_new_module_added.yml +++ b/detections/endpoint/windows_iis_components_new_module_added.yml @@ -1,19 +1,17 @@ name: Windows IIS Components New Module Added id: 55f22929-cfd3-4388-ba5c-4d01fac7ee7e -version: 1 -date: '2022-12-19' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic uses the Windows Event log - Microsoft-IIS-Configuration/Operational - - which must be enabled and logged on Windows IIS servers before it can be Splunked. - The following analytic identifies newly installed IIS modules. Per Microsoft, IIS - modules are not commonly added to a production IIS server, so alerting on this event - ID should be enabled.IIS modules can be installed at a global level or at a site - level. In detecting malicious IIS modules, it is important to check both the global - and site level for unauthorized modules. Regular monitoring of these locations for - such modules and comparing against a known good list can help detect and identify - malicious IIS modules. +description: The following analytic detects the addition of new IIS modules on a Windows + IIS server. It leverages the Windows Event log - Microsoft-IIS-Configuration/Operational, + specifically EventCode 29, to identify this activity. This behavior is significant + because IIS modules are rarely added to production servers, and unauthorized modules + could indicate malicious activity. If confirmed malicious, an attacker could use + these modules to execute arbitrary code, escalate privileges, or maintain persistence + within the environment, potentially compromising the server and sensitive data. data_source: - Windows IIS 29 search: '`iis_operational_logs` EventCode=29 | stats count min(_time) as firstTime @@ -62,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/IIS-Configuration-Operational.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/IIS-Configuration-Operational.log source: IIS:Configuration:Operational sourcetype: IIS:Configuration:Operational update_timestamp: true diff --git a/detections/endpoint/windows_impair_defense_add_xml_applocker_rules.yml b/detections/endpoint/windows_impair_defense_add_xml_applocker_rules.yml index c07f96bc62..210a52c970 100644 --- a/detections/endpoint/windows_impair_defense_add_xml_applocker_rules.yml +++ b/detections/endpoint/windows_impair_defense_add_xml_applocker_rules.yml @@ -1,14 +1,17 @@ name: Windows Impair Defense Add Xml Applocker Rules id: 467ed9d9-8035-470e-ad5e-ae5189283033 -version: 1 -date: '2022-06-24' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic is to identify a process that imports applocker - xml policy using PowerShell commandlet. This technique was seen in Azorult malware - where it drop an xml Applocker policy that will deny several AV products and further - executed the PowerShell Applocker commandlet. +description: The following analytic detects the use of a PowerShell commandlet to + import an AppLocker XML policy. This behavior is identified by monitoring processes + that execute the "Import-Module Applocker" and "Set-AppLockerPolicy" commands with + the "-XMLPolicy" parameter. This activity is significant because it can indicate + an attempt to disable or bypass security controls, as seen in the Azorult malware. + If confirmed malicious, this could allow an attacker to disable antivirus products, + leading to further compromise and persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -64,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_impair_defense_change_win_defender_health_check_intervals.yml b/detections/endpoint/windows_impair_defense_change_win_defender_health_check_intervals.yml index e344f42a85..40bb659bcf 100644 --- a/detections/endpoint/windows_impair_defense_change_win_defender_health_check_intervals.yml +++ b/detections/endpoint/windows_impair_defense_change_win_defender_health_check_intervals.yml @@ -1,28 +1,27 @@ name: Windows Impair Defense Change Win Defender Health Check Intervals id: 5211c260-820e-4366-b983-84bbfb5c263a -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to change the health check interval of Windows Defender. - Specifically, a value of 1 typically signifies that Windows Defender would perform health checks at a much higher frequency than the default settings. - However, it's important to note that modifying this value to 1 might not necessarily conform to the actual behavior, as certain registry settings may - have specific accepted values or a defined range that differs from a simple binary representation. - Changing registry values, especially those related to system services, should be approached cautiously. - Incorrect modifications can potentially impact system stability or performance. Always ensure you understand the implications and - have a backup before altering registry settings. +description: The following analytic detects modifications to the Windows registry + that change the health check interval of Windows Defender. It leverages data from + the Endpoint datamodel, specifically monitoring changes to the "ServiceKeepAlive" + registry path with a value of "0x00000001". This activity is significant because + altering Windows Defender settings can impair its ability to perform timely health + checks, potentially leaving the system vulnerable. If confirmed malicious, this + could allow an attacker to disable or delay security scans, increasing the risk + of undetected malware or other malicious activities. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\ServiceKeepAlive" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_change_win_defender_health_check_intervals_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\ServiceKeepAlive" Registry.registry_value_data="0x00000001" by Registry.registry_key_name + Registry.user Registry.registry_path Registry.registry_value_data Registry.action + Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_change_win_defender_health_check_intervals_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -66,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_change_win_defender_quick_scan_interval.yml b/detections/endpoint/windows_impair_defense_change_win_defender_quick_scan_interval.yml index d3cf063d45..5f43c86c9f 100644 --- a/detections/endpoint/windows_impair_defense_change_win_defender_quick_scan_interval.yml +++ b/detections/endpoint/windows_impair_defense_change_win_defender_quick_scan_interval.yml @@ -1,26 +1,26 @@ name: Windows Impair Defense Change Win Defender Quick Scan Interval id: 783f0798-f679-4c17-b3b3-187febf0b9b8 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to change Windows Defender - Quick Scan Interval. The "QuickScanInterval" in Windows Defender, specifically within the context of antivirus software, - typically refers to the interval or frequency at which the system conducts quick scans for malware or potential threats. - This setting dictates how often Windows Defender performs quick scans on the system. Quick scans are less comprehensive - than full system scans but provide a faster way to check critical areas for potential threats or malware. - This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications to the Windows registry + that change the Windows Defender Quick Scan Interval. It leverages data from the + Endpoint.Registry data model, focusing on changes to the "QuickScanInterval" registry + path. This activity is significant because altering the scan interval can impair + Windows Defender's ability to detect malware promptly, potentially allowing threats + to persist undetected. If confirmed malicious, this modification could enable attackers + to bypass security measures, maintain persistence, and execute further malicious + activities without being detected by quick scans. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Scan\\QuickScanInterval" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_change_win_defender_quick_scan_interval_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Scan\\QuickScanInterval" by Registry.registry_key_name Registry.user Registry.registry_path + Registry.registry_value_data Registry.action Registry.dest | `drop_dm_object_name(Registry)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_change_win_defender_quick_scan_interval_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -64,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_change_win_defender_throttle_rate.yml b/detections/endpoint/windows_impair_defense_change_win_defender_throttle_rate.yml index b35f125047..7112af78f7 100644 --- a/detections/endpoint/windows_impair_defense_change_win_defender_throttle_rate.yml +++ b/detections/endpoint/windows_impair_defense_change_win_defender_throttle_rate.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Change Win Defender Throttle Rate id: f7da5fca-9261-43de-a4d0-130dad1e4f4d -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to change the ThrottleDetectionEventsRate of Windows Defender. - The ThrottleDetectionEventsRate registry setting in Windows Defender is related to controlling the rate at which detection events are logged or - reported by Windows Defender Antivirus. - This registry setting determines how frequently Windows Defender logs or reports detection events. Adjusting the ThrottleDetectionEventsRate value - can impact the logging frequency of detection events such as malware detections, scanning results, or security-related events recorded by Windows Defender. - A higher value might mean that detection events are reported less frequently, potentially reducing the volume of recorded events, while a lower value could - increase the reporting frequency, resulting in more frequent logs of detection events. +description: The following analytic detects modifications to the ThrottleDetectionEventsRate + registry setting in Windows Defender. It leverages data from the Endpoint.Registry + datamodel to identify changes in the registry path related to Windows Defender's + event logging rate. This activity is significant because altering the ThrottleDetectionEventsRate + can reduce the frequency of logged detection events, potentially masking malicious + activities. If confirmed malicious, this could allow an attacker to evade detection + by decreasing the visibility of security events, thereby hindering incident response + and forensic investigations. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\NIS\\Consumers\\IPS\\ThrottleDetectionEventsRate" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_change_win_defender_throttle_rate_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\NIS\\Consumers\\IPS\\ThrottleDetectionEventsRate" by Registry.registry_key_name + Registry.user Registry.registry_path Registry.registry_value_data Registry.action + Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_change_win_defender_throttle_rate_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_change_win_defender_tracing_level.yml b/detections/endpoint/windows_impair_defense_change_win_defender_tracing_level.yml index ed5c7a5b7c..1e2532cf69 100644 --- a/detections/endpoint/windows_impair_defense_change_win_defender_tracing_level.yml +++ b/detections/endpoint/windows_impair_defense_change_win_defender_tracing_level.yml @@ -1,30 +1,27 @@ name: Windows Impair Defense Change Win Defender Tracing Level id: fe9391cd-952a-4c64-8f56-727cb0d4f2d4 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to change the Windows Defender Wpp Tracing levels. - The "WppTracingLevel" registry setting is typically related to Windows software tracing and diagnostics, specifically involving - Windows Software Trace Preprocessor (WPP) tracing. - WPP tracing is a mechanism used by developers to instrument code for diagnostic purposes, allowing for the collection of detailed logs - and traces during software execution. It helps in understanding the behavior of the software, identifying issues, and analyzing its performance. - Without specific documentation or references to "WppTracingLevel" within Windows Defender settings or its functionalities, it's challenging - to provide precise details about its intended use or configuration within Windows Defender. - Modifying registry settings without understanding their implications can affect system behavior or security. Always proceed cautiously - and ensure changes align with best practices and organizational requirements. +description: The following analytic detects modifications to the Windows registry + specifically targeting the "WppTracingLevel" setting within Windows Defender. This + detection leverages data from the Endpoint.Registry data model to identify changes + in the registry path associated with Windows Defender tracing levels. Such modifications + are significant as they can impair the diagnostic capabilities of Windows Defender, + potentially hiding malicious activities. If confirmed malicious, this activity could + allow an attacker to evade detection and maintain persistence within the environment, + leading to further compromise and data exfiltration. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Reporting\\WppTracingLevel" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_change_win_defender_tracing_level_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Reporting\\WppTracingLevel" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_change_win_defender_tracing_level_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -68,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_configure_app_install_control.yml b/detections/endpoint/windows_impair_defense_configure_app_install_control.yml index 22ebdbaf9d..d9c06e6d65 100644 --- a/detections/endpoint/windows_impair_defense_configure_app_install_control.yml +++ b/detections/endpoint/windows_impair_defense_configure_app_install_control.yml @@ -1,28 +1,29 @@ name: Windows Impair Defense Configure App Install Control id: c54b7439-cfb1-44c3-bb35-b0409553077c -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to change or disable Windows Defender - smartscreen app install control. Microsoft Edge's App Install Control feature helps manage the installation of web-based applications. - When attackers modify "ConfigureAppInstallControlEnabled" to 0, they are likely attempting to disable the App Install Control feature - in Microsoft Edge. This change might allow users to bypass restrictions imposed by the browser on the installation of web-based applications. - Disabling this feature might increase the risk of users being able to install potentially malicious or untrusted web applications without - restrictions or controls imposed by the browser. This action could potentially lead to security vulnerabilities or compromise if users - inadvertently install harmful applications. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender SmartScreen App Install Control feature. It leverages + data from the Endpoint.Registry data model to identify changes to specific registry + values. This activity is significant because disabling App Install Control can allow + users to install potentially malicious web-based applications without restrictions, + increasing the risk of security vulnerabilities. If confirmed malicious, this action + could lead to the installation of harmful applications, potentially compromising + the system and exposing sensitive information. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE (Registry.registry_path= "*\\Microsoft\\Windows Defender\\SmartScreen\\ConfigureAppInstallControl" Registry.registry_value_data= "Anywhere") OR - (Registry.registry_path= "*\\Microsoft\\Windows Defender\\SmartScreen\\ConfigureAppInstallControlEnabled" Registry.registry_value_data= "0x00000000") - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_configure_app_install_control_filter`' + WHERE (Registry.registry_path= "*\\Microsoft\\Windows Defender\\SmartScreen\\ConfigureAppInstallControl" + Registry.registry_value_data= "Anywhere") OR (Registry.registry_path= "*\\Microsoft\\Windows + Defender\\SmartScreen\\ConfigureAppInstallControlEnabled" Registry.registry_value_data= + "0x00000000") BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_configure_app_install_control_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -40,7 +41,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: Define Windows Defender App Install Control registry set to disable on $dest$. + message: Define Windows Defender App Install Control registry set to disable on + $dest$. mitre_attack_id: - T1562.001 - T1562 @@ -66,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_define_win_defender_threat_action.yml b/detections/endpoint/windows_impair_defense_define_win_defender_threat_action.yml index 13dc8facef..209ba10f7d 100644 --- a/detections/endpoint/windows_impair_defense_define_win_defender_threat_action.yml +++ b/detections/endpoint/windows_impair_defense_define_win_defender_threat_action.yml @@ -1,28 +1,27 @@ name: Windows Impair Defense Define Win Defender Threat Action id: 7215831c-8252-4ae3-8d43-db588e82f952 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to define the threat action of Windows Defender. - The ThreatSeverityDefaultAction registry setting in Windows Defender is used to define the default action taken by Windows Defender - when it encounters threats of specific severity levels. - A setting like ThreatSeverityDefaultAction is designed to define how Windows Defender responds to threats based on their severity. - For example, it might determine whether Windows Defender quarantines, removes, or takes other actions against threats based on their severity levels. - In this context, a registry value of 1 typically indicates an action to "clean," aiming to disinfect or resolve the detected threat, - while a registry value of 9 signifies "no action," meaning that the antivirus software refrains from taking immediate steps against the identified threat. +description: The following analytic detects modifications to the Windows Defender + ThreatSeverityDefaultAction registry setting. It leverages data from the Endpoint.Registry + datamodel to identify changes in registry values that define how Windows Defender + responds to threats. This activity is significant because altering these settings + can impair the system's defense mechanisms, potentially allowing threats to go unaddressed. + If confirmed malicious, this could enable attackers to bypass antivirus protections, + leading to persistent threats and increased risk of data compromise or further system + exploitation. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Threats\\ThreatSeverityDefaultAction*" - Registry.registry_value_data IN ("0x00000001", "9") - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_define_win_defender_threat_action_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Threats\\ThreatSeverityDefaultAction*" Registry.registry_value_data IN + ("0x00000001", "9") by Registry.registry_key_name Registry.user Registry.registry_path + Registry.registry_value_data Registry.action Registry.dest | `drop_dm_object_name(Registry)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_define_win_defender_threat_action_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -66,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_delete_win_defender_context_menu.yml b/detections/endpoint/windows_impair_defense_delete_win_defender_context_menu.yml index 37116639d0..028057a2a4 100644 --- a/detections/endpoint/windows_impair_defense_delete_win_defender_context_menu.yml +++ b/detections/endpoint/windows_impair_defense_delete_win_defender_context_menu.yml @@ -1,16 +1,18 @@ name: Windows Impair Defense Delete Win Defender Context Menu id: 395ed5fe-ad13-4366-9405-a228427bdd91 -version: 1 -date: '2022-06-07' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The search looks for the deletion of Windows Defender context menu within - the registry. This is consistent behavior with RAT malware across a fleet of endpoints. - This particular behavior is executed when an adversary gains access to an endpoint - and begins to perform execution. Usually, a batch (.bat) will be executed and multiple - registry and scheduled task modifications will occur. During triage, review parallel - processes and identify any further file modifications. +description: The following analytic detects the deletion of the Windows Defender context + menu entry from the registry. It leverages data from the Endpoint datamodel, specifically + monitoring registry actions where the path includes "*\\shellex\\ContextMenuHandlers\\EPP" + and the action is 'deleted'. This activity is significant as it is commonly associated + with Remote Access Trojan (RAT) malware attempting to disable security features. + If confirmed malicious, this could allow an attacker to impair defenses, facilitating + further malicious activities such as unauthorized access, persistence, and data + exfiltration. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -63,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/delete_win_defender_context_menu/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/delete_win_defender_context_menu/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_impair_defense_delete_win_defender_profile_registry.yml b/detections/endpoint/windows_impair_defense_delete_win_defender_profile_registry.yml index 04db697641..d6b47becd8 100644 --- a/detections/endpoint/windows_impair_defense_delete_win_defender_profile_registry.yml +++ b/detections/endpoint/windows_impair_defense_delete_win_defender_profile_registry.yml @@ -1,16 +1,18 @@ name: Windows Impair Defense Delete Win Defender Profile Registry id: 65d4b105-ec52-48ec-ac46-289d0fbf7d96 -version: 1 -date: '2022-06-07' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The search looks for the deletion of Windows Defender main profile within - the registry. This was used by RAT malware across a fleet of endpoints. This particular - behavior is typically executed when an adversary gains access to an endpoint and - beings to perform execution. Usually, a batch (.bat) will be executed and multiple - registry and scheduled task modifications will occur. During triage, review parallel - processes and identify any further file modifications. +description: The following analytic detects the deletion of the Windows Defender main + profile registry key. It leverages data from the Endpoint.Registry datamodel, specifically + monitoring for deleted actions within the Windows Defender registry path. This activity + is significant as it indicates potential tampering with security defenses, often + associated with Remote Access Trojans (RATs) and other malware. If confirmed malicious, + this action could allow an attacker to disable Windows Defender, reducing the system's + ability to detect and respond to further malicious activities, thereby compromising + endpoint security. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -63,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/delete_win_defender_context_menu/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/delete_win_defender_context_menu/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_impair_defense_deny_security_software_with_applocker.yml b/detections/endpoint/windows_impair_defense_deny_security_software_with_applocker.yml index 3dc1fef0ab..a40b2650a8 100644 --- a/detections/endpoint/windows_impair_defense_deny_security_software_with_applocker.yml +++ b/detections/endpoint/windows_impair_defense_deny_security_software_with_applocker.yml @@ -1,15 +1,18 @@ name: Windows Impair Defense Deny Security Software With Applocker id: e0b6ca60-9e29-4450-b51a-bba0abae2313 -version: 1 -date: '2022-06-24' +version: 2 +date: '2024-05-09' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a modification in the Windows registry - by the Applocker utility that contains details or registry data values related to - denying the execution of several security products. This technique was seen in Azorult - malware where it drops an xml Applocker policy that will deny several AV products - and then loaded by using PowerShell Applocker commandlet. +description: The following analytic detects modifications in the Windows registry + by the Applocker utility that deny the execution of various security products. This + detection leverages data from the Endpoint.Registry datamodel, focusing on specific + registry paths and values indicating a "Deny" action against known antivirus and + security software. This activity is significant as it may indicate an attempt to + disable security defenses, a tactic observed in malware like Azorult. If confirmed + malicious, this could allow attackers to bypass security measures, facilitating + further malicious activities and persistence within the environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -72,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_impair_defense_disable_controlled_folder_access.yml b/detections/endpoint/windows_impair_defense_disable_controlled_folder_access.yml index 452ac260f4..4fd31eb924 100644 --- a/detections/endpoint/windows_impair_defense_disable_controlled_folder_access.yml +++ b/detections/endpoint/windows_impair_defense_disable_controlled_folder_access.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Disable Controlled Folder Access id: 3032741c-d6fc-4c69-8988-be8043d6478c -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - Controlled Folder Access feature. The EnableControlledFolderAccess registry setting is associated with the Controlled - Folder Access feature in Windows Defender. Controlled Folder Access is a security feature designed to protect certain - folders from unauthorized access or modification by malicious applications, including ransomware. - When EnableControlledFolderAccess is set to 0, it usually indicates that the Controlled Folder Access feature - within Windows Defender is not active. Consequently, the protection mechanism for the specified folders against - unauthorized access by potentially malicious applications or ransomware is not enabled. +description: The following analytic detects a modification in the Windows registry + that disables the Windows Defender Controlled Folder Access feature. It leverages + data from the Endpoint.Registry data model, specifically monitoring changes to the + EnableControlledFolderAccess registry setting. This activity is significant because + Controlled Folder Access is designed to protect critical folders from unauthorized + access, including ransomware attacks. If this activity is confirmed malicious, it + could allow attackers to bypass a key security feature, potentially leading to unauthorized + access or modification of sensitive files. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Windows Defender Exploit Guard\\Controlled Folder Access\\EnableControlledFolderAccess" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Windows Defender Exploit Guard\\Controlled Folder Access\\EnableControlledFolderAccess" + Registry.registry_value_data="0x00000000" by Registry.registry_key_name Registry.user + Registry.registry_path Registry.registry_value_data Registry.action Registry.dest + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_controlled_folder_access_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -66,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_defender_firewall_and_network.yml b/detections/endpoint/windows_impair_defense_disable_defender_firewall_and_network.yml index 8fe39a685b..ce1d9979f6 100644 --- a/detections/endpoint/windows_impair_defense_disable_defender_firewall_and_network.yml +++ b/detections/endpoint/windows_impair_defense_disable_defender_firewall_and_network.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Disable Defender Firewall And Network id: 8467d8cd-b0f9-46fa-ac84-a30ad138983e -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable firewall - and network protection section settings of windows security. The specific impact of this change depends - on the context and the purpose behind modifying this registry value. In general, setting UILockdown to 1 - might imply enforcing a restriction or lockdown in the user interface (UI) related to firewall and network - protection settings within Windows Defender Security Center. This could potentially restrict users from modifying - certain firewall or network protection settings through the UI. +description: The following analytic detects modifications in the Windows registry + to disable firewall and network protection settings within Windows Defender Security + Center. It leverages data from the Endpoint.Registry data model, specifically monitoring + changes to the UILockdown registry value. This activity is significant as it may + indicate an attempt to impair system defenses, potentially restricting users from + modifying firewall or network protection settings. If confirmed malicious, this + could allow an attacker to weaken the system's security posture, making it more + vulnerable to further attacks and unauthorized access. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender Security Center\\Firewall and network protection\\UILockdown" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_defender_firewall_and_network_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender Security Center\\Firewall and network protection\\UILockdown" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_defender_firewall_and_network_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -39,7 +39,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: Windows Defender firewall and network protection section feature set to disable on $dest$. + message: Windows Defender firewall and network protection section feature set to + disable on $dest$. mitre_attack_id: - T1562.001 - T1562 @@ -65,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_defender_protocol_recognition.yml b/detections/endpoint/windows_impair_defense_disable_defender_protocol_recognition.yml index d69afcad10..4ecad8e241 100644 --- a/detections/endpoint/windows_impair_defense_disable_defender_protocol_recognition.yml +++ b/detections/endpoint/windows_impair_defense_disable_defender_protocol_recognition.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Disable Defender Protocol Recognition id: b2215bfb-6171-4137-af17-1a02fdd8d043 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - protocol recognition feature. The DisableProtocolRecognition setting in Windows Defender is not a commonly known - or documented registry setting. It's possible that this specific setting might not exist within the standard - Windows Defender configurations or that it might be specific to certain environments, versions, or configurations. - It might potentially control or influence the antivirus software's ability to recognize and handle specific protocols - or communication methods used by malware or suspicious software. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender protocol recognition feature. It leverages data + from the Endpoint.Registry data model, specifically looking for changes to the "DisableProtocolRecognition" + setting. This activity is significant because disabling protocol recognition can + hinder Windows Defender's ability to detect and respond to malware or suspicious + software. If confirmed malicious, this action could allow an attacker to bypass + antivirus defenses, facilitating further malicious activities such as data exfiltration + or system compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\NIS\\DisableProtocolRecognition" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_defender_protocol_recognition_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\NIS\\DisableProtocolRecognition" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_defender_protocol_recognition_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_pua_protection.yml b/detections/endpoint/windows_impair_defense_disable_pua_protection.yml index ab55ef1d3a..645c85539e 100644 --- a/detections/endpoint/windows_impair_defense_disable_pua_protection.yml +++ b/detections/endpoint/windows_impair_defense_disable_pua_protection.yml @@ -1,29 +1,27 @@ name: Windows Impair Defense Disable PUA Protection id: fbfef407-cfee-4866-88c1-f8de1c16147c -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - PUA protection. - Setting PUAProtection to 0 typically disables the detection and protection against Potentially Unwanted Applications - by Microsoft Defender Antivirus. Potentially Unwanted Applications include software that may not be inherently - malicious but could exhibit behaviors that users may find undesirable, such as adware, browser toolbars, or software bundlers. - Disabling this feature might be preferred in certain situations, but it's essential to consider potential security implications. - Enabling PUA protection provides an additional layer of defense against software that might negatively impact user experience - or security. +description: The following analytic detects a modification in the Windows registry + to disable Windows Defender PUA protection by setting PUAProtection to 0. This detection + leverages data from the Endpoint.Registry datamodel, focusing on registry path changes + related to Windows Defender. Disabling PUA protection is significant as it reduces + defenses against Potentially Unwanted Applications (PUAs), which, while not always + malicious, can negatively impact user experience and security. If confirmed malicious, + this activity could allow an attacker to introduce adware, browser toolbars, or + other unwanted software, potentially compromising system integrity and user productivity. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\PUAProtection" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_pua_protection_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\PUAProtection" Registry.registry_value_data="0x00000000" by Registry.registry_key_name + Registry.user Registry.registry_path Registry.registry_value_data Registry.action + Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_pua_protection_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -67,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_realtime_signature_delivery.yml b/detections/endpoint/windows_impair_defense_disable_realtime_signature_delivery.yml index 307965ad1f..09bbfd21f9 100644 --- a/detections/endpoint/windows_impair_defense_disable_realtime_signature_delivery.yml +++ b/detections/endpoint/windows_impair_defense_disable_realtime_signature_delivery.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Disable Realtime Signature Delivery id: ffd99aea-542f-448e-b737-091c1b417274 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable windows defender - realtime signature delivery feature. This setting governs how Windows Defender Antivirus receives updated signature - definitions for identifying and combating malware threats in real-time. The actual impact and behaviors associated - with different values for RealtimeSignatureDelivery can vary based on specific Windows Defender configurations and policies. - For instance, setting this value to 0 or 1 might control whether real-time signatures are delivered via different methods - such as through Windows Update or directly from Microsoft's cloud-based services. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender real-time signature delivery feature. It leverages + data from the Endpoint.Registry data model, specifically monitoring changes to the + registry path associated with Windows Defender signature updates. This activity + is significant because disabling real-time signature delivery can prevent Windows + Defender from receiving timely malware definitions, reducing its effectiveness. + If confirmed malicious, this action could allow attackers to bypass malware detection, + leading to potential system compromise and persistent threats. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Signature Updates\\RealtimeSignatureDelivery" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_realtime_signature_delivery_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Signature Updates\\RealtimeSignatureDelivery" Registry.registry_value_data="0x00000000" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_realtime_signature_delivery_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_web_evaluation.yml b/detections/endpoint/windows_impair_defense_disable_web_evaluation.yml index db5ee0a77d..ca0db28199 100644 --- a/detections/endpoint/windows_impair_defense_disable_web_evaluation.yml +++ b/detections/endpoint/windows_impair_defense_disable_web_evaluation.yml @@ -1,31 +1,27 @@ name: Windows Impair Defense Disable Web Evaluation id: e234970c-dcf5-4f80-b6a9-3a562544ca5b -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - web content evaluation. The "EnableWebContentEvaluation" registry entry typically relates to security settings - within Microsoft Edge or Internet Explorer, enabling the evaluation of web content for security purposes. - When attackers modify "EnableWebContentEvaluation" to 0, they might attempt to disable the browser's - capability to evaluate web content for security purposes. Disabling this feature could potentially impact - the browser's ability to assess the security risks associated with web content, such as potentially malicious scripts, - active content, or unsafe web elements. - By turning off content evaluation, attackers might aim to exploit security vulnerabilities present in web content without - triggering security warnings or blocks. This manipulation increases the risk of users accessing or interacting with malicious - content, potentially leading to security compromises or system exploitation. +description: The following analytic detects modifications to the Windows registry + entry "EnableWebContentEvaluation" to disable Windows Defender web content evaluation. + It leverages data from the Endpoint.Registry datamodel, specifically monitoring + changes where the registry value is set to "0x00000000". This activity is significant + as it indicates an attempt to impair browser security features, potentially allowing + malicious web content to bypass security checks. If confirmed malicious, this could + lead to users interacting with harmful scripts or unsafe web elements, increasing + the risk of system exploitation and security breaches. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE Registry.registry_path= "*\\Windows\\CurrentVersion\\AppHost\\EnableWebContentEvaluation" Registry.registry_value_data= "0x00000000" - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name - Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_web_evaluation_filter`' + WHERE Registry.registry_path= "*\\Windows\\CurrentVersion\\AppHost\\EnableWebContentEvaluation" Registry.registry_value_data= + "0x00000000" BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_web_evaluation_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -69,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_app_guard.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_app_guard.yml index b56927f230..02f4147feb 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_app_guard.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_app_guard.yml @@ -1,29 +1,26 @@ name: Windows Impair Defense Disable Win Defender App Guard id: 8b700d7e-54ad-4d7d-81cc-1456c4703306 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - audit application guard. - Microsoft Defender Application Guard provides enhanced security by isolating potentially malicious documents and - websites in a containerized environment, protecting the system against various threats. Auditing and logging are - essential components of security measures, providing visibility into activities within the isolated environment. - Disabling auditing events within Application Guard might not be a standard or recommended practice since auditing - is crucial for security monitoring and threat detection within the isolated container. However, there might be - settings or configurations related to audit policies in the broader Windows Defender or operating system settings. - This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications to the Windows registry + that disable Windows Defender Application Guard auditing. It leverages data from + the Endpoint.Registry data model, focusing on specific registry paths and values. + This activity is significant because disabling auditing can hinder security monitoring + and threat detection within the isolated environment, making it easier for malicious + activities to go unnoticed. If confirmed malicious, this action could allow attackers + to bypass Windows Defender protections, potentially leading to unauthorized access, + data exfiltration, or further system compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Policies\\Microsoft\\AppHVSI\\AuditApplicationGuard" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + Registry.registry_value_data="0x00000000" by Registry.registry_key_name Registry.user + Registry.registry_path Registry.registry_value_data Registry.action Registry.dest + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_app_guard_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -68,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_compute_file_hashes.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_compute_file_hashes.yml index 90cce17ec9..1f6f7f35c6 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_compute_file_hashes.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_compute_file_hashes.yml @@ -1,26 +1,27 @@ name: Windows Impair Defense Disable Win Defender Compute File Hashes id: fe52c280-98bd-4596-b6f6-a13bbf8ac7c6 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender file hashes computation. - The EnableFileHashComputation registry setting likely pertains to whether Windows Defender's MpEngine (Malware Protection Engine) computes - file hashes. Setting this value to 0 might disable the file hash computation feature within Windows Defender, which could affect certain - malware detection or scanning functionalities that rely on file hash analysis. This registry setting is being abuse by several threat actors, adversaries - and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications to the Windows registry + that disable Windows Defender's file hash computation by setting the EnableFileHashComputation + value to 0. This detection leverages data from the Endpoint.Registry data model, + focusing on changes to the specific registry path associated with Windows Defender. + Disabling file hash computation can significantly impair Windows Defender's ability + to detect and scan for malware, making it a critical behavior to monitor. If confirmed + malicious, this activity could allow attackers to bypass Windows Defender, facilitating + undetected malware execution and persistence in the environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\MpEngine\\EnableFileHashComputation" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_win_defender_compute_file_hashes_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\MpEngine\\EnableFileHashComputation" Registry.registry_value_data="0x00000000" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_compute_file_hashes_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -64,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_gen_reports.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_gen_reports.yml index 65c2e5d4d7..13250a24ee 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_gen_reports.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_gen_reports.yml @@ -1,27 +1,27 @@ name: Windows Impair Defense Disable Win Defender Gen reports id: 93f114f6-cb1e-419b-ac3f-9e11a3045e70 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - generic ports. This registry can disable the sending of Watson events in Windows Defender. This is by preventing - the transmission of generic or non-specific error reports to Microsoft's Windows Error Reporting service, - commonly known as Watson. This kind of setting could potentially be employed to limit or control the data sent to - Microsoft for error analysis, often in scenarios where privacy or specific reporting requirements are in place. - This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications in the Windows registry + to disable Windows Defender generic reports. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the "DisableGenericRePorts" registry + value. This activity is significant as it can prevent the transmission of error + reports to Microsoft's Windows Error Reporting service, potentially hiding malicious + activities. If confirmed malicious, this action could allow attackers to bypass + Windows Defender detections, reducing the visibility of their activities and increasing + the risk of undetected system compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Reporting\\DisableGenericRePorts" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_win_defender_gen_reports_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Reporting\\DisableGenericRePorts" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_gen_reports_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -65,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_network_protection.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_network_protection.yml index b8f4dbf87a..3829d5bca7 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_network_protection.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_network_protection.yml @@ -1,26 +1,27 @@ name: Windows Impair Defense Disable Win Defender Network Protection id: 8b6c15c7-5556-463d-83c7-986326c21f12 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - exploit guard network protection. The EnableNetworkProtection registry entry controls the activation or deactivation - of Network Protection within Windows Defender Exploit Guard. When set to 1, it typically signifies that Network Protection - is enabled, offering additional security measures against network-based threats by analyzing and blocking potentially - malicious network activity. This registry setting is being abuse by several threat actors, adversaries - and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications to the Windows registry + that disable Windows Defender Network Protection. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the EnableNetworkProtection registry + entry. This activity is significant because disabling Network Protection can leave + the system vulnerable to network-based threats by preventing Windows Defender from + analyzing and blocking malicious network activity. If confirmed malicious, this + action could allow attackers to bypass security measures, potentially leading to + unauthorized access, data exfiltration, or further compromise of the network. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Windows Defender Exploit Guard\\Network Protection\\EnableNetworkProtection" - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Windows Defender Exploit Guard\\Network Protection\\EnableNetworkProtection" + Registry.registry_value_data="0x00000000" by Registry.registry_key_name Registry.user + Registry.registry_path Registry.registry_value_data Registry.action Registry.dest + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_network_protection_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -65,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_report_infection.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_report_infection.yml index 29a66289be..7796d1d06b 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_report_infection.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_report_infection.yml @@ -1,26 +1,26 @@ name: Windows Impair Defense Disable Win Defender Report Infection id: 201946c6-b1d5-42bb-a7e0-5f7123f47fc4 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable windows defender - report infection information. Setting this registry key to 1, Instructs Windows Defender not to report detailed - information about infections or threats detected on the system to Microsoft. Enabling this setting might limit - or prevent the transmission of specific data related to infections, such as details about the detected malware, - to Microsoft's servers for analysis or logging purposes. - This registry is being abused by adversaries, threat actors and red-teamers to bypasses Windows Defender detections. +description: The following analytic detects modifications to the Windows registry + that disable Windows Defender's infection reporting. It leverages data from the + Endpoint.Registry datamodel, specifically monitoring changes to the "DontReportInfectionInformation" + registry key. This activity is significant because it can prevent Windows Defender + from reporting detailed threat information to Microsoft, potentially allowing malware + to evade detection. If confirmed malicious, this action could enable attackers to + bypass security measures, maintain persistence, and avoid detection, leading to + prolonged unauthorized access and potential data breaches. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Microsoft\\MRT\\DontReportInfectionInformation" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + Registry.registry_value_data="0x00000001" by Registry.registry_key_name Registry.user + Registry.registry_path Registry.registry_value_data Registry.action Registry.dest + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_report_infection_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -39,7 +39,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: Windows Defender DontReportInfectionInformation registry is enabled on $dest$. + message: Windows Defender DontReportInfectionInformation registry is enabled on + $dest$. mitre_attack_id: - T1562.001 - T1562 @@ -65,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_scan_on_update.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_scan_on_update.yml index 172942e72b..e01d1f1143 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_scan_on_update.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_scan_on_update.yml @@ -1,29 +1,26 @@ name: Windows Impair Defense Disable Win Defender Scan On Update id: 0418e72f-e710-4867-b656-0688e1523e09 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable Windows Defender - Scan On Update. The "DisableScanOnUpdate" registry setting in Windows Defender, when set to a value of 1, typically - signifies the feature that prevents automatic scans from initiating when updates to Windows Defender - or its antivirus definitions are installed. - Any modifications to registry settings, it's important to ensure that changes align with security policies and best practices. - Incorrect settings might affect the system's security or functionality. Always consider the implications and ensure changes - are made based on accurate information and organizational requirements. - This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender Scan On Update feature. It leverages data from + the Endpoint.Registry datamodel, specifically looking for changes to the "DisableScanOnUpdate" + registry setting with a value of "0x00000001". This activity is significant because + disabling automatic scans can leave systems vulnerable to malware and other threats. + If confirmed malicious, this action could allow attackers to bypass Windows Defender, + facilitating further compromise and persistence within the environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\Signature Updates\\DisableScanOnUpdate" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_win_defender_scan_on_update_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\Signature Updates\\DisableScanOnUpdate" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_scan_on_update_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -67,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_disable_win_defender_signature_retirement.yml b/detections/endpoint/windows_impair_defense_disable_win_defender_signature_retirement.yml index e8148b48ee..cf9d08115b 100644 --- a/detections/endpoint/windows_impair_defense_disable_win_defender_signature_retirement.yml +++ b/detections/endpoint/windows_impair_defense_disable_win_defender_signature_retirement.yml @@ -1,30 +1,27 @@ name: Windows Impair Defense Disable Win Defender Signature Retirement id: 7567a72f-bada-489d-aef1-59743fb64a66 -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable windows defender - Signature Retirement. The DisableSignatureRetirement registry setting in Windows Defender controls the retirement - or expiration of antivirus signatures used by Windows Defender Antivirus. - When DisableSignatureRetirement is set to 1, it usually indicates that Windows Defender won't automatically retire - or expire antivirus signatures. Antivirus signatures are files containing information about known malware and are - used by Windows Defender to detect and protect against threats. - Disabling signature retirement might prevent Windows Defender from automatically removing or retiring older or less - relevant antivirus signatures. This can potentially increase the number of signatures in use and might impact system - resources or the effectiveness of threat detection. +description: The following analytic detects modifications to the Windows registry + that disable Windows Defender Signature Retirement. It leverages data from the Endpoint.Registry + data model, specifically monitoring changes to the DisableSignatureRetirement registry + setting. This activity is significant because disabling signature retirement can + prevent Windows Defender from removing outdated antivirus signatures, potentially + reducing its effectiveness in detecting threats. If confirmed malicious, this action + could allow an attacker to evade detection by using older, less relevant signatures, + thereby compromising the system's security posture. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows Defender\\NIS\\Consumers\\IPS\\DisableSignatureRetirement" - Registry.registry_value_data="0x00000001" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_disable_win_defender_signature_retirement_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Windows + Defender\\NIS\\Consumers\\IPS\\DisableSignatureRetirement" Registry.registry_value_data="0x00000001" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_disable_win_defender_signature_retirement_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -42,7 +39,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: Windows Defender DisableSignatureRetirement registry is set to enable on $dest$. + message: Windows Defender DisableSignatureRetirement registry is set to enable on + $dest$. mitre_attack_id: - T1562.001 - T1562 @@ -68,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_overide_win_defender_phishing_filter.yml b/detections/endpoint/windows_impair_defense_overide_win_defender_phishing_filter.yml index 187dc99e75..db2f560571 100644 --- a/detections/endpoint/windows_impair_defense_overide_win_defender_phishing_filter.yml +++ b/detections/endpoint/windows_impair_defense_overide_win_defender_phishing_filter.yml @@ -1,28 +1,28 @@ name: Windows Impair Defense Overide Win Defender Phishing Filter id: 10ca081c-57b1-4a78-ba56-14a40a7e116a -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to disable windows defender - phishing filter. This setting controls whether users can manually disable or modify the browser's built-in phishing filter. - When attackers modify "PreventOverride" to 0, it might indicate an attempt to disable the prevention of user overrides for - the phishing filter within Microsoft Edge. This change allows users to bypass or disable the built-in phishing protection provided by the browser. - By allowing users to override the phishing filter, attackers may attempt to deceive users into visiting phishing websites or - malicious pages without triggering warnings or protections from the browser's built-in security measures. This manipulation increases the - risk of users unknowingly accessing potentially harmful websites, leading to potential security incidents or compromises. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender phishing filter. It leverages data from the Endpoint.Registry + data model, focusing on changes to specific registry values related to Microsoft + Edge's phishing filter settings. This activity is significant because disabling + the phishing filter can allow attackers to deceive users into visiting malicious + websites without triggering browser warnings. If confirmed malicious, this could + lead to users unknowingly accessing harmful sites, resulting in potential security + incidents or data compromises. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_key_name = "*\\MicrosoftEdge\\PhishingFilter" Registry.registry_value_name IN ("EnabledV9", "PreventOverride") - Registry.registry_value_data="0x00000000" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_overide_win_defender_phishing_filter_filter`' + as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_key_name = + "*\\MicrosoftEdge\\PhishingFilter" Registry.registry_value_name IN ("EnabledV9", + "PreventOverride") Registry.registry_value_data="0x00000000" by Registry.registry_key_name + Registry.user Registry.registry_path Registry.registry_value_data Registry.action + Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_overide_win_defender_phishing_filter_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -66,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_override_smartscreen_prompt.yml b/detections/endpoint/windows_impair_defense_override_smartscreen_prompt.yml index b1263d8685..741c72ce63 100644 --- a/detections/endpoint/windows_impair_defense_override_smartscreen_prompt.yml +++ b/detections/endpoint/windows_impair_defense_override_smartscreen_prompt.yml @@ -1,28 +1,27 @@ name: Windows Impair Defense Override SmartScreen Prompt id: 08058866-7987-486f-b042-275715ef6e9d -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to override windows defender - smartscreen prompt. The "PreventSmartScreenPromptOverride" registry setting is associated with the Windows SmartScreen feature, - specifically related to controlling whether users can override SmartScreen prompts. - When attackers modify "PreventSmartScreenPromptOverride" to 0, it signifies an attempt to disable the prevention of user overrides - for SmartScreen prompts. By doing so, attackers aim to allow users to bypass or ignore SmartScreen warnings or prompts. - This change increases the risk by permitting users to disregard warnings about potentially unsafe or malicious files or - websites that would typically trigger SmartScreen alerts. It could lead to users unintentionally executing or accessing - malicious content, potentially resulting in security incidents or system compromises. +description: The following analytic detects modifications to the Windows registry + that override the Windows Defender SmartScreen prompt. It leverages data from the + Endpoint.Registry data model, specifically monitoring changes to the "PreventSmartScreenPromptOverride" + registry setting. This activity is significant because it indicates an attempt to + disable the prevention of user overrides for SmartScreen prompts, potentially allowing + users to bypass security warnings. If confirmed malicious, this could lead to users + inadvertently executing or accessing harmful content, increasing the risk of security + incidents or system compromises. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE Registry.registry_path= "*\\Microsoft\\Edge\\PreventSmartScreenPromptOverride" Registry.registry_value_data= "0x00000000" - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_impair_defense_override_smartscreen_prompt_filter`' + WHERE Registry.registry_path= "*\\Microsoft\\Edge\\PreventSmartScreenPromptOverride" + Registry.registry_value_data= "0x00000000" BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_impair_defense_override_smartscreen_prompt_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. @@ -66,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defense_set_win_defender_smart_screen_level_to_warn.yml b/detections/endpoint/windows_impair_defense_set_win_defender_smart_screen_level_to_warn.yml index a24c698eaa..d2d8e1b17b 100644 --- a/detections/endpoint/windows_impair_defense_set_win_defender_smart_screen_level_to_warn.yml +++ b/detections/endpoint/windows_impair_defense_set_win_defender_smart_screen_level_to_warn.yml @@ -1,29 +1,26 @@ name: Windows Impair Defense Set Win Defender Smart Screen Level To Warn id: cc2a3425-2703-47e7-818f-3dca1b0bc56f -version: 1 -date: '2024-01-08' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to set windows defender - smart screen level to warn. Setting the ShellSmartScreenLevel to warn implies a SmartScreen configuration - where the system displays a warning prompt when users attempt to run or access potentially risky or unrecognized - files or applications. This warning serves as a cautionary alert to users, advising them about the potential - risks associated with the file or application they are trying to execute. - Changing SmartScreen settings to "warn" might be employed by attackers to reduce the likelihood of triggering - immediate suspicion from users when running malicious executables. By setting it to "warn," the system prompts a - cautionary warning rather than outright blocking the execution, potentially increasing the chances of users - proceeding with running the file despite the warning. +description: The following analytic detects modifications to the Windows registry + that set the Windows Defender SmartScreen level to "warn." This detection leverages + data from the Endpoint.Registry data model, specifically monitoring changes to the + ShellSmartScreenLevel registry value. This activity is significant because altering + SmartScreen settings to "warn" can reduce immediate suspicion from users, allowing + potentially malicious executables to run with just a warning prompt. If confirmed + malicious, this could enable attackers to execute harmful files, increasing the + risk of successful malware deployment and subsequent system compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path= "*\\Microsoft\\Windows\\System\\ShellSmartScreenLevel" - Registry.registry_value_data="Warn" - by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + Registry.registry_value_data="Warn" by Registry.registry_key_name Registry.user + Registry.registry_path Registry.registry_value_data Registry.action Registry.dest + | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defense_set_win_defender_smart_screen_level_to_warn_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -68,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable-windows-security-defender-features/windefender-bypas-2-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defenses_disable_hvci.yml b/detections/endpoint/windows_impair_defenses_disable_hvci.yml index 0769887403..74a15ee529 100644 --- a/detections/endpoint/windows_impair_defenses_disable_hvci.yml +++ b/detections/endpoint/windows_impair_defenses_disable_hvci.yml @@ -1,32 +1,42 @@ name: Windows Impair Defenses Disable HVCI id: b061dfcc-f0aa-42cc-a6d4-a87f172acb79 -version: 1 -date: '2023-04-13' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic refers to a detection mechanism designed to identify when the Hypervisor-protected Code Integrity (HVCI) feature is disabled within the Windows registry. HVCI is a security feature in Windows 10 and Windows Server 2016 that helps protect the kernel and system processes from being tampered with by malicious code. - HVCI relies on hardware-assisted virtualization and Microsoft's Hyper-V hypervisor to ensure that only kernel-mode code that has been signed by Microsoft or the system's hardware manufacturer can be executed. This prevents attackers from exploiting vulnerabilities to run unsigned code, like kernel-mode rootkits or other malicious software, at the kernel level. - Disabling HVCI may expose the system to security risks and could be an indicator of a potential compromise or unauthorized activity. The analytic aims to detect and report events or configurations that lead to the disabling of HVCI. +description: The following analytic detects the disabling of Hypervisor-protected + Code Integrity (HVCI) by monitoring changes in the Windows registry. It leverages + data from the Endpoint datamodel, specifically focusing on registry paths and values + related to HVCI settings. This activity is significant because HVCI helps protect + the kernel and system processes from tampering by malicious code. If confirmed malicious, + disabling HVCI could allow attackers to execute unsigned kernel-mode code, potentially + leading to kernel-level rootkits or other severe security breaches. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\CurrentControlSet\\Control\\DeviceGuard\\Scenarios\\HypervisorEnforcedCodeIntegrity\\Enabled" Registry.registry_value_data="0x00000000" by Registry.registry_path Registry.registry_value_name + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\CurrentControlSet\\Control\\DeviceGuard\\Scenarios\\HypervisorEnforcedCodeIntegrity\\Enabled" + Registry.registry_value_data="0x00000000" by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_impair_defenses_disable_hvci_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: False positives will be limited to administrative scripts disabling HVCI. Filter as needed. +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: False positives will be limited to administrative scripts disabling + HVCI. Filter as needed. references: - - https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ +- https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ tags: analytic_story: - BlackLotus Campaign - Windows Defense Evasion Tactics - Windows Registry Abuse asset_type: Endpoint - atomic_guid: + atomic_guid: - 70bd71e6-eba4-4e00-92f7-617911dbe020 confidence: 100 impact: 70 @@ -56,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/hvci_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/hvci_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_impair_defenses_disable_win_defender_auto_logging.yml b/detections/endpoint/windows_impair_defenses_disable_win_defender_auto_logging.yml index 63f1ca8f24..e3649c03d7 100644 --- a/detections/endpoint/windows_impair_defenses_disable_win_defender_auto_logging.yml +++ b/detections/endpoint/windows_impair_defenses_disable_win_defender_auto_logging.yml @@ -1,16 +1,18 @@ name: Windows Impair Defenses Disable Win Defender Auto Logging id: 76406a0f-f5e0-4167-8e1f-337fdc0f1b0c -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The search looks for the Registry Key DefenderApiLogger or DefenderAuditLogger - set to disable. This is consistent with RAT malware across a fleet of endpoints. - This particular behavior is typically executed when an adversary gains access to - an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed - and multiple registry and scheduled task modifications will occur. During triage, - review parallel processes and identify any further file modifications. +description: The following analytic detects the disabling of Windows Defender logging + by identifying changes to the Registry keys DefenderApiLogger or DefenderAuditLogger + set to disable. It leverages data from the Endpoint.Registry datamodel to monitor + specific registry paths and values. This activity is significant as it is commonly + associated with Remote Access Trojan (RAT) malware attempting to evade detection. + If confirmed malicious, this action could allow an attacker to conceal their activities, + making it harder to detect further malicious actions and maintain persistence on + the compromised endpoint. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -64,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable_defender_logging/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/disable_defender_logging/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_indicator_removal_via_rmdir.yml b/detections/endpoint/windows_indicator_removal_via_rmdir.yml index 4be0e1b285..d5143ea681 100644 --- a/detections/endpoint/windows_indicator_removal_via_rmdir.yml +++ b/detections/endpoint/windows_indicator_removal_via_rmdir.yml @@ -1,25 +1,27 @@ name: Windows Indicator Removal Via Rmdir id: c4566d2c-b094-48a1-9c59-d66e22065560 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: The following analytic identifies a process execute rmdir commandline to delete files and directory tree. - This technique has been observed in the actions of various malware strains, such as DarkGate, - as they attempt to eliminate specific files or components during their cleanup operations within compromised hosts. - Notably, this deletion method doesn't exclusively require elevated privileges and can be executed by regular users or network administrators, - although it's not the typical approach used for file deletion. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process = "*rmdir*" Processes.process = "* /s *" Processes.process = "* /q *" - by Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.process_guid Processes.parent_process_name Processes.parent_process Processes.parent_process_guid Processes.dest Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_indicator_removal_via_rmdir_filter`' +description: The following analytic detects the execution of the 'rmdir' command with + '/s' and '/q' options to delete files and directory trees. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and process metadata. This activity is significant as it may indicate + malware attempting to remove traces or components during cleanup operations. If + confirmed malicious, this behavior could allow attackers to eliminate forensic evidence, + hinder incident response efforts, and maintain persistence by removing indicators + of compromise. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process = "*rmdir*" + Processes.process = "* /s *" Processes.process = "* /q *" by Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.process_guid + Processes.parent_process_name Processes.parent_process Processes.parent_process_guid + Processes.dest Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_indicator_removal_via_rmdir_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -70,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/rmdir_delete_files_and_dir/rmdir.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070/rmdir_delete_files_and_dir/rmdir.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_indirect_command_execution_via_forfiles.yml b/detections/endpoint/windows_indirect_command_execution_via_forfiles.yml index 4d626dc7a2..b959dc3314 100644 --- a/detections/endpoint/windows_indirect_command_execution_via_forfiles.yml +++ b/detections/endpoint/windows_indirect_command_execution_via_forfiles.yml @@ -1,15 +1,19 @@ name: Windows Indirect Command Execution Via forfiles id: 1fdf31c9-ff4d-4c48-b799-0e8666e08787 -version: 1 -date: '2022-04-05' +version: 2 +date: '2024-05-28' author: Eric McGinnis, Splunk status: production type: TTP -description: The following analytic detects programs that have been started by forfiles.exe. - According to Microsoft, the 'The forfiles command lets you run a command on or pass - arguments to multiple files'. While this tool can be used to start legitimate programs, - usually within the context of a batch script, it has been observed being used to - evade protections on command line execution. +description: The following analytic detects the execution of programs initiated by + forfiles.exe. This command is typically used to run commands on multiple files, + often within batch scripts. The detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where forfiles.exe + is the parent process. This activity is significant because forfiles.exe can be + exploited to bypass command line execution protections, making it a potential vector + for malicious activity. If confirmed malicious, this could allow attackers to execute + arbitrary commands, potentially leading to unauthorized access or further system + compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1202/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1202/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_indirect_command_execution_via_pcalua.yml b/detections/endpoint/windows_indirect_command_execution_via_pcalua.yml index f5dc78005c..cec4a83828 100644 --- a/detections/endpoint/windows_indirect_command_execution_via_pcalua.yml +++ b/detections/endpoint/windows_indirect_command_execution_via_pcalua.yml @@ -1,14 +1,18 @@ name: Windows Indirect Command Execution Via pcalua id: 3428ac18-a410-4823-816c-ce697d26f7a8 -version: 1 -date: '2022-04-05' +version: 2 +date: '2024-05-10' author: Eric McGinnis, Splunk status: production type: TTP -description: The following analytic detects programs that have been started by pcalua.exe. - pcalua.exe is the Microsoft Windows Program Compatability Assistant. While this - tool can be used to start legitimate programs, it has been observed being used to - evade protections on command line execution. +description: The following analytic detects programs initiated by pcalua.exe, the + Microsoft Windows Program Compatibility Assistant. This detection leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process and parent + process information. While pcalua.exe can start legitimate programs, it is significant + because attackers may use it to bypass command line execution protections. If confirmed + malicious, this activity could allow attackers to execute arbitrary commands, potentially + leading to unauthorized actions, privilege escalation, or persistence within the + environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1202/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1202/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_indirect_command_execution_via_series_of_forfiles.yml b/detections/endpoint/windows_indirect_command_execution_via_series_of_forfiles.yml index ff5a3c559c..a5db471e72 100644 --- a/detections/endpoint/windows_indirect_command_execution_via_series_of_forfiles.yml +++ b/detections/endpoint/windows_indirect_command_execution_via_series_of_forfiles.yml @@ -1,15 +1,18 @@ name: Windows Indirect Command Execution Via Series Of Forfiles id: bfdaabe7-3db8-48c5-80c1-220f9b8f22be -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is developed to detect suspicious excessive usage of forfiles.exe - process. This event was seen in post exploitation tool WINPEAS that was used by - Ransomware Prestige. Forfiles command lets you run a command on or pass arguments - to multiple files. This Windows OS built-in tool being abused to list all files - in specific directory or drive. +description: The following analytic detects excessive usage of the forfiles.exe process, + which is often indicative of post-exploitation activities. The detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs that include process GUID, process name, and parent process. This activity + is significant because forfiles.exe can be abused to execute commands on multiple + files, a technique used by ransomware like Prestige. If confirmed malicious, this + behavior could allow attackers to enumerate files, potentially leading to data exfiltration + or further malicious actions. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -70,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_information_discovery_fsutil.yml b/detections/endpoint/windows_information_discovery_fsutil.yml index ddecabde5f..d49801f8b6 100644 --- a/detections/endpoint/windows_information_discovery_fsutil.yml +++ b/detections/endpoint/windows_information_discovery_fsutil.yml @@ -1,16 +1,18 @@ name: Windows Information Discovery Fsutil id: 2181f261-93e6-4166-a5a9-47deac58feff -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process execution of Windows OS built-in - tool FSUTIL to discover file system information. This tool is being abused or used - by several adversaries or threat actor to query/list all drives, drive type, volume - information or volume statistics by using the FSINFO parameter of this tool. This - technique was seen in WINPEAS post exploitation tool that is being used by ransomware - prestige to gain privilege and persistence to the targeted host. +description: The following analytic identifies the execution of the Windows built-in + tool FSUTIL with the FSINFO parameter to discover file system information. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process execution logs that include command-line details. Monitoring this activity + is significant because FSUTIL can be abused by adversaries to gather detailed information + about the file system, aiding in further exploitation. If confirmed malicious, this + activity could enable attackers to map the file system, identify valuable data, + and plan subsequent actions such as privilege escalation or persistence. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_fsutil/fsutil-fsinfo-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_fsutil/fsutil-fsinfo-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_ingress_tool_transfer_using_explorer.yml b/detections/endpoint/windows_ingress_tool_transfer_using_explorer.yml index 2da6d1f10c..7a6841a325 100644 --- a/detections/endpoint/windows_ingress_tool_transfer_using_explorer.yml +++ b/detections/endpoint/windows_ingress_tool_transfer_using_explorer.yml @@ -1,18 +1,18 @@ name: Windows Ingress Tool Transfer Using Explorer id: 76753bab-f116-4ea3-8fb9-89b638be58a9 -version: 2 -date: '2022-08-30' +version: 3 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies the Windows Explorer process with a - URL within the command-line. Explorer.exe is known Windows process that handles - start menu, taskbar, desktop and file manager. Many adversaries abuse this process, - like DCRat malware, where it attempts to open the URL with the default browser application - on the target host by putting the URL as a parameter on explorer.exe process. This - anomaly detection might be a good pivot to check which user and how this process - was executed, what is the parent process and what is the URL link. This technique - is not commonly used to open an URL. +description: The following analytic identifies instances where the Windows Explorer + process (explorer.exe) is executed with a URL in its command line. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + execution logs. This activity is significant because adversaries, such as those + using DCRat malware, may abuse explorer.exe to open URLs with the default browser, + which is an uncommon and suspicious behavior. If confirmed malicious, this technique + could allow attackers to download and execute malicious payloads, leading to potential + system compromise and further malicious activities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) @@ -85,7 +85,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_explorer_url/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_explorer_url/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_inprocserver32_new_outlook_form.yml b/detections/endpoint/windows_inprocserver32_new_outlook_form.yml index c4dee8b4d8..c2a3773cf5 100644 --- a/detections/endpoint/windows_inprocserver32_new_outlook_form.yml +++ b/detections/endpoint/windows_inprocserver32_new_outlook_form.yml @@ -1,21 +1,31 @@ name: Windows InProcServer32 New Outlook Form id: fedb49c4-4bd7-4d42-8fd9-f8c8538c73c4 -version: 1 -date: '2024-03-20' +version: 2 +date: '2024-05-25' author: Michael Haag, Splunk data_source: - Sysmon EventID 13 type: Anomaly status: production -description: The following analytic identifies the creation or modification of registry keys associated with new Outlook form installations that could indicate exploitation of CVE-2024-21378. The vulnerability allows for authenticated remote code execution via synced form objects by abusing the InProcServer32 registry key. The attack involves syncing malicious form objects that carry special properties and attachments used to "install" the form on a client, potentially leading to arbitrary file and registry key creation under HKEY_CLASSES_ROOT (HKCR), and ultimately, remote code execution. This detection focuses on monitoring for registry modifications involving InProcServer32 keys or equivalent that are linked to Outlook form installations, which are indicative of an attempt to exploit this vulnerability. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\InProcServer32\\*" Registry.registry_value_data=*\\FORMS\\* by Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.dest Registry.process_guid Registry.user - | `drop_dm_object_name(Registry)` - |`security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_inprocserver32_new_outlook_form_filter`' +description: The following analytic detects the creation or modification of registry + keys associated with new Outlook form installations, potentially indicating exploitation + of CVE-2024-21378. It leverages data from the Endpoint.Registry datamodel, focusing + on registry paths involving InProcServer32 keys linked to Outlook forms. This activity + is significant as it may signify an attempt to achieve authenticated remote code + execution via malicious form objects. If confirmed malicious, this could allow an + attacker to create arbitrary files and registry keys, leading to remote code execution + and potential full system compromise. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + where Registry.registry_path="*\\InProcServer32\\*" Registry.registry_value_data=*\\FORMS\\* + by Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.dest Registry.process_guid Registry.user | + `drop_dm_object_name(Registry)` |`security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_inprocserver32_new_outlook_form_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. -known_false_positives: False positives are possible if the organization adds new forms to Outlook via an automated method. Filter by name or path to reduce false positives. +known_false_positives: False positives are possible if the organization adds new forms + to Outlook via an automated method. Filter by name or path to reduce false positives. references: - https://www.netspi.com/blog/technical/red-team-operations/microsoft-outlook-remote-code-execution-cve-2024-21378/ tags: @@ -26,7 +36,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A registry key associated with a new Outlook form installation was created or modified. This could indicate exploitation of CVE-2024-21378 on $dest$. + message: A registry key associated with a new Outlook form installation was created + or modified. This could indicate exploitation of CVE-2024-21378 on $dest$. mitre_attack_id: - T1566 - T1112 @@ -52,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/cve-2024-21378/inprocserver32_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/cve-2024-21378/inprocserver32_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_input_capture_using_credential_ui_dll.yml b/detections/endpoint/windows_input_capture_using_credential_ui_dll.yml index 369c6604ee..638b2a7d98 100644 --- a/detections/endpoint/windows_input_capture_using_credential_ui_dll.yml +++ b/detections/endpoint/windows_input_capture_using_credential_ui_dll.yml @@ -1,17 +1,17 @@ name: Windows Input Capture Using Credential UI Dll id: 406c21d6-6c75-4e9f-9ca9-48049a1dd90e -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process that loads the credui.dll - module. This legitimate module is typically abused by adversaries, threat actors - and red teamers to create a credential UI prompt dialog box to lure users for possible - credential theft or can be used to dump the credentials of a targeted host. This - hunting query is a good pivot to check why the process loaded this dll and if it - is a legitimate file. This hunting query may hit false positive for a third party - application that uses a credential login UI for user login. +description: The following analytic detects a process loading the credui.dll or wincredui.dll + module. This detection leverages Sysmon EventCode 7 to identify instances where + these DLLs are loaded by processes outside typical system directories. This activity + is significant because adversaries often abuse these modules to create fake credential + prompts or dump credentials, posing a risk of credential theft. If confirmed malicious, + this activity could allow attackers to harvest user credentials, leading to unauthorized + access and potential lateral movement within the network. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 (ImageLoaded = "*\\credui.dll" AND OriginalFileName @@ -61,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_installutil_credential_theft.yml b/detections/endpoint/windows_installutil_credential_theft.yml index 7def68636e..5445ac16f5 100644 --- a/detections/endpoint/windows_installutil_credential_theft.yml +++ b/detections/endpoint/windows_installutil_credential_theft.yml @@ -1,35 +1,29 @@ name: Windows InstallUtil Credential Theft id: ccfeddec-43ec-11ec-b494-acde48001122 -version: 4 -date: '2024-03-14' +version: 5 +date: '2024-05-18' author: Michael Haag, Mauricio Velazo, Splunk status: production type: TTP -description: This analytic identifies instances where the Windows InstallUtil.exe binary - loads `vaultcli.dll` and `Samlib.dll`. This technique can be employed to execute code - that bypasses application control and captures credentials using tools like - Mimikatz. - - When `InstallUtil.exe` is used maliciously, it typically specifies the path to an executable on - the filesystem. It is important to observe the parent process in such cases. Suspicious - activity often involves being spawned from non-standard processes such as `Cmd.exe`, `PowerShell.exe`, - or `Explorer.exe`. - - Conversely, when used by developers, it is usually accompanied by multiple command-line - switches/arguments and originates from Visual Studio. - - During triage, review any resulting network connections, file modifications, and concurrent - processes. Capture any artifacts for further review.' +description: The following analytic detects instances where the Windows InstallUtil.exe + binary loads `vaultcli.dll` and `Samlib.dll`. This detection leverages Sysmon EventCode + 7 to identify these specific DLL loads. This activity is significant because it + can indicate an attempt to execute code that bypasses application control and captures + credentials using tools like Mimikatz. If confirmed malicious, this behavior could + allow an attacker to steal credentials, potentially leading to unauthorized access + and further compromise of the system. data_source: - Sysmon EventID 7 -search: '`sysmon` EventCode=7 process_name=installutil.exe loaded_file_path IN ("*\\samlib.dll", "*\\vaultcli.dll") - | stats count min(_time) as firstTime max(_time) as lastTime by user_id, dest, process_name, loaded_file, loaded_file_path, original_file_name, process_guid - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_installutil_credential_theft_filter`' +search: '`sysmon` EventCode=7 process_name=installutil.exe loaded_file_path IN ("*\\samlib.dll", + "*\\vaultcli.dll") | stats count min(_time) as firstTime max(_time) as lastTime + by user_id, dest, process_name, loaded_file, loaded_file_path, original_file_name, + process_guid | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_installutil_credential_theft_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and module loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: Typically, this will not trigger because, by its very nature, InstallUtil - does not require credentials. Filter as needed. +known_false_positives: Typically, this will not trigger because, by its very nature, + InstallUtil does not require credentials. Filter as needed. references: - https://gist.github.com/xorrior/bbac3919ca2aef8d924bdf3b16cce3d0 tags: @@ -38,8 +32,8 @@ tags: asset_type: Endpoint confidence: 100 impact: 80 - message: An instance of process name [$process_name$] loading a file [$loaded_file$] was identified - on endpoint- [$dest$] to potentially capture credentials in memory. + message: An instance of process name [$process_name$] loading a file [$loaded_file$] + was identified on endpoint- [$dest$] to potentially capture credentials in memory. mitre_attack_id: - T1218.004 - T1218 @@ -74,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_installutil_remote_network_connection.yml b/detections/endpoint/windows_installutil_remote_network_connection.yml index 9b8a4cb900..b8d6a4dd73 100644 --- a/detections/endpoint/windows_installutil_remote_network_connection.yml +++ b/detections/endpoint/windows_installutil_remote_network_connection.yml @@ -1,24 +1,19 @@ name: Windows InstallUtil Remote Network Connection id: 4fbf9270-43da-11ec-9486-acde48001122 -version: 3 -date: '2023-11-07' +version: 4 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the Windows InstallUtil.exe binary - making a remote network connection. This technique may be used to download and execute - code while bypassing application control. - - When `InstallUtil.exe` is used in a malicous manner, the path to an executable on - the filesystem is typically specified. Take note of the parent process. In a suspicious - instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` - or `Explorer.exe`. - - If used by a developer, typically this will be found with multiple command-line - switches/arguments and spawn from Visual Studio. - - During triage review resulting network connections, file modifications, and parallel - processes. Capture any artifacts and review further.' +description: 'The following analytic detects the Windows InstallUtil.exe binary making + a remote network connection. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process and network telemetry. This activity is significant + because InstallUtil.exe can be exploited to download and execute malicious code, + bypassing application control mechanisms. If confirmed malicious, an attacker could + achieve code execution, potentially leading to further system compromise, data exfiltration, + or lateral movement within the network. Analysts should review the parent process, + network connections, and any associated file modifications to determine the legitimacy + of this activity.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes @@ -98,6 +93,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_installutil_uninstall_option.yml b/detections/endpoint/windows_installutil_uninstall_option.yml index 9dc72a2937..b9f187a954 100644 --- a/detections/endpoint/windows_installutil_uninstall_option.yml +++ b/detections/endpoint/windows_installutil_uninstall_option.yml @@ -1,36 +1,28 @@ name: Windows InstallUtil Uninstall Option id: cfa7b9ac-43f0-11ec-9b48-acde48001122 -version: 2 -date: '2024-04-29' +version: 3 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the Windows InstallUtil.exe binary. - This will execute code while bypassing application control using the `/u` (uninstall) - switch. - - InstallUtil uses the functions install and uninstall within the System.Configuration.Install - namespace to process .net assembly. Install function requires admin privileges, - however, uninstall function can be run as an unprivileged user. - - When `InstallUtil.exe` is used in a malicous manner, the path to an executable on - the filesystem is typically specified. Take note of the parent process. In a suspicious - instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` - or `Explorer.exe`. - - If used by a developer, typically this will be found with multiple command-line - switches/arguments and spawn from Visual Studio. - - During triage review resulting network connections, file modifications, and parallel - processes. Capture any artifacts and review further.' +description: 'The following analytic detects the use of the Windows InstallUtil.exe + binary with the `/u` (uninstall) switch, which can execute code while bypassing + application control. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names, parent processes, and command-line executions. + This activity is significant because it can indicate an attempt to execute malicious + code without administrative privileges. If confirmed malicious, an attacker could + achieve code execution, potentially leading to further system compromise or persistence + within the environment.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_installutil` Processes.process - IN ("*/u*", "*uninstall*") NOT (Processes.process IN ("*C:\\WINDOWS\\CCM\\*")) NOT (Processes.parent_process_name IN ("Microsoft.SharePoint.Migration.ClientInstaller.exe")) by Processes.dest Processes.user Processes.parent_process_name - Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `windows_installutil_uninstall_option_filter`' + IN ("*/u*", "*uninstall*") NOT (Processes.process IN ("*C:\\WINDOWS\\CCM\\*")) NOT + (Processes.parent_process_name IN ("Microsoft.SharePoint.Migration.ClientInstaller.exe")) + by Processes.dest Processes.user Processes.parent_process_name Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `windows_installutil_uninstall_option_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -97,6 +89,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_installutil_uninstall_option_with_network.yml b/detections/endpoint/windows_installutil_uninstall_option_with_network.yml index 876e8d5d55..39c7259c94 100644 --- a/detections/endpoint/windows_installutil_uninstall_option_with_network.yml +++ b/detections/endpoint/windows_installutil_uninstall_option_with_network.yml @@ -1,39 +1,30 @@ name: Windows InstallUtil Uninstall Option with Network id: 1a52c836-43ef-11ec-a36c-acde48001122 -version: 2 -date: '2022-03-16' +version: 3 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the Windows InstallUtil.exe binary - making a remote network connection. This technique may be used to download and execute - code while bypassing application control using the `/u` (uninstall) switch. - - InstallUtil uses the functions install and uninstall within the System.Configuration.Install - namespace to process .net assembly. Install function requires admin privileges, - however, uninstall function can be run as an unprivileged user. - - When `InstallUtil.exe` is used in a malicous manner, the path to an executable on - the filesystem is typically specified. Take note of the parent process. In a suspicious - instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` - or `Explorer.exe`. - - If used by a developer, typically this will be found with multiple command-line - switches/arguments and spawn from Visual Studio. - - During triage review resulting network connections, file modifications, and parallel - processes. Capture any artifacts and review further.' +description: 'The following analytic identifies the use of Windows InstallUtil.exe + making a remote network connection using the `/u` (uninstall) switch. This detection + leverages Endpoint Detection and Response (EDR) telemetry, focusing on process and + network activity data. This behavior is significant as it may indicate an attempt + to download and execute code while bypassing application control mechanisms. If + confirmed malicious, this activity could allow an attacker to execute arbitrary + code, potentially leading to system compromise, data exfiltration, or further lateral + movement within the network.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where `process_installutil` Processes.process IN ("*/u*", "*uninstall*") by _time - span=1h Processes.user Processes.process_id Processes.process_name Processes.dest Processes.process_path - Processes.process Processes.parent_process_name | `drop_dm_object_name(Processes)` + span=1h Processes.user Processes.process_id Processes.process_name Processes.dest + Processes.process_path Processes.process Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | join process_id [| tstats `security_content_summariesonly` count FROM datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port != 0 by All_Traffic.process_id All_Traffic.dest All_Traffic.dest_port - | `drop_dm_object_name(All_Traffic)` | rename dest as C2 ] | table _time user dest parent_process_name - process_name process_path process process_id dest_port C2 | `windows_installutil_uninstall_option_with_network_filter`' + | `drop_dm_object_name(All_Traffic)` | rename dest as C2 ] | table _time user dest + parent_process_name process_name process_path process process_id dest_port C2 | + `windows_installutil_uninstall_option_with_network_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -104,6 +95,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_installutil_url_in_command_line.yml b/detections/endpoint/windows_installutil_url_in_command_line.yml index fc3a536b83..ca9b2147fd 100644 --- a/detections/endpoint/windows_installutil_url_in_command_line.yml +++ b/detections/endpoint/windows_installutil_url_in_command_line.yml @@ -1,24 +1,18 @@ name: Windows InstallUtil URL in Command Line id: 28e06670-43df-11ec-a569-acde48001122 -version: 1 -date: '2021-11-12' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic identifies the Windows InstallUtil.exe binary - passing a HTTP request on the command-line. This technique may be used to download - and execute code while bypassing application control. - - When `InstallUtil.exe` is used in a malicous manner, the path to an executable on - the filesystem is typically specified. Take note of the parent process. In a suspicious - instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` - or `Explorer.exe`. - - If used by a developer, typically this will be found with multiple command-line - switches/arguments and spawn from Visual Studio. - - During triage review resulting network connections, file modifications, and parallel - processes. Capture any artifacts and review further.' +description: 'The following analytic detects the use of Windows InstallUtil.exe with + an HTTP or HTTPS URL in the command line. This is identified through Endpoint Detection + and Response (EDR) telemetry, focusing on command-line executions containing URLs. + This activity is significant as it may indicate an attempt to download and execute + malicious code, potentially bypassing application control mechanisms. If confirmed + malicious, this could lead to unauthorized code execution, privilege escalation, + or persistent access within the environment. Analysts should review the parent process, + network connections, file modifications, and related processes for further investigation.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -93,6 +87,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.004/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_iso_lnk_file_creation.yml b/detections/endpoint/windows_iso_lnk_file_creation.yml index 6f68708f81..182d927f4a 100644 --- a/detections/endpoint/windows_iso_lnk_file_creation.yml +++ b/detections/endpoint/windows_iso_lnk_file_creation.yml @@ -1,15 +1,17 @@ name: Windows ISO LNK File Creation id: d7c2c09b-9569-4a9e-a8b6-6a39a99c1d32 -version: 2 -date: '2022-09-19' +version: 3 +date: '2024-05-09' author: Michael Haag, Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies the use of a delivered ISO file that - has been mounted and the afformention lnk or file opened within it. When the ISO - file is opened, the files are saved in the %USER%\AppData\Local\Temp\\ path. The analytic identifies .iso.lnk written to the path. The name of the - ISO file is prepended. +description: The following analytic detects the creation of .iso.lnk files in the + %USER%\AppData\Local\Temp\\ path, indicating that an ISO file + has been mounted and accessed. This detection leverages the Endpoint.Filesystem + data model, specifically monitoring file creation events in the Windows Recent folder. + This activity is significant as it may indicate the delivery and execution of potentially + malicious payloads via ISO files. If confirmed malicious, this could lead to unauthorized + code execution, data exfiltration, or further system compromise. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.001/atomic_red_team/iso_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.001/atomic_red_team/iso_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_java_spawning_shells.yml b/detections/endpoint/windows_java_spawning_shells.yml index 29ef727da7..78910c722e 100644 --- a/detections/endpoint/windows_java_spawning_shells.yml +++ b/detections/endpoint/windows_java_spawning_shells.yml @@ -1,15 +1,17 @@ name: Windows Java Spawning Shells id: 28c81306-5c47-11ec-bfea-acde48001122 -version: 2 -date: '2023-01-23' +version: 3 +date: '2024-05-11' author: Michael Haag, Splunk status: experimental type: TTP -description: The following analytic identifies the process name of java.exe and w3wp.exe - spawning a Windows shell. This is potentially indicative of exploitation of the - Java application and may be related to current event CVE-2021-44228 (Log4Shell). - The shells included in the macro are "cmd.exe", "powershell.exe". Upon triage, review - parallel processes and command-line arguments to determine legitimacy. +description: The following analytic identifies instances where java.exe or w3wp.exe + spawns a Windows shell, such as cmd.exe or powershell.exe. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process and + parent process relationships. This activity is significant as it may indicate exploitation + attempts, such as those related to CVE-2021-44228 (Log4Shell). If confirmed malicious, + attackers could execute arbitrary commands, potentially leading to system compromise, + data exfiltration, or further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/windows_kerberos_local_successful_logon.yml b/detections/endpoint/windows_kerberos_local_successful_logon.yml index 9781f363dc..5b28939ffb 100644 --- a/detections/endpoint/windows_kerberos_local_successful_logon.yml +++ b/detections/endpoint/windows_kerberos_local_successful_logon.yml @@ -1,22 +1,24 @@ name: Windows Kerberos Local Successful Logon id: 8309c3a8-4d34-48ae-ad66-631658214653 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP description: The following analytic identifies a local successful authentication event - on a Windows endpoint using the Kerberos package. The target user security identified - will be set to the built-in local Administrator account, along with the remote address - as localhost - 127.0.0.1. This may be indicative of a kerberos relay attack. Upon - triage, review for recently ran binaries on disk. In addition, look for new computer - accounts added to Active Directory and other anomolous AD events. + on a Windows endpoint using the Kerberos package. It detects EventCode 4624 with + LogonType 3 and source address 127.0.0.1, indicating a login to the built-in local + Administrator account. This activity is significant as it may suggest a Kerberos + relay attack, a method attackers use to escalate privileges. If confirmed malicious, + this could allow an attacker to gain unauthorized access to sensitive systems, execute + arbitrary code, or create new accounts in Active Directory, leading to potential + system compromise. data_source: - Windows Event Log Security 4624 search: '`wineventlog_security` EventCode=4624 LogonType=3 AuthenticationPackageName=Kerberos - action=success src=127.0.0.1 | stats count min(_time) as firstTime max(_time) - as lastTime by dest, subject, action, SubjectLogonId, user, TargetUserName, src | - `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_kerberos_local_successful_logon_filter`' + action=success src=127.0.0.1 | stats count min(_time) as firstTime max(_time) as + lastTime by dest, subject, action, SubjectLogonId, user, TargetUserName, src | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_kerberos_local_successful_logon_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4624 EventCode enabled. The Windows TA is also required. @@ -58,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/windows_kerberos_local_successful_logon/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558/windows_kerberos_local_successful_logon/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_known_abused_dll_created.yml b/detections/endpoint/windows_known_abused_dll_created.yml index 9756ab67c6..b8eb9d459e 100644 --- a/detections/endpoint/windows_known_abused_dll_created.yml +++ b/detections/endpoint/windows_known_abused_dll_created.yml @@ -1,36 +1,51 @@ name: Windows Known Abused DLL Created id: ea91651a-772a-4b02-ac3d-985b364a5f07 -version: 1 -date: '2024-02-19' +version: 2 +date: '2024-05-17' author: Steven Dick status: production type: Anomaly -description: This analytic is designed to identify instances where Dynamic Link Libraries (DLLs) with a known history of being exploited are created in locations that are not typical for their use. This could indicate that an attacker is attempting to exploit the DLL search order hijacking or sideloading techniques. DLL search order hijacking involves tricking an application into loading a malicious DLL instead of the legitimate one it was intending to load. This is often achieved by placing the malicious DLL in a directory that is searched before the directory containing the legitimate DLL. Sideloading, similarly, involves placing a malicious DLL with the same name as a legitimate DLL that an application is known to load, in a location that the application will search before finding the legitimate version. Both of these techniques can be used by attackers to execute arbitrary code, maintain persistence on a system, and potentially elevate their privileges, all while appearing as legitimate operations to the untrained eye. This analytic aims to shed light on such suspicious activities by monitoring for the creation of known abused DLLs in unconventional locations, thereby helping in the early detection of these stealthy attack techniques. +description: The following analytic identifies the creation of Dynamic Link Libraries + (DLLs) with a known history of exploitation in atypical locations. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process and + filesystem events. This activity is significant as it may indicate DLL search order + hijacking or sideloading, techniques used by attackers to execute arbitrary code, + maintain persistence, or escalate privileges. If confirmed malicious, this activity + could allow attackers to blend in with legitimate operations, posing a severe threat + to system integrity and security. data_source: - Sysmon EventID 1 - Sysmon EventID 11 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.parent_process_name!="unknown" Processes.process_name=* Processes.process_guid!=null by _time span=1h Processes.dest Processes.user Processes.process_guid Processes.process_name Processes.process Processes.parent_process Processes.parent_process_name - | `drop_dm_object_name(Processes)` - | join max=0 process_guid dest - [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\users\\*","*\\Windows\Temp\\*","*\\programdata\\*") Filesystem.file_name="*.dll" by _time span=1h Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path Filesystem.process_guid - | `drop_dm_object_name(Filesystem)` - | lookup hijacklibs_loaded library AS file_name OUTPUT islibrary, ttp, comment as desc - | lookup hijacklibs_loaded library AS file_name excludes as file_path OUTPUT islibrary as excluded - | search islibrary = TRUE AND excluded != TRUE - | stats latest(*) as * by dest process_guid ] - | where isnotnull(file_name) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_known_abused_dll_created_filter`' +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime FROM datamodel=Endpoint.Processes where Processes.parent_process_name!="unknown" + Processes.process_name=* Processes.process_guid!=null by _time span=1h Processes.dest + Processes.user Processes.process_guid Processes.process_name Processes.process Processes.parent_process + Processes.parent_process_name | `drop_dm_object_name(Processes)` | join max=0 process_guid + dest [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Filesystem + where Filesystem.file_path IN ("*\\users\\*","*\\Windows\Temp\\*","*\\programdata\\*") + Filesystem.file_name="*.dll" by _time span=1h Filesystem.dest Filesystem.file_create_time + Filesystem.file_name Filesystem.file_path Filesystem.process_guid | `drop_dm_object_name(Filesystem)` + | lookup hijacklibs_loaded library AS file_name OUTPUT islibrary, ttp, comment as + desc | lookup hijacklibs_loaded library AS file_name excludes as file_path OUTPUT + islibrary as excluded | search islibrary = TRUE AND excluded != TRUE | stats latest(*) + as * by dest process_guid ] | where isnotnull(file_name) | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_known_abused_dll_created_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to - the EDR product. The logs must also be mapped to the `Processes` and `Filesystem` nodes of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field - names and speed up the data modeling process. -known_false_positives: This analytic may flag instances where DLLs are loaded by user mode programs for entirely legitimate and benign purposes. It is important for users to be aware that false positives are not only possible but likely, and that careful tuning of this analytic is necessary to distinguish between malicious activity and normal, everyday operations of applications. This may involve adjusting thresholds, whitelisting known good software, or incorporating additional context from other security tools and logs to reduce the rate of false positives. + the EDR product. The logs must also be mapped to the `Processes` and `Filesystem` + nodes of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) + to normalize the field names and speed up the data modeling process. +known_false_positives: This analytic may flag instances where DLLs are loaded by user + mode programs for entirely legitimate and benign purposes. It is important for users + to be aware that false positives are not only possible but likely, and that careful + tuning of this analytic is necessary to distinguish between malicious activity and + normal, everyday operations of applications. This may involve adjusting thresholds, + whitelisting known good software, or incorporating additional context from other + security tools and logs to reduce the rate of false positives. references: - https://attack.mitre.org/techniques/T1574/002/ - https://hijacklibs.net/api/ @@ -43,7 +58,8 @@ tags: asset_type: Endpoint confidence: 25 impact: 40 - message: The file [$file_name$] was written to an unusual location by [$process_name$] on [$dest$]. + message: The file [$file_name$] was written to an unusual location by [$process_name$] + on [$dest$]. mitre_attack_id: - T1574.001 - T1574.002 @@ -88,6 +104,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/hijacklibs/hijacklibs_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/hijacklibs/hijacklibs_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_known_graphicalproton_loaded_modules.yml b/detections/endpoint/windows_known_graphicalproton_loaded_modules.yml index 5e9f560982..ab871bc23d 100644 --- a/detections/endpoint/windows_known_graphicalproton_loaded_modules.yml +++ b/detections/endpoint/windows_known_graphicalproton_loaded_modules.yml @@ -1,20 +1,27 @@ name: Windows Known GraphicalProton Loaded Modules id: bf471c94-0324-4b19-a113-d02749b969bc -version: 1 -date: '2023-12-18' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 7 -description: The following analytic identifies a potential suspicious process loading dll modules related to Graphicalproton backdoor implant of SVR. - These DLL modules have been observed in SVR attacks, commonly used to install backdoors on targeted hosts. - This anomaly detection highlights the need for thorough investigation and immediate mitigation measures to safeguard the network against potential breaches. -search: '`sysmon` EventCode=7 - ImageLoaded IN ("*\\AclNumsInvertHost.dll", "*\\ModeBitmapNumericAnimate.dll", "*\\UnregisterAncestorAppendAuto.dll", "*\\DeregisterSeekUsers.dll", "*\\ScrollbarHandleGet.dll", "*\\PerformanceCaptionApi.dll", "*\\WowIcmpRemoveReg.dll", "*\\BlendMonitorStringBuild.dll", "*\\HandleFrequencyAll.dll", "*\\HardSwapColor.dll", "*\\LengthInMemoryActivate.dll", "*\\ParametersNamesPopup.dll", "*\\ModeFolderSignMove.dll", "*\\ChildPaletteConnected.dll", "*\\AddressResourcesSpec.dll") - | stats count min(_time) as firstTime max(_time) as lastTime by Image ImageLoaded process_name dest EventCode Signed ProcessId Hashes IMPHASH - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the loading of DLL modules associated + with the GraphicalProton backdoor implant, commonly used by SVR in targeted attacks. + It leverages Sysmon EventCode 7 to identify specific DLLs loaded by processes. This + activity is significant as it may indicate the presence of a sophisticated backdoor, + warranting immediate investigation. If confirmed malicious, the attacker could gain + persistent access to the compromised host, potentially leading to further exploitation + and data exfiltration. +search: '`sysmon` EventCode=7 ImageLoaded IN ("*\\AclNumsInvertHost.dll", "*\\ModeBitmapNumericAnimate.dll", + "*\\UnregisterAncestorAppendAuto.dll", "*\\DeregisterSeekUsers.dll", "*\\ScrollbarHandleGet.dll", + "*\\PerformanceCaptionApi.dll", "*\\WowIcmpRemoveReg.dll", "*\\BlendMonitorStringBuild.dll", + "*\\HandleFrequencyAll.dll", "*\\HardSwapColor.dll", "*\\LengthInMemoryActivate.dll", + "*\\ParametersNamesPopup.dll", "*\\ModeFolderSignMove.dll", "*\\ChildPaletteConnected.dll", + "*\\AddressResourcesSpec.dll") | stats count min(_time) as firstTime max(_time) + as lastTime by Image ImageLoaded process_name dest EventCode Signed ProcessId Hashes + IMPHASH | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_known_graphicalproton_loaded_modules_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you @@ -57,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/svr_loaded_modules/loaded_module_svr.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/svr_loaded_modules/loaded_module_svr.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_large_number_of_computer_service_tickets_requested.yml b/detections/endpoint/windows_large_number_of_computer_service_tickets_requested.yml index 60135966dc..cb6ced8840 100644 --- a/detections/endpoint/windows_large_number_of_computer_service_tickets_requested.yml +++ b/detections/endpoint/windows_large_number_of_computer_service_tickets_requested.yml @@ -1,32 +1,31 @@ name: Windows Large Number of Computer Service Tickets Requested id: 386ad394-c9a7-4b4f-b66f-586252de20f0 -version: 1 -date: '2023-03-20' +version: 2 +date: '2024-05-11' author: Mauricio Velazco, Splunk type: Anomaly status: production data_source: - Windows Event Log Security 4769 -description: The following analytic leverages Event ID 4769, `A Kerberos - service ticket was requested`, to identify more than 30 computer service - ticket requests from one source. When a domain joined endpoint connects to other remote - endpoint, it will first request a Kerberos Service Ticket with the computer name as the - Service Name. A user requesting a large number of computer service tickets - for different endpoints could represent malicious behavior like lateral movement, - malware staging, reconnaissance, etc. - - Active Directory environments can be very different depending on the organization. Users should test this detection and customize - the arbitrary threshold as needed. +description: The following analytic detects a high volume of Kerberos service ticket + requests, specifically more than 30, from a single source within a 5-minute window. + It leverages Event ID 4769, which logs when a Kerberos service ticket is requested, + focusing on requests with computer names as the Service Name. This behavior is significant + as it may indicate malicious activities such as lateral movement, malware staging, + or reconnaissance. If confirmed malicious, an attacker could gain unauthorized access + to multiple endpoints, potentially compromising the entire network. search: ' `wineventlog_security` EventCode=4769 ServiceName="*$" TargetUserName!="*$" - | bucket span=5m _time - | stats dc(ServiceName) AS unique_targets values(ServiceName) as host_targets by _time, IpAddress, TargetUserName - | where unique_targets > 30 + | bucket span=5m _time | stats dc(ServiceName) AS unique_targets values(ServiceName) + as host_targets by _time, IpAddress, TargetUserName | where unique_targets > 30 | `windows_large_number_of_computer_service_tickets_requested_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. - The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. -known_false_positives: An single endpoint requesting a large number of kerberos service tickets is not common behavior. - Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems. +how_to_implement: To successfully implement this search, you need to be ingesting + Domain Controller and Kerberos events. The Advanced Security Audit policy setting + `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. +known_false_positives: An single endpoint requesting a large number of kerberos service + tickets is not common behavior. Possible false positive scenarios include but are + not limited to vulnerability scanners, administration systems and missconfigured + systems. references: - https://thedfirreport.com/2023/01/23/sharefinder-how-threat-actors-discover-file-shares/ - https://attack.mitre.org/techniques/T1135/ @@ -38,7 +37,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 60 - message: A large number of kerberos computer service tickets were requested by $IpAddress$ within 5 minutes. + message: A large number of kerberos computer service tickets were requested by $IpAddress$ + within 5 minutes. mitre_attack_id: - T1135 - T1078 @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/large_number_computer_service_tickets/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/large_number_computer_service_tickets/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_ldifde_directory_object_behavior.yml b/detections/endpoint/windows_ldifde_directory_object_behavior.yml index 023ba90cd0..a233880855 100644 --- a/detections/endpoint/windows_ldifde_directory_object_behavior.yml +++ b/detections/endpoint/windows_ldifde_directory_object_behavior.yml @@ -1,32 +1,20 @@ name: Windows Ldifde Directory Object Behavior id: 35cd29ca-f08c-4489-8815-f715c45460d3 -version: 1 -date: '2023-05-25' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies the use of Ldifde.exe, which provides - the ability to create, modify, or delete LDAP directory objects. Natively, the binary - is only installed on a domain controller. However, adversaries or administrators - may install the Windows Remote Server Admin Tools for ldifde.exe. Ldifde.exe is - a Microsoft Windows command-line utility used to import or export LDAP directory - entries. LDAP stands for Lightweight Directory Access Protocol, which is a protocol - used for accessing and managing directory information services over an IP network. - LDIF, on the other hand, stands for LDAP Data Interchange Format, a standard plain-text - data interchange format for representing LDAP directory entries. -i This is a flag - used with Ldifde.exe to denote import mode. In import mode, Ldifde.exe takes an - LDIF file and imports its contents into the LDAP directory. The data in the LDIF - file might include new objects to be created, or modifications or deletions to existing - objects. -f This flag is used to specify the filename of the LDIF file that Ldifde.exe - will import from (in the case of the -i flag) or export to (without the -i flag). - For example, if you wanted to import data from a file called data.ldif, you would - use the command ldifde -i -f data.ldif. Keep in mind that while the use of Ldifde.exe - is legitimate in many contexts, it can also be used maliciously. For instance, an - attacker who has gained access to a domain controller could potentially use Ldifde.exe - to export sensitive data or make unauthorized changes to the directory. Therefore, - it's important to monitor for unusual or unauthorized use of this tool. +description: The following analytic identifies the use of Ldifde.exe, a command-line + utility for creating, modifying, or deleting LDAP directory objects. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + execution and command-line arguments. Monitoring Ldifde.exe is significant because + it can be used by attackers to manipulate directory objects, potentially leading + to unauthorized changes or data exfiltration. If confirmed malicious, this activity + could allow an attacker to gain control over directory services, escalate privileges, + or access sensitive information within the network. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=ldifde.exe Processes.process IN ("*-i *", "*-f *") by Processes.dest Processes.user Processes.parent_process_name @@ -100,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/ldifde_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.002/AD_discovery/ldifde_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_linked_policies_in_adsi_discovery.yml b/detections/endpoint/windows_linked_policies_in_adsi_discovery.yml index 8736ccad8a..881d251a75 100644 --- a/detections/endpoint/windows_linked_policies_in_adsi_discovery.yml +++ b/detections/endpoint/windows_linked_policies_in_adsi_discovery.yml @@ -1,23 +1,25 @@ name: Windows Linked Policies In ADSI Discovery id: 510ea428-4731-4d2f-8829-a28293e427aa -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the `[Adsisearcher]` type accelerator being used to query Active Directory - for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate - domain organizational unit for situational awareness and Active Directory Discovery. +description: The following analytic detects the use of the `[Adsisearcher]` type accelerator + in PowerShell Script Block Logging (EventCode=4104) to query Active Directory for + domain organizational units. This detection leverages PowerShell operational logs + to identify script blocks containing `[adsisearcher]`, `objectcategory=organizationalunit`, + and `findAll()`. This activity is significant as it indicates potential reconnaissance + efforts by adversaries to gain situational awareness of the domain structure. If + confirmed malicious, this could lead to further exploitation, such as privilege + escalation or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*[adsisearcher]*" ScriptBlockText = "*objectcategory=organizationalunit*" ScriptBlockText = "*findAll()*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer user_id - | rename Computer as dest, user_id as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_linked_policies_in_adsi_discovery_filter`' + Computer user_id | rename Computer as dest, user_id as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_linked_policies_in_adsi_discovery_filter`' how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. @@ -57,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/adsi_discovery/windows-powershell-xml2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/adsi_discovery/windows-powershell-xml2.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_local_administrator_credential_stuffing.yml b/detections/endpoint/windows_local_administrator_credential_stuffing.yml index 56e0950d64..87560c5f9e 100644 --- a/detections/endpoint/windows_local_administrator_credential_stuffing.yml +++ b/detections/endpoint/windows_local_administrator_credential_stuffing.yml @@ -1,27 +1,31 @@ name: Windows Local Administrator Credential Stuffing id: 09555511-aca6-484a-b6ab-72cd03d73c34 -version: 1 -date: '2023-03-22' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 4624 - Windows Event Log Security 4625 -description: The following analytic leverages events 4625 and 4624 to identify an endpoint using the builtin local Administrator account to authenticate to a large numbers of endpoints. Specifically, - the logic will trigger when an endpoints attempts to authenticate to more than 30 target computers within a 5 minute timespan. This behavior could - represent an adversary who has obtained access to local credentials and is trying to validate if these credentials work on other hosts to escalate their privileges. - As environments differ across organizations, security teams should customize the thresholds of this detection as needed. +description: The following analytic detects attempts to authenticate using the built-in + local Administrator account across more than 30 endpoints within a 5-minute window. + It leverages Windows Event Logs, specifically events 4625 and 4624, to identify + this behavior. This activity is significant as it may indicate an adversary attempting + to validate stolen local credentials across multiple hosts, potentially leading + to privilege escalation. If confirmed malicious, this could allow the attacker to + gain widespread access and control over numerous systems within the network, posing + a severe security risk. search: ' `wineventlog_security` EventCode=4625 OR EventCode=4624 Logon_Type=3 TargetUserName=Administrator - | bucket span=5m _time - | stats dc(Computer) AS unique_targets values(Computer) as host_targets by _time, IpAddress, TargetUserName, EventCode - | where unique_targets > 30 - | `windows_local_administrator_credential_stuffing_filter`' + | bucket span=5m _time | stats dc(Computer) AS unique_targets values(Computer) as + host_targets by _time, IpAddress, TargetUserName, EventCode | where unique_targets + > 30 | `windows_local_administrator_credential_stuffing_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. -known_false_positives: Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed. +known_false_positives: Vulnerability scanners or system administration tools may also + trigger this detection. Filter as needed. references: - https://attack.mitre.org/techniques/T1110/004/ - https://attack.mitre.org/techniques/T1110/ @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.004/local_administrator_cred_stuffing/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.004/local_administrator_cred_stuffing/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_lsa_secrets_nolmhash_registry.yml b/detections/endpoint/windows_lsa_secrets_nolmhash_registry.yml index 716b6b9141..828e00bf9e 100644 --- a/detections/endpoint/windows_lsa_secrets_nolmhash_registry.yml +++ b/detections/endpoint/windows_lsa_secrets_nolmhash_registry.yml @@ -1,29 +1,27 @@ name: Windows LSA Secrets NoLMhash Registry id: 48cc1605-538c-4223-8382-e36bee5b540d -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry related to the Local Security Authority (LSA) in Windows. - This registry value is used to determine whether the system should store passwords in the weaker Lan Manager (LM) hash format. - Setting it to 0 disables this feature, meaning LM hashes will be stored. - Modifying these settings should be done carefully and with a clear understanding of the impact it might have on system security and functionality. - This command is often used in security configurations to enforce stronger password storage methods and prevent the storage of weaker LM hashes, - which are more susceptible to certain types of attacks. - This TTP detection can be a good indicator of any process or user that tries to modify the LSA security configuration. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry +description: The following analytic detects modifications to the Windows registry + related to the Local Security Authority (LSA) NoLMHash setting. It identifies when + the registry value is set to 0, indicating that the system will store passwords + in the weaker Lan Manager (LM) hash format. This detection leverages registry activity + logs from endpoint data sources like Sysmon or EDR tools. Monitoring this activity + is crucial as it can indicate attempts to weaken password storage security. If confirmed + malicious, this could allow attackers to exploit weaker LM hashes, potentially leading + to unauthorized access and credential theft. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\System\\CurrentControlSet\\Control\\Lsa\\NoLMHash" - Registry.registry_value_data = 0x00000000) - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_lsa_secrets_nolmhash_registry_filter`' + Registry.registry_value_data = 0x00000000) BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_lsa_secrets_nolmhash_registry_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 @@ -65,12 +63,13 @@ tags: - Registry.user - Registry.dest - Registry.action - - Registry.registry_value_data - - Registry.process_guid + - Registry.registry_value_data + - Registry.process_guid security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.004/NoLMHash/lsa-reg-settings-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.004/NoLMHash/lsa-reg-settings-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_mail_protocol_in_non_common_process_path.yml b/detections/endpoint/windows_mail_protocol_in_non_common_process_path.yml index 8b55fbde6c..c56ab5a29f 100644 --- a/detections/endpoint/windows_mail_protocol_in_non_common_process_path.yml +++ b/detections/endpoint/windows_mail_protocol_in_non_common_process_path.yml @@ -1,16 +1,18 @@ name: Windows Mail Protocol In Non-Common Process Path id: ac3311f5-661d-4e99-bd1f-3ec665b05441 -version: 1 -date: '2022-09-16' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a possible windows application having - a SMTP connection in a non common installation path in windows operating system.This - network protocol is being used by adversaries, threat actors and malware like AgentTesla - as a Command And Control communication to transfer its collected stolen information - like the desktop screenshots, browser information and system information of a targeted - or compromised host. +description: The following analytic detects a Windows application establishing an + SMTP connection from a non-common installation path. It leverages Sysmon EventCode + 3 to identify processes not typically associated with email clients (e.g., Thunderbird, + Outlook) making SMTP connections. This activity is significant as adversaries, including + malware like AgentTesla, use such connections for Command and Control (C2) communication + to exfiltrate stolen data. If confirmed malicious, this behavior could lead to unauthorized + data exfiltration, including sensitive information like desktop screenshots, browser + data, and system details, compromising the affected host. data_source: - Sysmon EventID 3 search: '`sysmon` EventCode=3 NOT(Image IN("*\\program files*", "*\\thunderbird.exe","*\\outlook.exe")) @@ -65,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_smtp/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_smtp/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_mark_of_the_web_bypass.yml b/detections/endpoint/windows_mark_of_the_web_bypass.yml index ca3c493988..fd2f47ba7b 100644 --- a/detections/endpoint/windows_mark_of_the_web_bypass.yml +++ b/detections/endpoint/windows_mark_of_the_web_bypass.yml @@ -1,23 +1,26 @@ name: Windows Mark Of The Web Bypass id: 8ca13343-7405-4916-a2d1-ae34ce0c28ae -version: 1 -date: '2023-08-14' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 23 -description: The following analytic identifies a suspicious process that delete mark-of-the-web data stream. - This technique has been observed in various instances of malware and adversarial activities aimed at circumventing - security restrictions within the Windows Operating System, particularly pertaining to files downloaded from the internet. - An example of this scenario is demonstrated by Ave Maria RAT, which attempts to delete this data stream as a means to evade such restrictions. -search: '`sysmon` EventCode=23 TargetFilename = "*:Zone.Identifier" - | stats min(_time) as firstTime max(_time) as lastTime count by user EventCode Image TargetFilename ProcessID dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies a suspicious process that deletes the + Mark-of-the-Web (MOTW) data stream. It leverages Sysmon EventCode 23 to detect when + a file's Zone.Identifier stream is removed. This activity is significant because + it is a common technique used by malware, such as Ave Maria RAT, to bypass security + restrictions on files downloaded from the internet. If confirmed malicious, this + behavior could allow an attacker to execute potentially harmful files without triggering + security warnings, leading to further compromise of the system. +search: '`sysmon` EventCode=23 TargetFilename = "*:Zone.Identifier" | stats min(_time) + as firstTime max(_time) as lastTime count by user EventCode Image TargetFilename + ProcessID dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_mark_of_the_web_bypass_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting logs with the deleted target file name, - process name and process id from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. +how_to_implement: To successfully implement this search, you need to be ingesting + logs with the deleted target file name, process name and process id from your endpoints. + If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. known_false_positives: unknown references: - https://attack.mitre.org/techniques/T1553/005/ @@ -57,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.005/mark_of_the_web_bypass/possible-motw-deletion.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.005/mark_of_the_web_bypass/possible-motw-deletion.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_masquerading_explorer_as_child_process.yml b/detections/endpoint/windows_masquerading_explorer_as_child_process.yml index 04ff87019e..6e1ff979c3 100644 --- a/detections/endpoint/windows_masquerading_explorer_as_child_process.yml +++ b/detections/endpoint/windows_masquerading_explorer_as_child_process.yml @@ -1,25 +1,27 @@ name: Windows Masquerading Explorer As Child Process id: 61490da9-52a1-4855-a0c5-28233c88c481 -version: 1 -date: '2024-04-25' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a suspicious parent process of explorer.exe. - Explorer is usually executed by userinit.exe that will exit after execution that - causes the main explorer.exe no parent process. Some malware like qakbot spawn another - explorer.exe to inject its code. This TTP detection is a good indicator that a process - spawning explorer.exe might inject code or masquerading its parent child process - to evade detections. +description: The following analytic identifies instances where explorer.exe is spawned + by unusual parent processes such as cmd.exe, powershell.exe, or regsvr32.exe. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process and parent process relationships. This activity is significant because + explorer.exe is typically initiated by userinit.exe, and deviations from this norm + can indicate code injection or process masquerading attempts by malware like Qakbot. + If confirmed malicious, this behavior could allow attackers to execute arbitrary + code, evade detection, and maintain persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name - IN("cmd.exe", "powershell.exe", "regsvr32.exe") AND Processes.process_name = "explorer.exe" AND Processes.process IN ("*\\explorer.exe") - by Processes.parent_process Processes.parent_process_name Processes.process_name - Processes.process_id Processes.process_guid Processes.process Processes.user Processes.dest - Processes.parent_process_id | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` - |`security_content_ctime(lastTime)` | `windows_masquerading_explorer_as_child_process_filter`' + IN("cmd.exe", "powershell.exe", "regsvr32.exe") AND Processes.process_name = "explorer.exe" + AND Processes.process IN ("*\\explorer.exe") by Processes.parent_process Processes.parent_process_name + Processes.process_name Processes.process_id Processes.process_guid Processes.process + Processes.user Processes.dest Processes.parent_process_id | `drop_dm_object_name("Processes")` + | `security_content_ctime(firstTime)` |`security_content_ctime(lastTime)` | `windows_masquerading_explorer_as_child_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_masquerading_msdtc_process.yml b/detections/endpoint/windows_masquerading_msdtc_process.yml index f7e032f976..a71d52bf86 100644 --- a/detections/endpoint/windows_masquerading_msdtc_process.yml +++ b/detections/endpoint/windows_masquerading_msdtc_process.yml @@ -1,27 +1,26 @@ name: Windows Masquerading Msdtc Process id: 238f3a07-8440-480b-b26f-462f41d9a47c -version: 1 -date: '2023-11-21' +version: 2 +date: '2024-05-19' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a suspicious msdtc.exe with specific command-line parameters, particularly -a or -b, - which are regarded as potential indicators of the presence of the insidious PlugX malware. This malware is notorious for its covert - operations and is frequently utilized by threat actors for unauthorized access, data exfiltration, and espionage. - The analytic's focus on the -a or -b command-line parameters within msdtc.exe is rooted in the PlugX malware's sophisticated tactic - of masquerading its activities. To elude detection, PlugX employs a technique where it injects a concealed, - headless PlugX Dynamic Link Library (DLL) module into the legitimate msdtc.exe process. By leveraging these - specific command-line parameters, the malware attempts to disguise its presence within a system's legitimate processes, - thereby evading immediate suspicion. -search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name = "msdtc.exe" Processes.process = "*msdtc.exe*" Processes.process IN ("* -a*", "* -b*") - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.original_file_name - Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the execution of msdtc.exe with specific + command-line parameters (-a or -b), which are indicative of the PlugX malware. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments. This activity is significant because + PlugX uses these parameters to masquerade its malicious operations within legitimate + processes, making it harder to detect. If confirmed malicious, this behavior could + allow attackers to gain unauthorized access, exfiltrate data, and conduct espionage, + severely compromising the affected system. +search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name = "msdtc.exe" + Processes.process = "*msdtc.exe*" Processes.process IN ("* -a*", "* -b*") by Processes.dest + Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_masquerading_msdtc_process_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -71,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036/msdtc_process_param/msdtc_a_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036/msdtc_process_param/msdtc_a_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_mimikatz_binary_execution.yml b/detections/endpoint/windows_mimikatz_binary_execution.yml index 218705eefb..2c3e806bab 100644 --- a/detections/endpoint/windows_mimikatz_binary_execution.yml +++ b/detections/endpoint/windows_mimikatz_binary_execution.yml @@ -1,18 +1,18 @@ name: Windows Mimikatz Binary Execution id: a9e0d6d3-9676-4e26-994d-4e0406bb4467 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: As simple as it sounds, this analytic identifies when the native mimikatz.exe - binary executes on Windows. It does look for the original file name as well, just - in case the binary is renamed. Adversaries sometimes bring in the default binary - and run it directly. Benjamin Delpy originally created Mimikatz as a proof of concept - to show Microsoft that its authentication protocols were vulnerable to an attack. - Instead, he inadvertently created one of the most widely used and downloaded threat - actor tools of the past 20 years. Mimikatz is an open-source application that allows - users to view and save authentication credentials such as Kerberos tickets. +description: The following analytic identifies the execution of the native mimikatz.exe + binary on Windows systems, including instances where the binary is renamed. It leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process names + and original file names. This activity is significant because Mimikatz is a widely + used tool for extracting authentication credentials, posing a severe security risk. + If confirmed malicious, this activity could allow attackers to obtain sensitive + credentials, escalate privileges, and move laterally within the network, leading + to potential data breaches and system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -90,7 +90,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003/credential_extraction/mimikatzwindows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003/credential_extraction/mimikatzwindows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_authenticationleveloverride.yml b/detections/endpoint/windows_modify_registry_authenticationleveloverride.yml index 9a02cf1336..28f8014766 100644 --- a/detections/endpoint/windows_modify_registry_authenticationleveloverride.yml +++ b/detections/endpoint/windows_modify_registry_authenticationleveloverride.yml @@ -1,23 +1,27 @@ name: Windows Modify Registry AuthenticationLevelOverride id: 6410a403-36bb-490f-a06a-11c3be7d2a41 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry related to authentication level settings. - This registry is the configuration for authentication level settings within the Terminal Server Client settings in Windows. - AuthenticationLevelOverride might be used to control or override the authentication level used by the Terminal Server Client for remote connections. - DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\Terminal Server Client\\AuthenticationLevelOverride" Registry.registry_value_data = 0x00000000 - by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_modify_registry_authenticationleveloverride_filter`' +description: The following analytic detects modifications to the Windows registry + key "AuthenticationLevelOverride" within the Terminal Server Client settings. It + leverages data from the Endpoint.Registry datamodel to identify changes where the + registry value is set to 0x00000000. This activity is significant as it may indicate + an attempt to override authentication levels for remote connections, a tactic used + by DarkGate malware for malicious installations. If confirmed malicious, this could + allow attackers to gain unauthorized remote access, potentially leading to data + exfiltration or further system compromise. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\Terminal + Server Client\\AuthenticationLevelOverride" Registry.registry_value_data = 0x00000000 + by Registry.registry_path Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_authenticationleveloverride_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -57,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/AuthenticationLevelOverride/auth_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/AuthenticationLevelOverride/auth_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_auto_minor_updates.yml b/detections/endpoint/windows_modify_registry_auto_minor_updates.yml index 3bca5e9f40..2a72081010 100644 --- a/detections/endpoint/windows_modify_registry_auto_minor_updates.yml +++ b/detections/endpoint/windows_modify_registry_auto_minor_updates.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry Auto Minor Updates id: be498b9f-d804-4bbf-9fc0-d5448466b313 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that will "Treat minor updates like other updates". -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AutoInstallMinorUpdates" - AND Registry.registry_value_data="0x00000000" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_auto_minor_updates_filter`' +description: The following analytic identifies a suspicious modification to the Windows + auto update configuration registry. It detects changes to the registry path + "*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AutoInstallMinorUpdates" + with a value of "0x00000000". This activity is significant as it is commonly used + by adversaries, including malware like RedLine Stealer, to bypass detection and + deploy additional payloads. If confirmed malicious, this modification could allow + attackers to evade defenses, potentially leading to further system compromise and + exploitation of zero-day vulnerabilities. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AutoInstallMinorUpdates" + AND Registry.registry_value_data="0x00000000" by Registry.dest Registry.user Registry.registry_path + Registry.registry_value_data Registry.registry_key_name | `drop_dm_object_name(Registry)` + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `windows_modify_registry_auto_minor_updates_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_auto_update_notif.yml b/detections/endpoint/windows_modify_registry_auto_update_notif.yml index e868d8c6e7..f88ce7e5aa 100644 --- a/detections/endpoint/windows_modify_registry_auto_update_notif.yml +++ b/detections/endpoint/windows_modify_registry_auto_update_notif.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry Auto Update Notif id: 4d1409df-40c7-4b11-aec4-bd0e709dfc12 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update notification. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that will switch the automatic windows update to "Notify before download". -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AUOptions" - AND Registry.registry_value_data="0x00000002" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_auto_update_notif_filter`' +description: The following analytic detects a suspicious modification to the Windows + registry that changes the auto-update notification setting to "Notify before download." + This detection leverages data from the Endpoint.Registry data model, focusing on + specific registry paths and values. This activity is significant because it is a + known technique used by adversaries, including malware like RedLine Stealer, to + evade detection and potentially deploy additional payloads. If confirmed malicious, + this modification could allow attackers to bypass security measures, maintain persistence, + and exploit vulnerabilities on the target host. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AUOptions" + AND Registry.registry_value_data="0x00000002" by Registry.dest Registry.user Registry.registry_path + Registry.registry_value_data Registry.registry_key_name | `drop_dm_object_name(Registry)` + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `windows_modify_registry_auto_update_notif_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -34,7 +34,7 @@ tags: analytic_story: - RedLine Stealer asset_type: Endpoint - atomic_guid: + atomic_guid: - 12e03af7-79f9-4f95-af48-d3f12f28a260 confidence: 50 impact: 50 @@ -64,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_default_icon_setting.yml b/detections/endpoint/windows_modify_registry_default_icon_setting.yml index 15f350d533..6325f12c1a 100644 --- a/detections/endpoint/windows_modify_registry_default_icon_setting.yml +++ b/detections/endpoint/windows_modify_registry_default_icon_setting.yml @@ -1,17 +1,18 @@ name: Windows Modify Registry Default Icon Setting id: a7a7afdb-3c58-45b6-9bff-63e5acfd9d40 -version: 1 -date: '2023-01-16' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is developed to detect suspicious registry modification - to change the default icon association of windows to ransomware . This technique - was seen in Lockbit ransomware where it modified the default icon association of - the compromised Windows OS host with its dropped ransomware icon file as part of - its defacement payload. This registry is not commonly modified by a normal user - so having this anomaly detection may help to catch possible lockbit ransomware infection - or other malware. +description: The following analytic detects suspicious modifications to the Windows + registry's default icon settings, a technique associated with Lockbit ransomware. + It leverages data from the Endpoint Registry data model, focusing on changes to + registry paths under "*HKCR\\*\\defaultIcon\\(Default)*". This activity is significant + as it is uncommon for normal users to modify these settings, and such changes can + indicate ransomware infection or other malware. If confirmed malicious, this could + lead to system defacement and signal a broader ransomware attack, potentially compromising + sensitive data and system integrity. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -67,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/lockbit_ransomware/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/lockbit_ransomware/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_disable_restricted_admin.yml b/detections/endpoint/windows_modify_registry_disable_restricted_admin.yml index add189820a..b526a40c4a 100644 --- a/detections/endpoint/windows_modify_registry_disable_restricted_admin.yml +++ b/detections/endpoint/windows_modify_registry_disable_restricted_admin.yml @@ -1,29 +1,26 @@ name: Windows Modify Registry Disable Restricted Admin id: cee573a0-7587-48e6-ae99-10e8c657e89a -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry related to DisableRestrictedAdmin. - This registry entry is used to control the behavior of Restricted Admin mode, which is a security feature that limits - the exposure of sensitive credentials when connecting remotely to another computer. When this registry value is set to 0 it - indicates that Restricted Admin mode is enabled (default behavior). As with any modifications to registry settings, - changing this entry should be approached cautiously, ensuring a clear understanding of the implications for system - security and functionality. Unauthorized changes to these security settings can pose risks and should be monitored - closely for any signs of tampering or unauthorized alterations. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry +description: The following analytic detects modifications to the Windows registry + entry "DisableRestrictedAdmin," which controls the Restricted Admin mode behavior. + This detection leverages registry activity logs from endpoint data sources like + Sysmon or Carbon Black. Monitoring this activity is crucial as changes to this setting + can disable a security feature that limits credential exposure during remote connections. + If confirmed malicious, an attacker could weaken security controls, increasing the + risk of credential theft and unauthorized access to sensitive systems. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\System\\CurrentControlSet\\Control\\Lsa\\DisableRestrictedAdmin" - Registry.registry_value_data = 0x00000000) - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_disable_restricted_admin_filter`' + Registry.registry_value_data = 0x00000000) BY _time span=1h Registry.dest Registry.user + Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_disable_restricted_admin_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 @@ -65,12 +62,13 @@ tags: - Registry.user - Registry.dest - Registry.action - - Registry.registry_value_data - - Registry.process_guid + - Registry.registry_value_data + - Registry.process_guid security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.004/NoLMHash/lsa-reg-settings-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.004/NoLMHash/lsa-reg-settings-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_disable_toast_notifications.yml b/detections/endpoint/windows_modify_registry_disable_toast_notifications.yml index 1d46601b2b..0c0d4cfcb6 100644 --- a/detections/endpoint/windows_modify_registry_disable_toast_notifications.yml +++ b/detections/endpoint/windows_modify_registry_disable_toast_notifications.yml @@ -1,16 +1,19 @@ name: Windows Modify Registry Disable Toast Notifications id: ed4eeacb-8d5a-488e-bc97-1ce6ded63b84 -version: 1 -date: '2022-06-22' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows registry - to disable toast notifications. This Windows Operating System feature is responsible - for alerting or notifying user if application or OS need some updates. Adversaries - and malwares like Azorult abuse this technique to disable important update notification - in compromised host. This anomaly detection is a good pivot to look for further - events related to defense evasion and execution. +description: The following analytic detects modifications to the Windows registry + that disable toast notifications. It leverages data from the Endpoint.Registry datamodel, + specifically monitoring changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\PushNotifications\\ToastEnabled*" + with a value set to "0x00000000". This activity is significant because disabling + toast notifications can prevent users from receiving critical system and application + updates, which adversaries like Azorult exploit for defense evasion. If confirmed + malicious, this action could allow attackers to operate undetected, leading to prolonged + persistence and potential further compromise of the system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -60,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_disable_win_defender_raw_write_notif.yml b/detections/endpoint/windows_modify_registry_disable_win_defender_raw_write_notif.yml index b25754e92f..ca18f20edd 100644 --- a/detections/endpoint/windows_modify_registry_disable_win_defender_raw_write_notif.yml +++ b/detections/endpoint/windows_modify_registry_disable_win_defender_raw_write_notif.yml @@ -1,15 +1,19 @@ name: Windows Modify Registry Disable Win Defender Raw Write Notif id: 0e5e25c3-32f4-46f7-ba4a-5b95c3b90f5b -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a modification in the Windows registry - to disable Windows Defender raw write notification feature. This policy controls - whether raw volume write notifications are sent to behavior monitoring or not. This - registry was recently identified in Azorult malware to bypass Windows Defender detections - or behavior monitoring in terms of volume write. +description: The following analytic detects modifications to the Windows registry + that disable the Windows Defender raw write notification feature. It leverages data + from the Endpoint.Registry datamodel, specifically monitoring changes to the registry + path associated with Windows Defender's real-time protection settings. This activity + is significant because disabling raw write notifications can allow malware, such + as Azorult, to bypass Windows Defender's behavior monitoring, potentially leading + to undetected malicious activities. If confirmed malicious, this could enable attackers + to execute code, persist in the environment, and access sensitive information without + detection. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -61,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_disable_windefender_notifications.yml b/detections/endpoint/windows_modify_registry_disable_windefender_notifications.yml index 1b2ecb7346..04af8a5dfd 100644 --- a/detections/endpoint/windows_modify_registry_disable_windefender_notifications.yml +++ b/detections/endpoint/windows_modify_registry_disable_windefender_notifications.yml @@ -1,18 +1,21 @@ name: Windows Modify Registry Disable WinDefender Notifications id: 8e207707-ad40-4eb3-b865-3a52aec91f26 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-09' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification - to disable Windows Defender notification. This technique was being abused by several - adversaries, malware authors and also red-teamers to evade detection on the targeted - machine. RedLine Stealer is one of the malware we've seen that uses this technique - to bypass Windows defender detection. +description: The following analytic detects a suspicious registry modification aimed + at disabling Windows Defender notifications. It leverages data from the Endpoint.Registry + data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows + Defender Security Center\\Notifications\\DisableNotifications" with a value of "0x00000001". + This activity is significant as it indicates an attempt to evade detection by disabling + security alerts, a technique used by adversaries and malware like RedLine Stealer. + If confirmed malicious, this could allow attackers to operate undetected, increasing + the risk of further compromise and data exfiltration. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows Defender Security Center\\Notifications\\DisableNotifications" AND Registry.registry_value_data="0x00000001" @@ -63,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_disable_windows_security_center_notif.yml b/detections/endpoint/windows_modify_registry_disable_windows_security_center_notif.yml index 59a4bf0910..944bbb2aea 100644 --- a/detections/endpoint/windows_modify_registry_disable_windows_security_center_notif.yml +++ b/detections/endpoint/windows_modify_registry_disable_windows_security_center_notif.yml @@ -1,16 +1,19 @@ name: Windows Modify Registry Disable Windows Security Center Notif id: 27ed3e79-6d86-44dd-b9ab-524451c97a7b -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows registry - to disable windows center notifications. This Windows Operating System feature is - responsible for alerting or notifying user if application or OS need some updates. - Adversaries and malwares like Azorult abuse this technique to disable important - update notification in compromised host. This anomaly detection is a good pivot - to look for further events related to defense evasion and execution. +description: The following analytic detects modifications to the Windows registry + aimed at disabling Windows Security Center notifications. It leverages data from + the Endpoint.Registry datamodel, specifically monitoring changes to the registry + path "*\\Windows\\CurrentVersion\\ImmersiveShell\\UseActionCenterExperience*" with + a value of "0x00000000". This activity is significant as it can indicate an attempt + by adversaries or malware, such as Azorult, to evade defenses by suppressing critical + update notifications. If confirmed malicious, this could allow attackers to persist + undetected, potentially leading to further exploitation and compromise of the host + system. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -62,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_disableremotedesktopantialias.yml b/detections/endpoint/windows_modify_registry_disableremotedesktopantialias.yml index 2097dfb15a..7b3ed78c86 100644 --- a/detections/endpoint/windows_modify_registry_disableremotedesktopantialias.yml +++ b/detections/endpoint/windows_modify_registry_disableremotedesktopantialias.yml @@ -1,23 +1,27 @@ name: Windows Modify Registry DisableRemoteDesktopAntiAlias id: 4927c6f1-4667-42e6-bd7a-f5222116386b -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to DisableRemoteDesktopAntiAlias. - This registry setting might be intended to manage or control anti-aliasing behavior (smoothing of edges and fonts) within Remote Desktop sessions. - DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\Terminal Services\\DisableRemoteDesktopAntiAlias" Registry.registry_value_data = 0x00000001 - by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_disableremotedesktopantialias_filter`' +description: The following analytic detects modifications to the Windows registry + key "DisableRemoteDesktopAntiAlias" with a value set to 0x00000001. This detection + leverages data from the Endpoint datamodel, specifically monitoring changes in the + Registry node. This activity is significant as it may indicate the presence of DarkGate + malware, which alters this registry setting to enhance its remote desktop capabilities. + If confirmed malicious, this modification could allow an attacker to maintain persistence + and control over the compromised host, potentially leading to further exploitation + and data exfiltration. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\Terminal + Services\\DisableRemoteDesktopAntiAlias" Registry.registry_value_data = 0x00000001 + by Registry.registry_path Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_disableremotedesktopantialias_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -32,7 +36,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: the registry for remote desktop settings was modified to be DisableRemoteDesktopAntiAlias on $dest$. + message: the registry for remote desktop settings was modified to be DisableRemoteDesktopAntiAlias + on $dest$. mitre_attack_id: - T1112 observable: @@ -57,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/DisableRemoteDesktopAntiAlias/disable_remote_alias.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/DisableRemoteDesktopAntiAlias/disable_remote_alias.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_disablesecuritysettings.yml b/detections/endpoint/windows_modify_registry_disablesecuritysettings.yml index f4a0454a6f..51df5de3ed 100644 --- a/detections/endpoint/windows_modify_registry_disablesecuritysettings.yml +++ b/detections/endpoint/windows_modify_registry_disablesecuritysettings.yml @@ -1,20 +1,21 @@ name: Windows Modify Registry DisableSecuritySettings id: 989019b4-b7aa-418a-9a17-2293e91288b6 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry - to disable security settings of Terminal Services. altering or disabling security - settings within Terminal Services. Terminal Services, now known as Remote Desktop - Services (RDS) in more recent Windows versions, allows users to access applications, - data, and even an entire desktop remotely. DarkGate malware modify this registry - as part of its malicious installation in a targeted host for its remote desktop - capabilities. +description: The following analytic detects modifications to the Windows registry + that disable security settings for Terminal Services. It leverages the Endpoint + data model, specifically monitoring changes to the registry path associated with + Terminal Services security settings. This activity is significant because altering + these settings can weaken the security posture of Remote Desktop Services, potentially + allowing unauthorized remote access. If confirmed malicious, such modifications + could enable attackers to gain persistent remote access to the system, facilitating + further exploitation and data exfiltration. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\Terminal Services\\DisableSecuritySettings" Registry.registry_value_data = 0x00000001 by Registry.registry_path @@ -62,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/disablesecuritysetting.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/disablesecuritysetting.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_disabling_wer_settings.yml b/detections/endpoint/windows_modify_registry_disabling_wer_settings.yml index d488055f1f..d26073ec5f 100644 --- a/detections/endpoint/windows_modify_registry_disabling_wer_settings.yml +++ b/detections/endpoint/windows_modify_registry_disabling_wer_settings.yml @@ -1,15 +1,17 @@ name: Windows Modify Registry Disabling WER Settings id: 21cbcaf1-b51f-496d-a0c1-858ff3070452 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a modification in the Windows registry - to disable Windows error reporting settings. This Windows feature allows the user - to report bugs, errors, failure or problems encountered in specific application - or processes. Adversaries use this technique to hide any error or failure that some - of its malicious components trigger. +description: The following analytic detects modifications in the Windows registry + to disable Windows Error Reporting (WER) settings. It leverages data from the Endpoint.Registry + datamodel, specifically monitoring changes to registry paths related to WER with + a value set to "0x00000001". This activity is significant as adversaries may disable + WER to suppress error notifications, hiding the presence of malicious activities. + If confirmed malicious, this could allow attackers to operate undetected, potentially + leading to prolonged persistence and further exploitation within the environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -60,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_disallow_windows_app.yml b/detections/endpoint/windows_modify_registry_disallow_windows_app.yml index 87a95b0a1f..7fa3ba2780 100644 --- a/detections/endpoint/windows_modify_registry_disallow_windows_app.yml +++ b/detections/endpoint/windows_modify_registry_disallow_windows_app.yml @@ -1,15 +1,18 @@ name: Windows Modify Registry DisAllow Windows App id: 4bc788d3-c83a-48c5-a4e2-e0c6dba57889 -version: 1 -date: '2022-06-22' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies modification in the Windows registry - to prevent user running specific computer programs that could aid them in manually - removing malware or detecting it using security products. This technique was recently - identified in Azorult malware where it uses this registry value to prevent several - AV products to execute on the compromised host machine. +description: The following analytic detects modifications to the Windows registry + aimed at preventing the execution of specific computer programs. It leverages data + from the Endpoint.Registry datamodel, focusing on changes to the registry path + "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\DisallowRun*" + with a value of "0x00000001". This activity is significant as it can indicate an + attempt to disable security tools, a tactic used by malware like Azorult. If confirmed + malicious, this could allow an attacker to evade detection and maintain persistence + on the compromised host. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -58,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_do_not_connect_to_win_update.yml b/detections/endpoint/windows_modify_registry_do_not_connect_to_win_update.yml index 6ef781934b..e165e8ebe5 100644 --- a/detections/endpoint/windows_modify_registry_do_not_connect_to_win_update.yml +++ b/detections/endpoint/windows_modify_registry_do_not_connect_to_win_update.yml @@ -1,27 +1,27 @@ name: Windows Modify Registry Do Not Connect To Win Update id: e09c598e-8dd0-4e73-b740-4b96b689199e -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that will disable Windos update functionality, and may cause connection to public services such as the Windows Store to stop working. - This policy applies only when this PC is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\DoNotConnectToWindowsUpdateInternetLocations" - AND Registry.registry_value_data="0x00000001" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_do_not_connect_to_win_update_filter`' +description: The following analytic detects a suspicious modification to the Windows + registry that disables automatic updates. It leverages data from the Endpoint datamodel, + specifically monitoring changes to the registry path + "*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\DoNotConnectToWindowsUpdateInternetLocations" + with a value of "0x00000001". This activity is significant as it can be used by + adversaries, including malware like RedLine Stealer, to evade detection and prevent + the system from receiving critical updates. If confirmed malicious, this could allow + attackers to exploit vulnerabilities, persist in the environment, and potentially + deploy additional payloads. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\DoNotConnectToWindowsUpdateInternetLocations" + AND Registry.registry_value_data="0x00000001" by Registry.dest Registry.user Registry.registry_path + Registry.registry_value_data Registry.registry_key_name | `drop_dm_object_name(Registry)` + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `windows_modify_registry_do_not_connect_to_win_update_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -36,7 +36,7 @@ tags: analytic_story: - RedLine Stealer asset_type: Endpoint - atomic_guid: + atomic_guid: - 12e03af7-79f9-4f95-af48-d3f12f28a260 confidence: 50 impact: 50 @@ -66,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_dontshowui.yml b/detections/endpoint/windows_modify_registry_dontshowui.yml index ffcdd1cb73..6f4f26d691 100644 --- a/detections/endpoint/windows_modify_registry_dontshowui.yml +++ b/detections/endpoint/windows_modify_registry_dontshowui.yml @@ -1,25 +1,27 @@ name: Windows Modify Registry DontShowUI id: 4ff9767b-fdf2-489c-83a5-c6c34412d72e -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows Error Reporting registry to DontShowUI. - DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. - When this registry value is present and set to a specific configuration, it can influence the behavior of error reporting dialogs or prompts, - suppressing them from being displayed to the user.For instance, setting DontShowUI to a value of 1 often indicates that the - Windows Error Reporting UI prompts will be suppressed, meaning users won't see error reporting pop-ups when errors occur. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\DontShowUI" Registry.registry_value_data = 0x00000001 - by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_dontshowui_filter`' +description: The following analytic detects modifications to the Windows Error Reporting + registry key "DontShowUI" to suppress error reporting dialogs. It leverages data + from the Endpoint datamodel's Registry node to identify changes where the registry + value is set to 0x00000001. This activity is significant as it is commonly associated + with DarkGate malware, which uses this modification to avoid detection during its + installation. If confirmed malicious, this behavior could allow attackers to maintain + a low profile, avoiding user alerts and potentially enabling further malicious activities + without user intervention. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\SOFTWARE\\Microsoft\\Windows\\Windows + Error Reporting\\DontShowUI" Registry.registry_value_data = 0x00000001 by Registry.registry_path + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_dontshowui_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -59,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/wer_dontshowui/dontshowui_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/wer_dontshowui/dontshowui_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_enablelinkedconnections.yml b/detections/endpoint/windows_modify_registry_enablelinkedconnections.yml index f22dd15d67..c57b4e44ec 100644 --- a/detections/endpoint/windows_modify_registry_enablelinkedconnections.yml +++ b/detections/endpoint/windows_modify_registry_enablelinkedconnections.yml @@ -1,24 +1,28 @@ name: Windows Modify Registry EnableLinkedConnections id: 93048164-3358-4af0-8680-aa5f38440516 -version: 1 -date: '2023-07-10' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows linked connection configuration. - This technique was being abused by several adversaries, malware like BlackByte ransomware to enable the linked connections feature, - that allows network shares to be accessed using both standard and administrator-level privileges simultaneously. - By default, Windows does not enable this feature to enhance security. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE (Registry.registry_path= "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLinkedConnections" Registry.registry_value_data = "0x00000001") - BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_enablelinkedconnections_filter`' +description: The following analytic detects a suspicious modification to the Windows + registry setting for EnableLinkedConnections. It leverages data from the Endpoint.Registry + datamodel to identify changes where the registry path is + "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLinkedConnections" + and the value is set to "0x00000001". This activity is significant because enabling + linked connections can allow network shares to be accessed with both standard and + administrator-level privileges, a technique often abused by malware like BlackByte + ransomware. If confirmed malicious, this could lead to unauthorized access to sensitive + network resources, escalating the attacker's privileges. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLinkedConnections" + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_modify_registry_enablelinkedconnections_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -35,7 +39,8 @@ tags: - 4f4e2f9f-6209-4fcf-9b15-3b7455706f5b confidence: 70 impact: 70 - message: A registry modification in Windows EnableLinkedConnections configuration on $dest$ + message: A registry modification in Windows EnableLinkedConnections configuration + on $dest$ mitre_attack_id: - T1112 observable: @@ -61,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/blackbyte/enablelinkedconnections/blackbyte_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/blackbyte/enablelinkedconnections/blackbyte_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_longpathsenabled.yml b/detections/endpoint/windows_modify_registry_longpathsenabled.yml index 4904bd46ff..1822366cb3 100644 --- a/detections/endpoint/windows_modify_registry_longpathsenabled.yml +++ b/detections/endpoint/windows_modify_registry_longpathsenabled.yml @@ -1,24 +1,27 @@ name: Windows Modify Registry LongPathsEnabled id: 36f9626c-4272-4808-aadd-267acce681c0 -version: 1 -date: '2023-07-10' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows long path enable configuration. - This technique was being abused by several adversaries, malware like BlackByte to enable long file path support in the operating system. - By default, Windows has a limitation on the maximum length of a file path, which is set to 260 characters. - Enabling the LongPathsEnabled setting allows you to work with file paths longer than 260 characters. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE (Registry.registry_path= "*\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled" Registry.registry_value_data = "0x00000001") - BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_longpathsenabled_filter`' +description: The following analytic detects a modification to the Windows registry + setting "LongPathsEnabled," which allows file paths longer than 260 characters. + This detection leverages data from the Endpoint.Registry datamodel, focusing on + changes to the specific registry path and value. This activity is significant because + adversaries, including malware like BlackByte, exploit this setting to bypass file + path limitations, potentially aiding in evasion techniques. If confirmed malicious, + this modification could facilitate the execution of long-path payloads, aiding in + persistence and further system compromise. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + WHERE (Registry.registry_path= "*\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled" + Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_modify_registry_longpathsenabled_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -61,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/blackbyte/longpathsenabled/longpath_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/blackbyte/longpathsenabled/longpath_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_maxconnectionperserver.yml b/detections/endpoint/windows_modify_registry_maxconnectionperserver.yml index 94c2969b1c..effdb82672 100644 --- a/detections/endpoint/windows_modify_registry_maxconnectionperserver.yml +++ b/detections/endpoint/windows_modify_registry_maxconnectionperserver.yml @@ -1,23 +1,28 @@ name: Windows Modify Registry MaxConnectionPerServer id: 064cd09f-1ff4-4823-97e0-45c2f5b087ec -version: 1 -date: '2023-07-26' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows max connection per server configuration. - This particular technique has been observed in various threat actors, adversaries, and even in malware such as the Warzone (Ave Maria) RAT. - By altering the max connection per server setting in the Windows registry, attackers can potentially increase the number of concurrent connections - allowed to a remote server. This modification could be exploited for various malicious purposes, including facilitating distributed denial-of-service (DDoS) attacks or enabling more effective lateral movement within a compromised network. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry - where (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\MaxConnectionsPerServer*" OR Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\MaxConnectionsPer1_0Server*") Registry.registry_value_data = "0x0000000a" by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_maxconnectionperserver_filter`' +description: The following analytic identifies a suspicious modification of the Windows + registry setting for max connections per server. It detects changes to specific + registry paths using data from the Endpoint.Registry datamodel. This activity is + significant because altering this setting can be exploited by attackers to increase + the number of concurrent connections to a remote server, potentially facilitating + DDoS attacks or enabling more effective lateral movement within a compromised network. + If confirmed malicious, this could lead to network disruption or further compromise + of additional systems. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime FROM datamodel=Endpoint.Registry where (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet + Settings\\MaxConnectionsPerServer*" OR Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet + Settings\\MaxConnectionsPer1_0Server*") Registry.registry_value_data = "0x0000000a" + by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data + Registry.action Registry.dest | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_modify_registry_maxconnectionperserver_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -59,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/maxconnectionperserver/registry_event.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/maxconnectionperserver/registry_event.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_no_auto_reboot_with_logon_user.yml b/detections/endpoint/windows_modify_registry_no_auto_reboot_with_logon_user.yml index e341e11248..a9825acf86 100644 --- a/detections/endpoint/windows_modify_registry_no_auto_reboot_with_logon_user.yml +++ b/detections/endpoint/windows_modify_registry_no_auto_reboot_with_logon_user.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry No Auto Reboot With Logon User id: 6a12fa9f-580d-4627-8c7f-313e359bdc6a -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that will allow "Logged-on user gets to choose whether or not to restart his or her compute". -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\NoAutoRebootWithLoggedOnUsers" - AND Registry.registry_value_data="0x00000001" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_no_auto_reboot_with_logon_user_filter`' +description: The following analytic detects a suspicious modification to the Windows + registry that disables automatic reboot with a logged-on user. This detection leverages + the Endpoint data model to identify changes to the registry path + `SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoRebootWithLoggedOnUsers` + with a value of `0x00000001`. This activity is significant as it is commonly used + by adversaries, including malware like RedLine Stealer, to evade detection and maintain + persistence. If confirmed malicious, this could allow attackers to bypass security + measures and deploy additional payloads without interruption. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\NoAutoRebootWithLoggedOnUsers" + AND Registry.registry_value_data="0x00000001" by Registry.dest Registry.user Registry.registry_path + Registry.registry_value_data Registry.registry_key_name | `drop_dm_object_name(Registry)` + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `windows_modify_registry_no_auto_reboot_with_logon_user_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -34,7 +34,7 @@ tags: analytic_story: - RedLine Stealer asset_type: Endpoint - atomic_guid: + atomic_guid: - 12e03af7-79f9-4f95-af48-d3f12f28a260 confidence: 30 impact: 30 @@ -64,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_no_auto_update.yml b/detections/endpoint/windows_modify_registry_no_auto_update.yml index c65d281c3c..068495e512 100644 --- a/detections/endpoint/windows_modify_registry_no_auto_update.yml +++ b/detections/endpoint/windows_modify_registry_no_auto_update.yml @@ -1,20 +1,20 @@ name: Windows Modify Registry No Auto Update id: fbd4f333-17bb-4eab-89cb-860fa2e0600e -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification - of Windows auto update configuration. This technique was being abused by several - adversaries, malware authors and also red-teamers to bypass detection or to be able - to compromise the target host with zero day exploit or as an additional defense - evasion technique. RedLine Stealer is one of the malware we've seen that uses this - technique to evade detection and add more payload on the target host. This detection - looks for registry modification that will "Disable Automatic Updates". +description: The following analytic identifies a suspicious modification to the Windows + registry that disables automatic updates. It detects changes to the registry path + `SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate` with a value + of `0x00000001`. This activity is significant as it is commonly used by adversaries, + including malware like RedLine Stealer, to evade detection and maintain persistence. + If confirmed malicious, this could allow attackers to bypass security updates, leaving + the system vulnerable to further exploitation and potential zero-day attacks. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\NoAutoUpdate" AND Registry.registry_value_data="0x00000001" by Registry.dest Registry.user Registry.registry_path @@ -64,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_nochangingwallpaper.yml b/detections/endpoint/windows_modify_registry_nochangingwallpaper.yml index 309c48bbbd..1b2fba591d 100644 --- a/detections/endpoint/windows_modify_registry_nochangingwallpaper.yml +++ b/detections/endpoint/windows_modify_registry_nochangingwallpaper.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry NoChangingWallPaper id: a2276412-e254-4e9a-9082-4d92edb6a3e0 -version: 1 -date: '2023-12-12' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies alterations in the Windows registry aimed at restricting wallpaper modifications. - This tactic has been exploited by the Rhysida ransomware as a part of its destructive payload within compromised systems. - By making this registry modification, the ransomware seeks to impede users from changing the wallpaper forcibly set by the malware, - restricting the user's control over their system's visual settings. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry +description: The following analytic detects modifications to the Windows registry + aimed at preventing wallpaper changes. It leverages data from the Endpoint.Registry + datamodel, specifically monitoring changes to the "NoChangingWallPaper" registry + value. This activity is significant as it is a known tactic used by Rhysida ransomware + to enforce a malicious wallpaper, thereby limiting user control over system settings. + If confirmed malicious, this registry change could indicate a ransomware infection, + leading to further system compromise and user disruption. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\Windows\\CurrentVersion\\Policies\\ActiveDesktop\\NoChangingWallPaper" - Registry.registry_value_data = 1) - BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_nochangingwallpaper_filter`' + Registry.registry_value_data = 1) BY _time span=1h Registry.dest Registry.user Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data + Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_nochangingwallpaper_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -35,7 +35,8 @@ tags: asset_type: Endpoint confidence: 60 impact: 60 - message: the registry settings was modified to disable changing of wallpaper on $dest$. + message: the registry settings was modified to disable changing of wallpaper on + $dest$. mitre_attack_id: - T1112 observable: @@ -60,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/no_changing_wallpaper/NoChangingWallPaper.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/no_changing_wallpaper/NoChangingWallPaper.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_proxyenable.yml b/detections/endpoint/windows_modify_registry_proxyenable.yml index 2d5b384c3a..1c7713ebe9 100644 --- a/detections/endpoint/windows_modify_registry_proxyenable.yml +++ b/detections/endpoint/windows_modify_registry_proxyenable.yml @@ -1,26 +1,27 @@ name: Windows Modify Registry ProxyEnable id: b27f20bd-ef20-41d1-a1e9-25dedd5bf2f5 -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to enable proxy. - This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, - facilitating connections to malicious Command and Control (C2) servers. - Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy - feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially - those aiming to leverage proxy configurations for unauthorized communication with malicious entities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\Internet Settings\\ProxyEnable" Registry.registry_value_data = 0x00000001 - by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_registry_proxyenable_filter`' +description: The following analytic detects modifications to the Windows registry + key "ProxyEnable" to enable proxy settings. It leverages data from the Endpoint.Registry + datamodel, specifically monitoring changes to the "Internet Settings\ProxyEnable" + registry path. This activity is significant as it is commonly exploited by malware + and adversaries to establish proxy communication, potentially connecting to malicious + Command and Control (C2) servers. If confirmed malicious, this could allow attackers + to redirect network traffic through a proxy, facilitating unauthorized communication + and data exfiltration, thereby compromising the security of the affected host. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\Internet + Settings\\ProxyEnable" Registry.registry_value_data = 0x00000001 by Registry.registry_path + Registry.registry_value_name Registry.registry_value_data Registry.process_guid + Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_proxyenable_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure @@ -60,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/proxy_enable/proxyenable.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/proxy_enable/proxyenable.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_proxyserver.yml b/detections/endpoint/windows_modify_registry_proxyserver.yml index 179e526a4d..83f4e5bae7 100644 --- a/detections/endpoint/windows_modify_registry_proxyserver.yml +++ b/detections/endpoint/windows_modify_registry_proxyserver.yml @@ -1,26 +1,25 @@ name: Windows Modify Registry ProxyServer id: 12bdaa0b-3c59-4489-aae1-bff6d67746ef -version: 1 -date: '2023-11-23' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a modification in the Windows registry to setup proxy server. - This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, - facilitating connections to malicious Command and Control (C2) servers. - Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy - feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially - those aiming to leverage proxy configurations for unauthorized communication with malicious entities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\Internet Settings\\ProxyServer" - by Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.action Registry.user Registry.dest - | `drop_dm_object_name(Registry)` - | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects modifications to the Windows registry + key for setting up a proxy server. It leverages data from the Endpoint.Registry + datamodel, focusing on changes to the "Internet Settings\\ProxyServer" registry + path. This activity is significant as it can indicate malware or adversaries configuring + a proxy to facilitate unauthorized communication with Command and Control (C2) servers. + If confirmed malicious, this could allow attackers to establish persistent, covert + channels for data exfiltration or further exploitation of the compromised host. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path = "*\\Internet + Settings\\ProxyServer" by Registry.registry_path Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.action Registry.user Registry.dest | `drop_dm_object_name(Registry)` + | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_registry_proxyserver_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -61,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/proxy_server/ProxyServer_sys.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/proxy_server/ProxyServer_sys.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog \ No newline at end of file + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_qakbot_binary_data_registry.yml b/detections/endpoint/windows_modify_registry_qakbot_binary_data_registry.yml index f92bf36259..b5232301d2 100644 --- a/detections/endpoint/windows_modify_registry_qakbot_binary_data_registry.yml +++ b/detections/endpoint/windows_modify_registry_qakbot_binary_data_registry.yml @@ -1,35 +1,39 @@ name: Windows Modify Registry Qakbot Binary Data Registry id: 2e768497-04e0-4188-b800-70dd2be0e30d -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-12' author: Teoderick Contreras, Bhavin Patel, Splunk status: production type: Anomaly -description: The following analytic identifies a suspicious registry entry created - by Qakbot malware as part of its malicious execution. This "Binary Data" Registry was - created by newly spawn explorer.exe where its malicious code is injected to it. - The registry consist of 8 random registry value name with encrypted binary data - on its registry value data. This anomaly detections can be a good pivot for possible - Qakbot malware infection or other malware that uses registry to save or store there - config or malicious code on the registry data stream. +description: The following analytic detects the creation of a suspicious registry + entry by Qakbot malware, characterized by 8 random registry value names with encrypted + binary data. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on registry modifications under the "SOFTWARE\\Microsoft\\" + path by processes like explorer.exe. This activity is significant as it indicates + potential Qakbot infection, which uses the registry to store malicious code or configuration + data. If confirmed malicious, this could allow attackers to maintain persistence + and execute arbitrary code on the compromised system. data_source: - Sysmon EventID 1 - Sysmon EventID 12 - Sysmon EventID 13 -search: '| tstats `security_content_summariesonly` count dc(registry_value_name) as registry_value_name_count FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Microsoft\\*" AND Registry.registry_value_data = "Binary Data" by _time span=1m Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.process_id Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | eval registry_key_name_len = len(registry_key_name) - | eval registry_value_name_len = len(registry_value_name) - | regex registry_value_name="^[0-9a-fA-F]{8}" - | where registry_key_name_len < 80 AND registry_value_name_len == 8 - | join process_guid, _time - [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name IN ("explorer.exe", "wermgr.exe","dxdiag.exe", "OneDriveSetup.exe", "mobsync.exe", "msra.exe", "xwizard.exe") by _time span=1m Processes.process_id Processes.process_name Processes.process Processes.dest Processes.parent_process_name Processes.parent_process Processes.process_guid Processes.process_path - | `drop_dm_object_name(Processes)` - ] - | stats min(_time) as firstTime max(_time) as lastTime values(registry_value_name) as registry_value_name dc(registry_value_name) as registry_value_name_count values(registry_key_name) by dest process_guid process_name parent_process_name - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | where registry_value_name_count >= 5 - | `windows_modify_registry_qakbot_binary_data_registry_filter`' +search: '| tstats `security_content_summariesonly` count dc(registry_value_name) as + registry_value_name_count FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Microsoft\\*" + AND Registry.registry_value_data = "Binary Data" by _time span=1m Registry.dest + Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_value_data + Registry.process_guid Registry.process_id Registry.registry_key_name | `drop_dm_object_name(Registry)` + | eval registry_key_name_len = len(registry_key_name) | eval registry_value_name_len + = len(registry_value_name) | regex registry_value_name="^[0-9a-fA-F]{8}" | where + registry_key_name_len < 80 AND registry_value_name_len == 8 | join process_guid, + _time [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes + where Processes.process_name IN ("explorer.exe", "wermgr.exe","dxdiag.exe", "OneDriveSetup.exe", + "mobsync.exe", "msra.exe", "xwizard.exe") by _time span=1m Processes.process_id + Processes.process_name Processes.process Processes.dest Processes.parent_process_name + Processes.parent_process Processes.process_guid Processes.process_path | `drop_dm_object_name(Processes)` + ] | stats min(_time) as firstTime max(_time) as lastTime values(registry_value_name) + as registry_value_name dc(registry_value_name) as registry_value_name_count values(registry_key_name) + by dest process_guid process_name parent_process_name | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | where registry_value_name_count >= 5 | `windows_modify_registry_qakbot_binary_data_registry_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -82,7 +86,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_reg_restore.yml b/detections/endpoint/windows_modify_registry_reg_restore.yml index f825c16324..d1a53adcac 100644 --- a/detections/endpoint/windows_modify_registry_reg_restore.yml +++ b/detections/endpoint/windows_modify_registry_reg_restore.yml @@ -1,15 +1,18 @@ name: Windows Modify Registry Reg Restore id: d0072bd2-6d73-4c1b-bc77-ded6d2da3a4e -version: 1 -date: '2022-12-12' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process execution of reg.exe with - "restore" parameter. This reg.exe parameter is commonly used to restore registry - backup data in a targeted host. This approach or technique was also seen in post-exploitation - tool like winpeas where it uses "reg save" and "reg restore" to check the registry - modification restriction in targeted host after gaining access to it. +description: The following analytic detects the execution of reg.exe with the "restore" + parameter, indicating an attempt to restore registry backup data on a host. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process execution logs and command-line arguments. This activity is significant + as it may indicate post-exploitation actions, such as those performed by tools like + winpeas, which use "reg save" and "reg restore" to manipulate registry settings. + If confirmed malicious, this could allow an attacker to revert registry changes, + potentially bypassing security controls and maintaining persistence. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_regedit_silent_reg_import.yml b/detections/endpoint/windows_modify_registry_regedit_silent_reg_import.yml index 2fadc958c1..fbdb72e48b 100644 --- a/detections/endpoint/windows_modify_registry_regedit_silent_reg_import.yml +++ b/detections/endpoint/windows_modify_registry_regedit_silent_reg_import.yml @@ -1,17 +1,18 @@ name: Windows Modify Registry Regedit Silent Reg Import id: 824dd598-71be-4203-bc3b-024f4cda340e -version: 1 -date: '2022-06-24' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies modification of Windows registry using - regedit.exe application with silent mode parameter. regedit.exe windows application - is commonly used as GUI app to check or modify registry. This application is also - has undocumented command-line parameter and one of those are silent mode parameter - that performs action without stopping for confirmation with dialog box. Importing - registry from .reg files need to monitor in a production environment since it can - be used adversaries to import RMS registry in compromised host. +description: The following analytic detects the modification of the Windows registry + using the regedit.exe application with the silent mode parameter. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + command-line executions. This activity is significant because the silent mode allows + registry changes without user confirmation, which can be exploited by adversaries + to import malicious registry settings. If confirmed malicious, this could enable + attackers to persist in the environment, escalate privileges, or manipulate system + configurations, leading to potential system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -72,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_risk_behavior.yml b/detections/endpoint/windows_modify_registry_risk_behavior.yml index 17c8a72951..f44605d7f1 100644 --- a/detections/endpoint/windows_modify_registry_risk_behavior.yml +++ b/detections/endpoint/windows_modify_registry_risk_behavior.yml @@ -1,32 +1,36 @@ name: Windows Modify Registry Risk Behavior id: 5eb479b1-a5ea-4e01-8365-780078613776 -version: 1 -date: '2023-06-15' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Correlation data_source: [] -description: This analytic is designed to identify instances where three or more distinct analytics associated with Mitre ID T1112 - Modification of registry information are triggered. Such occurrences could indicate the presence of multiple malicious registry modifications on a host. Malicious actors frequently manipulate the Windows Registry to hide important configuration details within specific Registry keys. This technique allows them to obscure their activities, erase any evidence during cleanup operations, and establish continuous access and execution of malicious code. -search: '| 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 - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where source_count >= 3 - | `windows_modify_registry_risk_behavior_filter`' -how_to_implement: 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. +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: '| 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 | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 3 | `windows_modify_registry_risk_behavior_filter`' +how_to_implement: 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. references: @@ -64,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/windows_mod_reg_risk_behavior/modify_reg_risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/windows_mod_reg_risk_behavior/modify_reg_risk.log source: mod_reg sourcetype: stash diff --git a/detections/endpoint/windows_modify_registry_suppress_win_defender_notif.yml b/detections/endpoint/windows_modify_registry_suppress_win_defender_notif.yml index 5a38de518c..c863f2df58 100644 --- a/detections/endpoint/windows_modify_registry_suppress_win_defender_notif.yml +++ b/detections/endpoint/windows_modify_registry_suppress_win_defender_notif.yml @@ -1,15 +1,18 @@ name: Windows Modify Registry Suppress Win Defender Notif id: e3b42daf-fff4-429d-bec8-2a199468cea9 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows registry - to suppress windows defender notification. This technique was abuse by adversaries - and threat actor to bypassed windows defender on the targeted host. Azorult malware - is one of the malware use this technique that also disable toast notification and - other windows features as part of its malicious behavior. +description: The following analytic detects modifications in the Windows registry + to suppress Windows Defender notifications. It leverages data from the Endpoint.Registry + datamodel, specifically targeting changes to the "Notification_Suppress" registry + value. This activity is significant because adversaries, including those deploying + Azorult malware, use this technique to bypass Windows Defender and disable critical + notifications. If confirmed malicious, this behavior could allow attackers to evade + detection, maintain persistence, and execute further malicious activities without + alerting the user or security tools. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -61,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_modify_registry_tamper_protection.yml b/detections/endpoint/windows_modify_registry_tamper_protection.yml index 47a68a3ea0..d35c5a3f93 100644 --- a/detections/endpoint/windows_modify_registry_tamper_protection.yml +++ b/detections/endpoint/windows_modify_registry_tamper_protection.yml @@ -1,24 +1,27 @@ name: Windows Modify Registry Tamper Protection id: 12094335-88fc-4c3a-b55f-e62dd8c93c23 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification to tamper Windows Defender protection. - This technique was being abused by several adversaries, malware authors and also red-teamers to evade detection on the targeted machine. - RedLine Stealer is one of the malware we've seen that uses this technique to bypass Windows defender detection. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Microsoft\\Windows Defender\\Features\\TamperProtection" - AND Registry.registry_value_data="0x00000000" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_tamper_protection_filter`' +description: The following analytic detects a suspicious modification to the Windows + Defender Tamper Protection registry setting. It leverages data from the Endpoint + datamodel, specifically targeting changes where the registry path is set to disable + Tamper Protection. This activity is significant because disabling Tamper Protection + can allow adversaries to make further undetected changes to Windows Defender settings, + potentially leading to reduced security on the system. If confirmed malicious, this + could enable attackers to evade detection, persist in the environment, and execute + further malicious activities without interference from Windows Defender. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Microsoft\\Windows + Defender\\Features\\TamperProtection" AND Registry.registry_value_data="0x00000000" + by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data + Registry.registry_key_name | `drop_dm_object_name(Registry)` | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_modify_registry_tamper_protection_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -32,7 +35,7 @@ tags: analytic_story: - RedLine Stealer asset_type: Endpoint - atomic_guid: + atomic_guid: - 12e03af7-79f9-4f95-af48-d3f12f28a260 confidence: 70 impact: 70 @@ -62,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_updateserviceurlalternate.yml b/detections/endpoint/windows_modify_registry_updateserviceurlalternate.yml index a4e0b5cc50..60b4641bd4 100644 --- a/detections/endpoint/windows_modify_registry_updateserviceurlalternate.yml +++ b/detections/endpoint/windows_modify_registry_updateserviceurlalternate.yml @@ -1,25 +1,26 @@ name: Windows Modify Registry UpdateServiceUrlAlternate id: ca4e94fb-7969-4d63-8630-3625809a1f70 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that specifies an intranet server to host updates from Microsoft Update. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\UpdateServiceUrlAlternate" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_updateserviceurlalternate_filter`' +description: The following analytic detects a suspicious modification to the Windows + Update configuration registry key, specifically targeting the UpdateServiceUrlAlternate + setting. It leverages data from the Endpoint.Registry datamodel to identify changes + to this registry path. This activity is significant because adversaries, including + malware like RedLine Stealer, exploit this technique to bypass detection and deploy + additional payloads. If confirmed malicious, this modification could allow attackers + to redirect update services, potentially leading to the execution of malicious code, + further system compromise, and persistent evasion of security defenses. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\UpdateServiceUrlAlternate" + by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data + Registry.registry_key_name | `drop_dm_object_name(Registry)` | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_modify_registry_updateserviceurlalternate_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -61,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_usewuserver.yml b/detections/endpoint/windows_modify_registry_usewuserver.yml index 56fbac5ca4..acbbb57bfa 100644 --- a/detections/endpoint/windows_modify_registry_usewuserver.yml +++ b/detections/endpoint/windows_modify_registry_usewuserver.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry USeWuServer id: c427bafb-0b2c-4b18-ad85-c03c6fed9e75 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification that will use "The WUServer value unless this key is set". -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\UseWUServer" - AND Registry.registry_value_data="0x00000001" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_usewuserver_filter`' +description: The following analytic detects a suspicious modification to the Windows + Update configuration registry key "UseWUServer." It leverages data from the Endpoint.Registry + data model to identify changes where the registry value is set to "0x00000001." + This activity is significant because it is commonly used by adversaries, including + malware like RedLine Stealer, to bypass detection mechanisms and potentially exploit + zero-day vulnerabilities. If confirmed malicious, this modification could allow + attackers to evade defenses, persist on the target host, and deploy additional malicious + payloads. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\UseWUServer" + AND Registry.registry_value_data="0x00000001" by Registry.dest Registry.user Registry.registry_path + Registry.registry_value_data Registry.registry_key_name | `drop_dm_object_name(Registry)` + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `windows_modify_registry_usewuserver_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_with_md5_reg_key_name.yml b/detections/endpoint/windows_modify_registry_with_md5_reg_key_name.yml index 0787a856e9..5c29de3e84 100644 --- a/detections/endpoint/windows_modify_registry_with_md5_reg_key_name.yml +++ b/detections/endpoint/windows_modify_registry_with_md5_reg_key_name.yml @@ -1,31 +1,35 @@ name: Windows Modify Registry With MD5 Reg Key Name id: 4662c6b1-0754-455e-b9ff-3ee730af3ba8 -version: 1 -date: '2023-09-25' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: This analytic is designed to identify potentially malicious registry modification characterized by MD5-like registry key names. - This technique has been notably observed in NjRAT malware, which employs such registries for fileless storage of keylogs and .DLL plugins. - Detecting this tactic serves as an effective means of identifying possible NjRAT malware instances that create or modify registries as - part of their malicious activities. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path = "*\\SOFTWARE\\*" Registry.registry_value_data = "Binary Data" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | eval dropped_reg_path = split(registry_path, "\\") - | eval dropped_reg_path_split_count = mvcount(dropped_reg_path) +description: The following analytic detects potentially malicious registry modifications + characterized by MD5-like registry key names. It leverages the Endpoint data model + to identify registry entries under the SOFTWARE path with 32-character hexadecimal + names, a technique often used by NjRAT malware for fileless storage of keylogs and + .DLL plugins. This activity is significant as it can indicate the presence of NjRAT + or similar malware, which can lead to unauthorized data access and persistent threats + within the environment. If confirmed malicious, attackers could maintain persistence + and exfiltrate sensitive information. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime + max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path + = "*\\SOFTWARE\\*" Registry.registry_value_data = "Binary Data" by Registry.dest + Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_value_data + Registry.registry_key_name | `drop_dm_object_name(Registry)` | eval dropped_reg_path + = split(registry_path, "\\") | eval dropped_reg_path_split_count = mvcount(dropped_reg_path) | eval validation_result= if(match(registry_value_name,"^[0-9a-fA-F]{32}$"),"md5","nonmd5") - | where validation_result = "md5" AND dropped_reg_path_split_count <= 5 - | table dest user registry_path registry_value_name registry_value_data registry_key_name reg_key_name dropped_reg_path_split_count validation_result - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_with_md5_reg_key_name_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that - include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. + | where validation_result = "md5" AND dropped_reg_path_split_count <= 5 | table + dest user registry_path registry_value_name registry_value_data registry_key_name + reg_key_name dropped_reg_path_split_count validation_result | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_modify_registry_with_md5_reg_key_name_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the Filesystem responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Filesystem` node. known_false_positives: unknown references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/njrat_md5_registry_entry/njrat_reg_binary.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/njrat_md5_registry_entry/njrat_reg_binary.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_wuserver.yml b/detections/endpoint/windows_modify_registry_wuserver.yml index 756a65ab11..3c71d7f3fc 100644 --- a/detections/endpoint/windows_modify_registry_wuserver.yml +++ b/detections/endpoint/windows_modify_registry_wuserver.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry WuServer id: a02ad386-e26d-44ce-aa97-6a46cee31439 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification related to the WSUS server used by Automatic Updates and (by default) API callers. - This policy is paired with WUStatusServer; both must be set to the same value in order for them to be valid. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\WUServer" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_wuserver_filter`' +description: The following analytic detects suspicious modifications to the Windows + Update Server (WUServer) registry settings. It leverages data from the Endpoint.Registry + data model to identify changes in the registry path associated with Windows Update + configurations. This activity is significant because adversaries, including malware + like RedLine Stealer, exploit this technique to bypass detection and deploy additional + payloads. If confirmed malicious, this registry modification could allow attackers + to evade defenses, potentially leading to further system compromise and persistent + unauthorized access. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\WUServer" + by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data + Registry.registry_key_name | `drop_dm_object_name(Registry)` | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_modify_registry_wuserver_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_registry_wustatusserver.yml b/detections/endpoint/windows_modify_registry_wustatusserver.yml index f90cf34d51..92790bcc74 100644 --- a/detections/endpoint/windows_modify_registry_wustatusserver.yml +++ b/detections/endpoint/windows_modify_registry_wustatusserver.yml @@ -1,26 +1,26 @@ name: Windows Modify Registry wuStatusServer id: 073e69d0-68b2-4142-aa90-a7ee6f590676 -version: 1 -date: '2023-04-21' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification of Windows auto update configuration. - This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or - to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. - RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. - This detection looks for registry modification related to the server to which reporting information will be sent for client computers - that use the WSUS server configured by the WUServer key. This policy is paired with WUServer; both must be set to the same value in order for them to be valid. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\WUStatusServer" - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_modify_registry_wustatusserver_filter`' +description: The following analytic identifies suspicious modifications to the Windows + Update configuration registry, specifically targeting the WUStatusServer key. It + leverages data from the Endpoint datamodel to detect changes in the registry path + associated with Windows Update settings. This activity is significant as it is commonly + used by adversaries, including malware like RedLine Stealer, to bypass detection + and deploy additional payloads. If confirmed malicious, this modification could + allow attackers to evade defenses, potentially leading to further system compromise + and persistent unauthorized access. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\WUStatusServer" + by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data + Registry.registry_key_name | `drop_dm_object_name(Registry)` | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_modify_registry_wustatusserver_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/modify_registry/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_show_compress_color_and_info_tip_registry.yml b/detections/endpoint/windows_modify_show_compress_color_and_info_tip_registry.yml index 25e3634663..4f97037742 100644 --- a/detections/endpoint/windows_modify_show_compress_color_and_info_tip_registry.yml +++ b/detections/endpoint/windows_modify_show_compress_color_and_info_tip_registry.yml @@ -1,26 +1,28 @@ name: Windows Modify Show Compress Color And Info Tip Registry id: b7548c2e-9a10-11ec-99e3-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-27' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to look for suspicious registry modification related - to file compression color and information tips. This IOC was seen in hermetic wiper - where it has a thread that will create this registry entry to change the color of - compressed or encrypted files in NTFS file system as well as the pop up information - tips. This is a good indicator that a process tries to modified one of the registry - GlobalFolderOptions related to file compression attribution in terms of color in - NTFS file system. +description: The following analytic detects suspicious modifications to the Windows + registry keys related to file compression color and information tips. It leverages + data from the Endpoint.Registry data model, specifically monitoring changes to the + "ShowCompColor" and "ShowInfoTip" values under the "Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced" + path. This activity is significant as it was observed in the Hermetic Wiper malware, + indicating potential malicious intent to alter file attributes and user interface + elements. If confirmed malicious, this could signify an attempt to manipulate file + visibility and deceive users, potentially aiding in further malicious activities. data_source: - Sysmon EventID 12 - Sysmon EventID 13 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced*" - AND Registry.registry_value_name IN("ShowCompColor", "ShowInfoTip")) BY _time span=1h Registry.dest Registry.user - Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data - Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_modify_show_compress_color_and_info_tip_registry_filter`' + AND Registry.registry_value_name IN("ShowCompColor", "ShowInfoTip")) BY _time span=1h + Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name + Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)` + | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_modify_show_compress_color_and_info_tip_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical @@ -62,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/globalfolderoptions_reg/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/globalfolderoptions_reg/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_modify_system_firewall_with_notable_process_path.yml b/detections/endpoint/windows_modify_system_firewall_with_notable_process_path.yml index 94b88c80ce..be273fc785 100644 --- a/detections/endpoint/windows_modify_system_firewall_with_notable_process_path.yml +++ b/detections/endpoint/windows_modify_system_firewall_with_notable_process_path.yml @@ -1,25 +1,30 @@ name: Windows Modify System Firewall with Notable Process Path id: cd6d7410-9146-4471-a418-49edba6dadc4 -version: 1 -date: '2023-12-12' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Will Metcalf, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic detects a potential suspicious modification of firewall - rule allowing to execute specific application in public and suspicious windows process file path. This technique was identified when - an adversary and red teams to bypassed firewall file execution restriction in a - targetted host. Take note that this event or command can run by administrator during - testing or allowing legitimate tool or application. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process = "*firewall*" Processes.process = "*allow*" Processes.process = "*add*" Processes.process = "*ENABLE*" - Processes.process IN ("*\\windows\\fonts\\*", "*\\windows\\temp\\*", "*\\users\\public\\*", "*\\windows\\debug\\*", "*\\Users\\Administrator\\Music\\*", "*\\Windows\\servicing\\*", "*\\Users\\Default\\*","*Recycle.bin*", "*\\Windows\\Media\\*", "\\Windows\\repair\\*", "*\\temp\\*", "*\\PerfLogs\\*") - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_modify_system_firewall_with_notable_process_path_filter`' +description: The following analytic detects suspicious modifications to system firewall + rules, specifically allowing execution of applications from notable and potentially + malicious file paths. This detection leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command-line executions involving firewall rule + changes. This activity is significant as it may indicate an adversary attempting + to bypass firewall restrictions to execute malicious files. If confirmed malicious, + this could allow attackers to execute unauthorized code, potentially leading to + further system compromise, data exfiltration, or persistence within the environment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process = "*firewall*" + Processes.process = "*allow*" Processes.process = "*add*" Processes.process = "*ENABLE*" + Processes.process IN ("*\\windows\\fonts\\*", "*\\windows\\temp\\*", "*\\users\\public\\*", + "*\\windows\\debug\\*", "*\\Users\\Administrator\\Music\\*", "*\\Windows\\servicing\\*", + "*\\Users\\Default\\*","*Recycle.bin*", "*\\Windows\\Media\\*", "\\Windows\\repair\\*", + "*\\temp\\*", "*\\PerfLogs\\*") by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_modify_system_firewall_with_notable_process_path_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -68,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/njrat_add_firewall_rule/njrat_firewall_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/njrat_add_firewall_rule/njrat_firewall_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_mof_event_triggered_execution_via_wmi.yml b/detections/endpoint/windows_mof_event_triggered_execution_via_wmi.yml index b4d639814c..ba34e91262 100644 --- a/detections/endpoint/windows_mof_event_triggered_execution_via_wmi.yml +++ b/detections/endpoint/windows_mof_event_triggered_execution_via_wmi.yml @@ -1,25 +1,25 @@ name: Windows MOF Event Triggered Execution via WMI id: e59b5a73-32bf-4467-a585-452c36ae10c1 -version: 2 -date: '2024-04-29' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following anaytic identifies MOFComp.exe loading a MOF file. The - Managed Object Format (MOF) compiler parses a file containing MOF statements and - adds the classes and class instances defined in the file to the WMI repository. - Typically, MOFComp.exe does not reach out to the public internet or load a MOF file - from User Profile paths. A filter and consumer is typically registered in WMI. Review - parallel processes and query WMI subscriptions to gather artifacts. The default - path of mofcomp.exe is C:\Windows\System32\wbem. +description: The following analytic detects the execution of MOFComp.exe loading a + MOF file, often triggered by cmd.exe or powershell.exe, or from unusual paths like + User Profile directories. It leverages Endpoint Detection and Response (EDR) data, + focusing on process names, parent processes, and command-line executions. This activity + is significant as it may indicate an attacker using WMI for persistence or lateral + movement. If confirmed malicious, it could allow the attacker to execute arbitrary + code, maintain persistence, or escalate privileges within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.parent_process_name IN ("cmd.exe", "powershell.exe") Processes.process_name=mofcomp.exe) OR (Processes.process_name=mofcomp.exe - Processes.process IN ("*\\AppData\\Local\\*","*\\Users\\Public\\*")) - by Processes.dest Processes.user Processes.parent_process_name Processes.process_name - Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + Processes.process IN ("*\\AppData\\Local\\*","*\\Users\\Public\\*")) by Processes.dest + Processes.user Processes.parent_process_name Processes.process_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_mof_event_triggered_execution_via_wmi_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -88,7 +88,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/mofcomp.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/mofcomp.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_moveit_transfer_writing_aspx.yml b/detections/endpoint/windows_moveit_transfer_writing_aspx.yml index 26b12bd5a9..afa42c67af 100644 --- a/detections/endpoint/windows_moveit_transfer_writing_aspx.yml +++ b/detections/endpoint/windows_moveit_transfer_writing_aspx.yml @@ -1,19 +1,27 @@ name: Windows MOVEit Transfer Writing ASPX id: c0ed2aca-5666-45b3-813f-ddfac3f3eda0 -version: 1 -date: '2023-06-01' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: experimental type: TTP data_source: - Sysmon EventID 11 -description: The following analytic detects the creation of new ASPX files in the MOVEit Transfer application's "wwwroot" directory. This activity is indicative of the recent critical vulnerability found in MOVEit Transfer, where threat actors have been observed exploiting a zero-day vulnerability to install a malicious ASPX file (e.g., "human2.aspx") in the wwwroot directory. The injected file could then be used to exfiltrate sensitive data, including user credentials and file metadata. The vulnerability affects the MOVEit Transfer managed file transfer software developed by Progress, a subsidiary of US-based Progress Software Corporation. This analytic requires endpoint data reflecting process and filesystem activity. The identified process must be responsible for the creation of new ASPX or ASHX files in the specified directory. +description: The following analytic detects the creation of new ASPX files in the + MOVEit Transfer application's "wwwroot" directory. It leverages endpoint data on + process and filesystem activity to identify processes responsible for creating these + files. This activity is significant as it may indicate exploitation of a critical + zero-day vulnerability in MOVEit Transfer, used by threat actors to install malicious + ASPX files. If confirmed malicious, this could lead to exfiltration of sensitive + data, including user credentials and file metadata, posing a severe risk to the + organization's security. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name=System by _time span=1h Processes.process_id Processes.process_name Processes.dest | `drop_dm_object_name(Processes)` | join process_guid, _time [| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\MOVEitTransfer\\wwwroot\\*") Filesystem.file_name - IN("*.aspx", "*.ashx", "*.asp*") OR Filesystem.file_name IN ("human2.aspx","_human2.aspx") by _time span=1h Filesystem.dest Filesystem.file_create_time + as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\MOVEitTransfer\\wwwroot\\*") + Filesystem.file_name IN("*.aspx", "*.ashx", "*.asp*") OR Filesystem.file_name IN + ("human2.aspx","_human2.aspx") by _time span=1h Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path | `drop_dm_object_name(Filesystem)` | fields _time dest file_create_time file_name file_path process_name process_path process] | dedup file_create_time | table dest file_create_time, file_name, file_path, @@ -26,11 +34,11 @@ known_false_positives: The query is structured in a way that `action` (read, cre is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. references: - - https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023 - - https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/ - - https://www.bleepingcomputer.com/news/security/new-moveit-transfer-zero-day-mass-exploited-in-data-theft-attacks/ - - https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/ - - https://www.mandiant.com/resources/blog/zero-day-moveit-data-theft +- https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023 +- https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/ +- https://www.bleepingcomputer.com/news/security/new-moveit-transfer-zero-day-mass-exploited-in-data-theft-attacks/ +- https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/ +- https://www.mandiant.com/resources/blog/zero-day-moveit-data-theft tags: analytic_story: - MOVEit Transfer Critical Vulnerability @@ -60,13 +68,14 @@ tags: - Filesystem.file_hash - Filesystem.user - Filesystem.file_create_time - - Processes.process_id + - Processes.process_id - Processes.process_name - Processes.dest security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/moveit_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.003/moveit_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_mshta_execution_in_registry.yml b/detections/endpoint/windows_mshta_execution_in_registry.yml index 45f01c7a32..49612a23f0 100644 --- a/detections/endpoint/windows_mshta_execution_in_registry.yml +++ b/detections/endpoint/windows_mshta_execution_in_registry.yml @@ -1,17 +1,18 @@ name: Windows Mshta Execution In Registry id: e13ceade-b673-4d34-adc4-4d9c01729753 -version: 1 -date: '2022-10-14' +version: 2 +date: '2024-05-12' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies the usage of mshta.exe Windows binary - in registry to execute malicious script. This technique was seen in kovter malware - where it create several registry entry which is a encoded javascript and will be - executed by another registry containing mshta and javascript activexobject to execute - the encoded script using wscript.shell. This TTP is a good indication of kovter - malware or other adversaries or threat actors leveraging fileless detection that - survive system reboot. +description: The following analytic detects the execution of mshta.exe via registry + entries to run malicious scripts. It leverages registry activity logs to identify + entries containing "mshta," "javascript," "vbscript," or "WScript.Shell." This behavior + is significant as it indicates potential fileless malware, such as Kovter, which + uses encoded scripts in the registry to persist and execute without files. If confirmed + malicious, this activity could allow attackers to maintain persistence, execute + arbitrary code, and evade traditional file-based detection methods, posing a significant + threat to system integrity and security. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -66,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/mshta_in_registry/sysmon3.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/mshta_in_registry/sysmon3.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_mshta_writing_to_world_writable_path.yml b/detections/endpoint/windows_mshta_writing_to_world_writable_path.yml index 37d114da15..cbe89e7960 100644 --- a/detections/endpoint/windows_mshta_writing_to_world_writable_path.yml +++ b/detections/endpoint/windows_mshta_writing_to_world_writable_path.yml @@ -1,25 +1,44 @@ name: Windows MSHTA Writing to World Writable Path id: efbcf8ee-bc75-47f1-8985-a5c638c4faf0 -version: 1 -date: '2024-03-26' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk data_source: - Sysmon EventID 11 type: TTP status: production -description: This detection identifies instances of the Windows utility `mshta.exe` being used to write files to world-writable directories, a technique commonly leveraged by adversaries to execute malicious scripts or payloads. Starting from 26 February 2024, APT29 has been observed distributing phishing attachments that lead to the download and execution of the ROOTSAW dropper via a compromised website. The ROOTSAW payload, utilizing obfuscated JavaScript, downloads a file named `invite.txt` to the `C:\Windows\Tasks` directory. This file is then decoded and decompressed to execute a malicious payload, often leveraging legitimate Windows binaries for malicious purposes, as seen with `SqlDumper.exe` in this campaign. \ - - The analytic is designed to detect the initial file write operation by `mshta.exe` to directories that are typically writable by any user, such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. This behavior is indicative of an attempt to establish persistence, execute code, or both, as part of a multi-stage infection process. The detection focuses on the use of `mshta.exe` to write to these locations, which is a deviation from the utility's legitimate use cases and thus serves as a strong indicator of compromise (IoC). \ - - The ROOTSAW campaign associated with APT29 utilizes a sophisticated obfuscation technique and leverages multiple stages of payloads, ultimately leading to the execution of the WINELOADER malware. This detection aims to catch the early stages of such attacks, enabling defenders to respond before full compromise occurs. -search: '`sysmon` EventCode=11 Image="*\\mshta.exe" TargetFilename IN ("*\\Windows\\Tasks\\*", "*\\Windows\\Temp\\*", "*\\Windows\\tracing\\*", "*\\Windows\\PLA\\Reports\\*", "*\\Windows\\PLA\\Rules\\*", "*\\Windows\\PLA\\Templates\\*", "*\\Windows\\PLA\\Reports\\en-US\\*", "*\\Windows\\PLA\\Rules\\en-US\\*", "*\\Windows\\Registration\\CRMLog\\*", "*\\Windows\\System32\\Tasks\\*", "*\\Windows\\System32\\Com\\dmp\\*", "*\\Windows\\System32\\LogFiles\\WMI\\*", "*\\Windows\\System32\\Microsoft\\Crypto\\RSA\\MachineKeys\\*", "*\\Windows\\System32\\spool\\PRINTERS\\*", "*\\Windows\\System32\\spool\\SERVERS\\*", "*\\Windows\\System32\\spool\\drivers\\color\\*", "*\\Windows\\System32\\Tasks\\Microsoft\\Windows\\RemoteApp and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\*", "*\\Windows\\SysWOW64\\Com\\dmp\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\RemoteApp and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\System\\*") - | rename Computer as dest, User as user - | stats count min(_time) as firstTime max(_time) as lastTime by dest, user, Image, TargetFilename - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_mshta_writing_to_world_writable_path_filter`' -how_to_implement: The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The search focuses on EventCode 11 where the Image is `mshta.exe` and the TargetFilename is within world-writable directories such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. The detection is designed to catch the initial file write operation by `mshta.exe` to these locations, which is indicative of an attempt to establish persistence or execute malicious code. The analytic can be modified to include additional world-writable directories as needed. -known_false_positives: False positives may occur if legitimate processes are writing to world-writable directories. It is recommended to investigate the context of the file write operation to determine if it is malicious or not. Modify the search to include additional known good paths for `mshta.exe` to reduce false positives. +description: The following analytic identifies instances of `mshta.exe` writing files + to world-writable directories. It leverages Sysmon EventCode 11 logs to detect file + write operations by `mshta.exe` to directories like `C:\Windows\Tasks` and `C:\Windows\Temp`. + This activity is significant as it often indicates an attempt to establish persistence + or execute malicious code, deviating from the utility's legitimate use. If confirmed + malicious, this behavior could lead to the execution of multi-stage payloads, potentially + resulting in full system compromise and unauthorized access to sensitive information. +search: '`sysmon` EventCode=11 Image="*\\mshta.exe" TargetFilename IN ("*\\Windows\\Tasks\\*", + "*\\Windows\\Temp\\*", "*\\Windows\\tracing\\*", "*\\Windows\\PLA\\Reports\\*", + "*\\Windows\\PLA\\Rules\\*", "*\\Windows\\PLA\\Templates\\*", "*\\Windows\\PLA\\Reports\\en-US\\*", + "*\\Windows\\PLA\\Rules\\en-US\\*", "*\\Windows\\Registration\\CRMLog\\*", "*\\Windows\\System32\\Tasks\\*", + "*\\Windows\\System32\\Com\\dmp\\*", "*\\Windows\\System32\\LogFiles\\WMI\\*", "*\\Windows\\System32\\Microsoft\\Crypto\\RSA\\MachineKeys\\*", + "*\\Windows\\System32\\spool\\PRINTERS\\*", "*\\Windows\\System32\\spool\\SERVERS\\*", + "*\\Windows\\System32\\spool\\drivers\\color\\*", "*\\Windows\\System32\\Tasks\\Microsoft\\Windows\\RemoteApp + and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\*", "*\\Windows\\SysWOW64\\Com\\dmp\\*", + "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\RemoteApp + and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\System\\*") + | rename Computer as dest, User as user | stats count min(_time) as firstTime max(_time) + as lastTime by dest, user, Image, TargetFilename | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_mshta_writing_to_world_writable_path_filter`' +how_to_implement: The analytic is designed to be run against Sysmon event logs collected + from endpoints. The analytic requires the Sysmon event logs to be ingested into + Splunk. The search focuses on EventCode 11 where the Image is `mshta.exe` and the + TargetFilename is within world-writable directories such as `C:\Windows\Tasks`, + `C:\Windows\Temp`, and others. The detection is designed to catch the initial file + write operation by `mshta.exe` to these locations, which is indicative of an attempt + to establish persistence or execute malicious code. The analytic can be modified + to include additional world-writable directories as needed. +known_false_positives: False positives may occur if legitimate processes are writing + to world-writable directories. It is recommended to investigate the context of the + file write operation to determine if it is malicious or not. Modify the search to + include additional known good paths for `mshta.exe` to reduce false positives. references: - https://www.mandiant.com/resources/blog/apt29-wineloader-german-political-parties - https://www.zscaler.com/blogs/security-research/european-diplomats-targeted-spikedwine-wineloader @@ -61,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/mshta_tasks_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/mshta_tasks_windows-sysmon.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational diff --git a/detections/endpoint/windows_msiexec_hidewindow_rundll32_execution.yml b/detections/endpoint/windows_msiexec_hidewindow_rundll32_execution.yml index cc002bf578..c26455606b 100644 --- a/detections/endpoint/windows_msiexec_hidewindow_rundll32_execution.yml +++ b/detections/endpoint/windows_msiexec_hidewindow_rundll32_execution.yml @@ -1,24 +1,26 @@ name: Windows MsiExec HideWindow Rundll32 Execution id: 9683271d-92e4-43b5-a907-1983bfb9f7fd -version: 1 -date: '2024-01-03' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a msiexec.exe process with hidewindow rundll32 process commandline. - One such tactic involves utilizing system processes like "msiexec," "hidewindow," and "rundll32" through command-line execution. - By leveraging these legitimate processes, QakBot masks its malicious operations, hiding behind seemingly normal system activities. - This clandestine approach allows the trojan to carry out unauthorized tasks discreetly, such as downloading additional payloads, - executing malicious code, or establishing communication with remote servers. This obfuscation through trusted system processes - enables QakBot to operate stealthily, evading detection by security mechanisms and perpetuating its harmful actions without raising suspicion. +description: The following analytic detects the execution of the msiexec.exe process + with the /HideWindow and rundll32 command-line parameters. It leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process creation events + and command-line arguments. This activity is significant because it is a known tactic + used by malware like QakBot to mask malicious operations under legitimate system + processes. If confirmed malicious, this behavior could allow an attacker to download + additional payloads, execute malicious code, or establish communication with remote + servers, thereby evading detection and maintaining persistence. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name = msiexec.exe Processes.process = "* /HideWindow *" Processes.process = "* rundll32*" - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name + = msiexec.exe Processes.process = "* /HideWindow *" Processes.process = "* rundll32*" + by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_msiexec_hidewindow_rundll32_execution_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -29,7 +31,8 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: Other possible 3rd party msi software installers use this technique as part of its installation process. +known_false_positives: Other possible 3rd party msi software installers use this technique + as part of its installation process. references: - https://twitter.com/Max_Mal_/status/1736392741758611607 - https://twitter.com/1ZRR4H/status/1735944522075386332 @@ -39,7 +42,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: a msiexec parent process with /hidewindow rundll32 process commandline in $dest$ + message: a msiexec parent process with /hidewindow rundll32 process commandline + in $dest$ mitre_attack_id: - T1218.007 - T1218 @@ -71,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.007/msiexec-hidewindow-rundll32/hidewndw-rundll32.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.007/msiexec-hidewindow-rundll32/hidewndw-rundll32.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_msiexec_spawn_windbg.yml b/detections/endpoint/windows_msiexec_spawn_windbg.yml index 5b1532788c..39ee45ee9c 100644 --- a/detections/endpoint/windows_msiexec_spawn_windbg.yml +++ b/detections/endpoint/windows_msiexec_spawn_windbg.yml @@ -1,21 +1,37 @@ name: Windows MSIExec Spawn WinDBG id: 9a18f7c2-1fe3-47b8-9467-8b3976770a30 -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This analytic identifies the unusual behavior of MSIExec spawning WinDBG. It is designed to detect potential malicious activities. The search specifically looks for instances where the parent process name is 'msiexec.exe' and the process name is 'windbg.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. +description: The following analytic identifies the unusual behavior of MSIExec spawning + WinDBG. It detects this activity by analyzing endpoint telemetry data, specifically + looking for instances where 'msiexec.exe' is the parent process of 'windbg.exe'. + This behavior is significant as it may indicate an attempt to debug or tamper with + system processes, which is uncommon in typical user activity and could signify malicious + intent. If confirmed malicious, this activity could allow an attacker to manipulate + or inspect running processes, potentially leading to privilege escalation or persistence + within the environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=msiexec.exe Processes.process_name=windbg.exe by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process_path Processes.parent_process Processes.process_name Processes.process_path - Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `windows_msiexec_spawn_windbg_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives will only be present if the MSIExec process legitimately spawns WinDBG. Filter as needed. + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=msiexec.exe + Processes.process_name=windbg.exe by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process_path Processes.parent_process Processes.process_name Processes.process_path + Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `windows_msiexec_spawn_windbg_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: False positives will only be present if the MSIExec process + legitimately spawns WinDBG. Filter as needed. references: - https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2023-10-25-IOCs-from-DarkGate-activity.txt tags: @@ -66,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.007/atomic_red_team/windbg_msiexec.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.007/atomic_red_team/windbg_msiexec.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_multi_hop_proxy_tor_website_query.yml b/detections/endpoint/windows_multi_hop_proxy_tor_website_query.yml index 4f8a5b9c7c..ac04567ed7 100644 --- a/detections/endpoint/windows_multi_hop_proxy_tor_website_query.yml +++ b/detections/endpoint/windows_multi_hop_proxy_tor_website_query.yml @@ -1,21 +1,24 @@ name: Windows Multi hop Proxy TOR Website Query id: 4c2d198b-da58-48d7-ba27-9368732d0054 -version: 1 -date: '2022-09-16' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a dns query to a known TOR proxy website. - This technique was seen in several adversaries, threat actors and malware like AgentTesla - to To disguise the source of its malicious traffic. adversaries may chain together - multiple proxies. This Anomaly detection might be a good pivot for a process trying - to download or use TOR proxies in a compromised host machine. +description: The following analytic identifies DNS queries to known TOR proxy websites, + such as "*.torproject.org" and "www.theonionrouter.com". It leverages Sysmon EventCode + 22 to detect these queries by monitoring DNS query events from endpoints. This activity + is significant because adversaries often use TOR proxies to disguise the source + of their malicious traffic, making it harder to trace their actions. If confirmed + malicious, this behavior could indicate an attempt to obfuscate network traffic, + potentially allowing attackers to exfiltrate data or communicate with command and + control servers undetected. data_source: - Sysmon EventID 22 search: '`sysmon` EventCode=22 QueryName IN ("*.torproject.org", "www.theonionrouter.com") | stats count min(_time) as firstTime max(_time) as lastTime by Image QueryName - QueryStatus ProcessId Computer | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_multi_hop_proxy_tor_website_query_filter`' + QueryStatus ProcessId Computer | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_multi_hop_proxy_tor_website_query_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 22 dns query events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the @@ -56,7 +59,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_tor_dns_query/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/agent_tesla/agent_tesla_tor_dns_query/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_multiple_account_passwords_changed.yml b/detections/endpoint/windows_multiple_account_passwords_changed.yml index 67861e1700..a699fadee2 100644 --- a/detections/endpoint/windows_multiple_account_passwords_changed.yml +++ b/detections/endpoint/windows_multiple_account_passwords_changed.yml @@ -1,22 +1,30 @@ name: Windows Multiple Account Passwords Changed id: faefb681-14be-4f0d-9cac-0bc0160c7280 -version: 1 -date: '2024-02-20' +version: 2 +date: '2024-05-19' author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4724 type: TTP status: production -description: This Splunk detection identifies situations where over five unique Windows account passwords are changed within a 10-minute interval, captured by Event Code 4724 in the Windows Security Event Log. The query utilizes the wineventlog_security dataset, organizing data into 10-minute periods to monitor the count and distinct count of TargetUserName, the accounts with altered passwords. Rapid password changes across multiple accounts are atypical and might indicate unauthorized access or an internal actor compromising account security. Teams should calibrate the detection's threshold and timeframe to fit their specific operational context. -search: ' `wineventlog_security` EventCode=4724 status=success - | bucket span=10m _time - | stats count dc(user) as unique_users values(user) as user by EventCode signature _time src_user SubjectDomainName TargetDomainName Logon_ID - | where unique_users > 5 - | `windows_multiple_account_passwords_changed_filter`' +description: The following analytic detects instances where more than five unique + Windows account passwords are changed within a 10-minute interval. It leverages + Event Code 4724 from the Windows Security Event Log, using the wineventlog_security + dataset to monitor and count distinct TargetUserName values. This behavior is significant + as rapid password changes across multiple accounts are unusual and may indicate + unauthorized access or internal compromise. If confirmed malicious, this activity + could lead to widespread account compromise, unauthorized access to sensitive information, + and potential disruption of services. +search: ' `wineventlog_security` EventCode=4724 status=success | bucket span=10m _time + | stats count dc(user) as unique_users values(user) as user by EventCode signature + _time src_user SubjectDomainName TargetDomainName Logon_ID | where unique_users + > 5 | `windows_multiple_account_passwords_changed_filter`' how_to_implement: To successfully implement this search, you need to be ingesting - Domain Controller events with the Windows TA. The Advanced Security Audit policy setting - `Audit User Account Management` within `Account Management` needs to be enabled. -known_false_positives: Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. + Domain Controller events with the Windows TA. The Advanced Security Audit policy + setting `Audit User Account Management` within `Account Management` needs to be + enabled. +known_false_positives: Service accounts may be responsible for the creation, deletion + or modification of accounts for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/ tags: @@ -25,7 +33,8 @@ tags: asset_type: Endpoint confidence: 60 impact: 40 - message: User $src_user$ changed the passwords of multiple accounts in a short period of time. + message: User $src_user$ changed the passwords of multiple accounts in a short period + of time. mitre_attack_id: - T1098 - T1078 @@ -54,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_passwords_changed/windows_multiple_passwords_changed.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_passwords_changed/windows_multiple_passwords_changed.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_multiple_accounts_deleted.yml b/detections/endpoint/windows_multiple_accounts_deleted.yml index 01bffce3e1..9b49d44623 100644 --- a/detections/endpoint/windows_multiple_accounts_deleted.yml +++ b/detections/endpoint/windows_multiple_accounts_deleted.yml @@ -1,22 +1,29 @@ name: Windows Multiple Accounts Deleted id: 49c0d4d6-c55d-4d3a-b3d5-7709fafed70d -version: 1 -date: '2024-02-21' +version: 2 +date: '2024-05-21' author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4726 type: TTP status: production -description: The following analytic flags when more than five unique Windows accounts are deleted within a 10-minute period, identified by Event Code 4726 in the Windows Security Event Log. Using the wineventlog_security dataset, it segments data into 10-minute intervals to monitor account deletions, a pattern that could suggest malicious intent like an attacker erasing traces. Teams should adjust the detection's threshold and timeframe to suit their specific environment. -search: ' `wineventlog_security` EventCode=4726 status=success - | bucket span=10m _time - | stats count dc(user) as unique_users values(user) as user by EventCode signature _time src_user SubjectDomainName TargetDomainName Logon_ID - | where unique_users > 5 - | `windows_multiple_accounts_deleted_filter`' +description: The following analytic detects the deletion of more than five unique + Windows accounts within a 10-minute period, using Event Code 4726 from the Windows + Security Event Log. It leverages the `wineventlog_security` dataset, segmenting + data into 10-minute intervals to identify suspicious account deletions. This activity + is significant as it may indicate an attacker attempting to erase traces of their + actions. If confirmed malicious, this could lead to unauthorized access removal, + hindering incident response and forensic investigations. +search: ' `wineventlog_security` EventCode=4726 status=success | bucket span=10m _time + | stats count dc(user) as unique_users values(user) as user by EventCode signature + _time src_user SubjectDomainName TargetDomainName Logon_ID | where unique_users + > 5 | `windows_multiple_accounts_deleted_filter`' how_to_implement: To successfully implement this search, you need to be ingesting - Domain Controller events with the Windows TA. The Advanced Security Audit policy setting - `Audit User Account Management` within `Account Management` needs to be enabled. -known_false_positives: Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. + Domain Controller events with the Windows TA. The Advanced Security Audit policy + setting `Audit User Account Management` within `Account Management` needs to be + enabled. +known_false_positives: Service accounts may be responsible for the creation, deletion + or modification of accounts for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/ tags: @@ -54,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_accounts_deleted/windows_multiple_accounts_deleted.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_accounts_deleted/windows_multiple_accounts_deleted.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_multiple_accounts_disabled.yml b/detections/endpoint/windows_multiple_accounts_disabled.yml index ba814f89cc..38cc7c019c 100644 --- a/detections/endpoint/windows_multiple_accounts_disabled.yml +++ b/detections/endpoint/windows_multiple_accounts_disabled.yml @@ -1,22 +1,30 @@ name: Windows Multiple Accounts Disabled id: 5d93894e-befa-4429-abde-7fc541020b7b -version: 1 -date: '2024-02-21' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4725 type: TTP status: production -description: This Splunk detection focuses on instances where more than five unique Windows accounts are disabled within a 10-minute window, as indicated by Event Code 4725 in the Windows Security Event Log. The query analyzes the wineventlog_security dataset, grouping data into 10-minute segments, and tracks the count and distinct count of TargetUserName, the accounts being disabled. This pattern of disabling multiple accounts rapidly is unusual and could signal internal policy breaches or an external attacker's attempt to disrupt normal operations. Teams are advised to tailor the threshold and timeframe of this detection to their environment's specifics -search: ' `wineventlog_security` EventCode=4725 status=success - | bucket span=10m _time - | stats count dc(user) as unique_users values(user) as user by EventCode signature _time src_user SubjectDomainName TargetDomainName Logon_ID - | where unique_users > 5 - | `windows_multiple_accounts_disabled_filter`' +description: The following analytic identifies instances where more than five unique + Windows accounts are disabled within a 10-minute window, as indicated by Event Code + 4725 in the Windows Security Event Log. It leverages the wineventlog_security dataset, + grouping data into 10-minute segments and tracking the count and distinct count + of TargetUserName. This behavior is significant as it may indicate internal policy + breaches or an external attacker's attempt to disrupt operations. If confirmed malicious, + this activity could lead to widespread account lockouts, hindering user access and + potentially disrupting business operations. +search: ' `wineventlog_security` EventCode=4725 status=success | bucket span=10m _time + | stats count dc(user) as unique_users values(user) as user by EventCode signature + _time src_user SubjectDomainName TargetDomainName Logon_ID | where unique_users + > 5 | `windows_multiple_accounts_disabled_filter`' how_to_implement: To successfully implement this search, you need to be ingesting - Domain Controller events with the Windows TA. The Advanced Security Audit policy setting - `Audit User Account Management` within `Account Management` needs to be enabled. -known_false_positives: Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. + Domain Controller events with the Windows TA. The Advanced Security Audit policy + setting `Audit User Account Management` within `Account Management` needs to be + enabled. +known_false_positives: Service accounts may be responsible for the creation, deletion + or modification of accounts for legitimate purposes. Filter as needed. references: - https://attack.mitre.org/techniques/T1098/ tags: @@ -54,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_accounts_disabled/windows_multiple_accounts_disabled.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/windows_multiple_accounts_disabled/windows_multiple_accounts_disabled.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_multiple_disabled_users_failed_to_authenticate_wth_kerberos.yml b/detections/endpoint/windows_multiple_disabled_users_failed_to_authenticate_wth_kerberos.yml index c98402540b..0fc83fc237 100644 --- a/detections/endpoint/windows_multiple_disabled_users_failed_to_authenticate_wth_kerberos.yml +++ b/detections/endpoint/windows_multiple_disabled_users_failed_to_authenticate_wth_kerberos.yml @@ -1,25 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4768 -date: '2021-04-14' -description: 'The following analytic identifies one source endpoint failing to authenticate +date: '2024-05-28' +description: 'The following analytic detects a single source endpoint failing to authenticate with 30 unique disabled domain users using the Kerberos protocol within 5 minutes. - This behavior could represent an adversary performing a Password Spraying attack - against an Active Directory environment using Kerberos to obtain initial access - or elevate privileges. Active Directory environments can be very different depending - on the organization. Users should test this detection and customize the arbitrary - threshold when needed. As attackers progress in a breach, mistakes will be made. - In certain scenarios, adversaries may execute a password spraying attack against - disabled users. Event 4768 is generated every time the Key Distribution Center issues - a Kerberos Ticket Granting Ticket (TGT). Failure code `0x12` stands for `clients - credentials have been revoked` (account disabled, expired or locked out). - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will only trigger on domain controllers, not on member - servers or workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' + It leverages Windows Security Event 4768, focusing on failure code `0x12`, indicating + revoked credentials. This activity is significant as it may indicate a Password + Spraying attack targeting disabled accounts, a tactic used by adversaries to gain + initial access or elevate privileges. If confirmed malicious, this could lead to + unauthorized access or privilege escalation within the Active Directory environment, + posing a severe security risk.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -55,7 +45,7 @@ tags: - name: IpAddress type: IP Address role: - - Attacker + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security @@ -70,9 +60,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_disabled_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_disabled_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: xmlwineventlog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_invalid_users_fail_to_authenticate_using_kerberos.yml b/detections/endpoint/windows_multiple_invalid_users_fail_to_authenticate_using_kerberos.yml index d738b9a399..a369d3a1f0 100644 --- a/detections/endpoint/windows_multiple_invalid_users_fail_to_authenticate_using_kerberos.yml +++ b/detections/endpoint/windows_multiple_invalid_users_fail_to_authenticate_using_kerberos.yml @@ -1,25 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4768 -date: '2021-04-14' -description: 'The following analytic identifies one source endpoint failing to authenticate - with 30 unique invalid domain users using the Kerberos protocol. This behavior could - represent an adversary performing a Password Spraying attack against an Active Directory - environment using Kerberos to obtain initial access or elevate privileges. Active - Directory environments can be very different depending on the organization. Users - should test this detection and customize the arbitrary threshold when needed. As - attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries - may execute a password spraying attack using an invalid list of users. Event 4768 - is generated every time the Key Distribution Center issues a Kerberos Ticket Granting - Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` - (the attempted user is not a valid domain user). - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will only trigger on domain controllers, not on member - servers or workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' +date: '2024-05-21' +description: 'The following analytic identifies a source endpoint failing to authenticate + with 30 unique invalid domain users using the Kerberos protocol. This detection + leverages EventCode 4768, specifically looking for failure code 0x6, indicating + the user is not found in the Kerberos database. This activity is significant as + it may indicate a Password Spraying attack, where an adversary attempts to gain + initial access or elevate privileges. If confirmed malicious, this could lead to + unauthorized access or privilege escalation within the Active Directory environment, + posing a significant security risk.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -33,7 +23,7 @@ references: - https://attack.mitre.org/techniques/T1110/003/ search: '`wineventlog_security` EventCode=4768 TargetUserName!=*$ Status=0x6 | bucket span=5m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) - as user by _time, IpAddress | where unique_accounts > 30 | `windows_multiple_invalid_users_fail_to_authenticate_using_kerberos_filter` ' + as user by _time, IpAddress | where unique_accounts > 30 | `windows_multiple_invalid_users_fail_to_authenticate_using_kerberos_filter`' status: production tags: analytic_story: @@ -55,7 +45,7 @@ tags: - name: IpAddress type: Endpoint role: - - Attacker + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security @@ -70,9 +60,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_invalid_users_failed_to_authenticate_using_ntlm.yml b/detections/endpoint/windows_multiple_invalid_users_failed_to_authenticate_using_ntlm.yml index 55899adff2..4a0d9fefbf 100644 --- a/detections/endpoint/windows_multiple_invalid_users_failed_to_authenticate_using_ntlm.yml +++ b/detections/endpoint/windows_multiple_invalid_users_failed_to_authenticate_using_ntlm.yml @@ -1,26 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4776 -date: '2021-04-15' -description: 'The following analytic identifies one source endpoint failing to authenticate - with 30 unique invalid users using the NTLM protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using NTLM to obtain initial access or elevate privileges. Active Directory environments - can be very different depending on the organization. Users should test this detection - and customize the arbitrary threshold when needed. As attackers progress in a breach, - mistakes will be made. In certain scenarios, adversaries may execute a password - spraying attack using an invalid list of users. Event 4776 is generated on the computer - that is authoritative for the provided credentials. For domain accounts, the domain - controller is authoritative. For local accounts, the local computer is authoritative. - Error code 0xC0000064 stands for `The username you typed does not exist` (the attempted - user is a legitimate domain user). - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will only trigger on domain controllers, not on member - servers or workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source workstation name and attempted user accounts.' +date: '2024-05-17' +description: 'The following analytic detects a single source endpoint failing to authenticate + with 30 unique invalid users using the NTLM protocol. It leverages EventCode 4776 + from Domain Controller logs, focusing on error code 0xC0000064, which indicates + non-existent usernames. This behavior is significant as it may indicate a Password + Spraying attack, where an adversary attempts to gain initial access or elevate privileges. + If confirmed malicious, this activity could lead to unauthorized access, privilege + escalation, and potential compromise of sensitive information within the Active + Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled. @@ -69,9 +58,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_ntlm_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_ntlm_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_users_fail_to_authenticate_wth_explicitcredentials.yml b/detections/endpoint/windows_multiple_users_fail_to_authenticate_wth_explicitcredentials.yml index 9d433582d8..2c0916a271 100644 --- a/detections/endpoint/windows_multiple_users_fail_to_authenticate_wth_explicitcredentials.yml +++ b/detections/endpoint/windows_multiple_users_fail_to_authenticate_wth_explicitcredentials.yml @@ -1,24 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4648 -date: '2021-04-13' +date: '2024-05-17' description: 'The following analytic identifies a source user failing to authenticate - with 30 unique users using explicit credentials on a host. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - to obtain initial access or elevate privileges. Active Directory environments can - be very different depending on the organization. Users should test this detection - and customize the arbitrary threshold when needed. Event 4648 is generated when - a process attempts an account logon by explicitly specifying that accounts credentials. - This event generates on domain controllers, member servers, and workstations. - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will trigger on the potenfially malicious host, perhaps - controlled via a trojan or operated by an insider threat, from where a password - spraying attack is being executed. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source account, attempted user accounts and the endpoint were - the behavior was identified.' + with 30 unique users using explicit credentials on a host. It leverages Windows + Event 4648, which is generated when a process attempts an account logon by explicitly + specifying account credentials. This detection is significant as it may indicate + a Password Spraying attack, where an adversary attempts to gain initial access or + elevate privileges within an Active Directory environment. If confirmed malicious, + this activity could lead to unauthorized access, privilege escalation, and potential + compromise of sensitive information.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -37,7 +28,7 @@ references: search: ' `wineventlog_security` EventCode=4648 Caller_User_Name!=*$ Target_User_Name!=*$ | bucket span=5m _time | stats dc(Target_User_Name) AS unique_accounts values(Target_User_Name) as tried_account by _time, Computer, Caller_User_Name | where unique_accounts > - 30 | `windows_multiple_users_fail_to_authenticate_wth_explicitcredentials_filter` ' + 30 | `windows_multiple_users_fail_to_authenticate_wth_explicitcredentials_filter`' status: production tags: analytic_story: @@ -70,9 +61,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_explicit_credential_spray_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_explicit_credential_spray_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_host_using_ntlm.yml b/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_host_using_ntlm.yml index 43054b767c..1ca6318c8d 100644 --- a/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_host_using_ntlm.yml +++ b/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_host_using_ntlm.yml @@ -1,24 +1,14 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4776 -date: '2021-04-13' -description: 'The following analytic identifies one source endpoint failing to authenticate - with 30 unique valid users using the NTLM protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using NTLM to obtain initial access or elevate privileges. Active Directory environments - can be very different depending on the organization. Users should test this detection - and customize the arbitrary threshold when needed. Event 4776 is generated on the - computer that is authoritative for the provided credentials. For domain accounts, - the domain controller is authoritative. For local accounts, the local computer is - authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted - user is a legitimate domain user). - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will only trigger on domain controllers, not on member - servers or workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source workstation name and attempted user accounts.' +date: '2024-05-26' +description: 'The following analytic identifies a single source endpoint failing to + authenticate with 30 unique valid users using the NTLM protocol. It leverages EventCode + 4776 from Domain Controller logs, focusing on error code 0xC000006A, which indicates + a bad password. This behavior is significant as it may indicate a Password Spraying + attack, where an adversary attempts to gain initial access or elevate privileges. + If confirmed malicious, this activity could lead to unauthorized access to sensitive + information or further compromise of the Active Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled. @@ -67,9 +57,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_ntlm_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_ntlm_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_process.yml b/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_process.yml index 2a396e394c..596020b269 100644 --- a/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_process.yml +++ b/detections/endpoint/windows_multiple_users_failed_to_authenticate_from_process.yml @@ -1,24 +1,14 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4625 -date: '2021-04-13' -description: 'The following analytic identifies a source process name failing to authenticate - with 30 uniquer users. This behavior could represent an adversary performing a Password - Spraying attack against an Active Directory environment to obtain initial access - or elevate privileges. Active Directory environments can be very different depending - on the organization. Users should test this detection and customize the arbitrary - threshold when needed. Event 4625 generates on domain controllers, member servers, - and workstations when an account fails to logon. Logon Type 2 describes an iteractive - logon attempt. - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will trigger on the potenfially malicious host, perhaps - controlled via a trojan or operated by an insider threat, from where a password - spraying attack is being executed. This could be a domain controller as well as - a member server or workstation. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source process name, source account and attempted user accounts.' +date: '2024-05-25' +description: 'The following analytic detects a source process failing to authenticate + with 30 unique users, indicating a potential Password Spraying attack. It leverages + Windows Event 4625 with Logon Type 2, collected from domain controllers, member + servers, and workstations. This activity is significant as it may represent an adversary + attempting to gain initial access or elevate privileges within an Active Directory + environment. If confirmed malicious, this could lead to unauthorized access, privilege + escalation, or further compromise of the network, posing a severe security risk.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -35,8 +25,8 @@ references: - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/basic-audit-logon-events search: ' `wineventlog_security` EventCode=4625 Logon_Type=2 ProcessName!="-" | bucket span=5m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) - as tried_accounts by _time, ProcessName, SubjectUserName, Computer | rename Computer as dest | where unique_accounts - > 30 | `windows_multiple_users_failed_to_authenticate_from_process_filter`' + as tried_accounts by _time, ProcessName, SubjectUserName, Computer | rename Computer + as dest | where unique_accounts > 30 | `windows_multiple_users_failed_to_authenticate_from_process_filter`' status: production tags: analytic_story: @@ -71,9 +61,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_multiple_users_from_process_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_multiple_users_from_process_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_users_failed_to_authenticate_using_kerberos.yml b/detections/endpoint/windows_multiple_users_failed_to_authenticate_using_kerberos.yml index e45b8f4cf1..3b007a7059 100644 --- a/detections/endpoint/windows_multiple_users_failed_to_authenticate_using_kerberos.yml +++ b/detections/endpoint/windows_multiple_users_failed_to_authenticate_using_kerberos.yml @@ -1,23 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4771 -date: '2021-04-08' -description: 'The following analytic identifies one source endpoint failing to authenticate - with 30 unique users using the Kerberos protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using Kerberos to obtain initial access or elevate privileges. Active Directory - environments can be very different depending on the organization. Users should test - this detection and customize the arbitrary threshold when needed. Event 4771 is - generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting - Ticket (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted - user is a legitimate domain user). - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will only trigger on domain controllers, not on member - servers or workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' +date: '2024-05-16' +description: 'The following analytic identifies a single source endpoint failing to + authenticate with 30 unique users using the Kerberos protocol. It leverages EventCode + 4771 with Status 0x18, indicating wrong password attempts, and aggregates these + events over a 5-minute window. This behavior is significant as it may indicate a + Password Spraying attack, where an adversary attempts to gain initial access or + elevate privileges in an Active Directory environment. If confirmed malicious, this + activity could lead to unauthorized access, privilege escalation, and potential + compromise of sensitive information.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -70,9 +62,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_multiple_users_remotely_failed_to_authenticate_from_host.yml b/detections/endpoint/windows_multiple_users_remotely_failed_to_authenticate_from_host.yml index 3a00966b45..8084bdfb50 100644 --- a/detections/endpoint/windows_multiple_users_remotely_failed_to_authenticate_from_host.yml +++ b/detections/endpoint/windows_multiple_users_remotely_failed_to_authenticate_from_host.yml @@ -1,24 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4625 -date: '2021-04-13' +date: '2024-05-28' description: 'The following analytic identifies a source host failing to authenticate - against a remote host with 30 unique users. This behavior could represent an adversary - performing a Password Spraying attack against an Active Directory environment to - obtain initial access or elevate privileges. Active Directory environments can be - very different depending on the organization. Users should test this detection and - customize the arbitrary threshold when needed. Event 4625 documents each and every - failed attempt to logon to the local computer. This event generates on domain controllers, - member servers, and workstations. Logon Type 3 describes an remote authentication - attempt. - - This logic can be used for real time security monitoring as well as threat hunting - exercises. This detection will trigger on the host that is the target of the password - spraying attack. This could be a domain controller as well as a member server or - workstation. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source process name, source account and attempted user accounts.' + against a remote host with 30 unique users. It leverages Windows Event 4625 with + Logon Type 3, indicating remote authentication attempts. This behavior is significant + as it may indicate a Password Spraying attack, where an adversary attempts to gain + initial access or elevate privileges in an Active Directory environment. If confirmed + malicious, this activity could lead to unauthorized access, privilege escalation, + and potential compromise of sensitive information. This detection is crucial for + real-time security monitoring and threat hunting.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -36,7 +27,7 @@ references: - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/basic-audit-logon-events search: ' `wineventlog_security` EventCode=4625 Logon_Type=3 IpAddress!="-" | bucket span=5m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) - as tried_accounts by _time, IpAddress, Computer | rename Computer as dest| where unique_accounts > 30 | `windows_multiple_users_remotely_failed_to_authenticate_from_host_filter` ' + as tried_accounts by _time, IpAddress, Computer | rename Computer as dest| where unique_accounts > 30 | `windows_multiple_users_remotely_failed_to_authenticate_from_host_filter`' status: production tags: analytic_story: @@ -69,9 +60,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_remote_spray_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_remote_spray_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: TTP -version: 2 +version: 3 diff --git a/detections/endpoint/windows_new_inprocserver32_added.yml b/detections/endpoint/windows_new_inprocserver32_added.yml index 25d9966da4..0b9156b74e 100644 --- a/detections/endpoint/windows_new_inprocserver32_added.yml +++ b/detections/endpoint/windows_new_inprocserver32_added.yml @@ -1,21 +1,30 @@ name: Windows New InProcServer32 Added id: 0fa86e31-0f73-4ec7-9ca3-dc88e117f1db -version: 1 -date: '2024-03-20' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk data_source: - Sysmon EventID 13 type: Hunting status: production -description: This analytic is designed to detect the addition of new InProcServer32 registry keys, which could indicate suspicious or malicious activity on a Windows endpoint. The InProcServer32 registry key specifies the path to a COM object that can be loaded into the process space of calling processes. Malware often abuses this mechanism to achieve persistence or execute code by registering a new InProcServer32 key pointing to a malicious DLL. By monitoring for the creation of new InProcServer32 keys, this analytic helps identify potential threats that leverage COM hijacking or similar techniques for execution and persistence. Understanding the normal behavior of legitimate software in your environment will aid in distinguishing between benign and malicious use of InProcServer32 modifications. -search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\InProcServer32\\*" by Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.dest Registry.process_guid Registry.user - | `drop_dm_object_name(Registry)` - |`security_content_ctime(firstTime)` +description: The following analytic detects the addition of new InProcServer32 registry + keys on Windows endpoints. It leverages data from the Endpoint.Registry datamodel + to identify changes in registry paths associated with InProcServer32. This activity + is significant because malware often uses this mechanism to achieve persistence + or execute malicious code by registering a new InProcServer32 key pointing to a + harmful DLL. If confirmed malicious, this could allow an attacker to persist in + the environment or execute arbitrary code, posing a significant threat to system + integrity and security. +search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry + where Registry.registry_path="*\\InProcServer32\\*" by Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.dest Registry.process_guid + Registry.user | `drop_dm_object_name(Registry)` |`security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_new_inprocserver32_added_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. -known_false_positives: False positives are expected. Filtering will be needed to properly reduce legitimate applications from the results. +known_false_positives: False positives are expected. Filtering will be needed to properly + reduce legitimate applications from the results. references: - https://www.netspi.com/blog/technical/red-team-operations/microsoft-outlook-remote-code-execution-cve-2024-21378/ tags: @@ -24,7 +33,8 @@ tags: asset_type: Endpoint confidence: 20 impact: 10 - message: A new InProcServer32 registry key was added to a Windows endpoint. This could indicate suspicious or malicious activity on the $dest$ . + message: A new InProcServer32 registry key was added to a Windows endpoint. This + could indicate suspicious or malicious activity on the $dest$ . mitre_attack_id: - T1112 observable: @@ -51,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/cve-2024-21378/inprocserver32_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/cve-2024-21378/inprocserver32_windows-sysmon.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational diff --git a/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml b/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml index 3280ec3e5b..b66eded1e2 100644 --- a/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml +++ b/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml @@ -1,15 +1,17 @@ name: Windows Ngrok Reverse Proxy Usage id: e2549f2c-0aef-408a-b0c1-e0f270623436 -version: 2 -date: '2023-01-12' +version: 3 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the use of ngrok.exe being utilized - on the Windows operating system. Unfortunately, there is no original file name for - Ngrok, so it may be worth an additional hunt to identify any command-line arguments. - The sign of someone using Ngrok is not malicious, however, more recently it has - become an adversary tool. +description: The following analytic detects the execution of ngrok.exe on a Windows + operating system. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and command-line arguments. This activity is significant + because while ngrok is a legitimate tool for creating secure tunnels, it is increasingly + used by adversaries to bypass network defenses and establish reverse proxies. If + confirmed malicious, this could allow attackers to exfiltrate data, maintain persistence, + or facilitate further attacks by tunneling traffic through the compromised system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -83,7 +85,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_nirsoft_advancedrun.yml b/detections/endpoint/windows_nirsoft_advancedrun.yml index c967cafb8f..f903662971 100644 --- a/detections/endpoint/windows_nirsoft_advancedrun.yml +++ b/detections/endpoint/windows_nirsoft_advancedrun.yml @@ -1,15 +1,18 @@ name: Windows NirSoft AdvancedRun id: bb4f3090-7ae4-11ec-897f-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of AdvancedRun.exe. AdvancedRun.exe - has similar capabilities as other remote programs like psexec. AdvancedRun may also - ingest a configuration file with all settings defined and perform its activity. - The analytic is written in a way to identify a renamed binary and also the common - command-line arguments. +description: The following analytic detects the execution of AdvancedRun.exe, a tool + with capabilities similar to remote administration programs like PsExec. It identifies + the process by its name or original file name and flags common command-line arguments. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process and command-line telemetry. Monitoring this activity is crucial + as AdvancedRun can be used for remote code execution and configuration-based automation. + If malicious, this could allow attackers to execute arbitrary commands, escalate + privileges, or maintain persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1588.002/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1588.002/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_njrat_fileless_storage_via_registry.yml b/detections/endpoint/windows_njrat_fileless_storage_via_registry.yml index 8e70d16024..d35c591ffe 100644 --- a/detections/endpoint/windows_njrat_fileless_storage_via_registry.yml +++ b/detections/endpoint/windows_njrat_fileless_storage_via_registry.yml @@ -1,24 +1,27 @@ name: Windows Njrat Fileless Storage via Registry id: a5fffbbd-271f-4980-94ed-4fbf17f0af1c -version: 1 -date: '2023-09-14' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The following analytic identifies a suspicious registry modification associated with NjRat, - a telltale sign of its fileless technique. NjRat employs this method to manage its keylogs and execute downloaded DLL module plugins discreetly on the compromised host. - This approach is particularly effective at evading conventional file-based detection systems, as it stores indicators of compromise (IOCs) in the registry. - Leveraging this TTP (Tactics, Techniques, and Procedures) detection can significantly enhance the identification of NjRAT infections. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry - where Registry.registry_path="*\\[kl]" OR Registry.registry_value_data IN ("*[ENTER]*", "*[TAP]*", "*[Back]*") - by Registry.dest Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name Registry.registry_value_name - | `drop_dm_object_name(Registry)` - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `windows_njrat_fileless_storage_via_registry_filter`' +description: The following analytic detects suspicious registry modifications indicative + of NjRat's fileless storage technique. It leverages the Endpoint.Registry data model + to identify specific registry paths and values commonly used by NjRat for keylogging + and executing DLL plugins. This activity is significant as it helps evade traditional + file-based detection systems, making it crucial for SOC analysts to monitor. If + confirmed malicious, this behavior could allow attackers to persist on the host, + execute arbitrary code, and capture sensitive keystrokes, leading to potential data + breaches and further system compromise. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\[kl]" + OR Registry.registry_value_data IN ("*[ENTER]*", "*[TAP]*", "*[Back]*") by Registry.dest + Registry.user Registry.registry_path Registry.registry_value_data Registry.registry_key_name + Registry.registry_value_name | `drop_dm_object_name(Registry)` | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `windows_njrat_fileless_storage_via_registry_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, @@ -26,7 +29,7 @@ how_to_implement: To successfully implement this search you need to be ingesting endpoint product. known_false_positives: unknown references: - - https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat +- https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat tags: analytic_story: - NjRAT @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.011/njrat_fileless_registry_entry/njrat_registry.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.011/njrat_fileless_registry_entry/njrat_registry.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_non_discord_app_access_discord_leveldb.yml b/detections/endpoint/windows_non_discord_app_access_discord_leveldb.yml index 965d47f826..d4bd14b414 100644 --- a/detections/endpoint/windows_non_discord_app_access_discord_leveldb.yml +++ b/detections/endpoint/windows_non_discord_app_access_discord_leveldb.yml @@ -1,23 +1,25 @@ name: Windows Non Discord App Access Discord LevelDB id: 1166360c-d495-45ac-87a6-8948aac1fa07 -version: 1 -date: '2024-02-16' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk data_source: - Windows Event Log Security 4663 type: Anomaly status: production -description: The following analytic detects suspicious file access within the Discord LevelDB database. - This database contains critical data such as user profiles, messages, guilds, channels, settings, and cached information. - Access to this data poses a risk of Discord credential theft or unauthorized access to sensitive information on the - compromised system. Detecting such anomalies can serve as an effective pivot to identify non-Discord applications - accessing this database, potentially indicating the presence of malware or trojan stealers aimed at data theft. -search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\discord\\Local Storage\\leveldb*") - AND process_name != *\\discord.exe AND NOT (process_path IN ("*:\\Windows\\System32\\*", "*:\\Windows\\SysWow64\\*", "*:\\Program Files*", "*:\\Windows\\*")) - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_non_discord_app_access_discord_leveldb_filter`' +description: The following analytic detects non-Discord applications accessing the + Discord LevelDB database. It leverages Windows Security Event logs, specifically + event code 4663, to identify file access attempts to the LevelDB directory by processes + other than Discord. This activity is significant as it may indicate attempts to + steal Discord credentials or access sensitive user data. If confirmed malicious, + this could lead to unauthorized access to user profiles, messages, and other critical + information, potentially compromising the security and privacy of the affected users. +search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\discord\\Local + Storage\\leveldb*") AND process_name != *\\discord.exe AND NOT (process_path IN + ("*:\\Windows\\System32\\*", "*:\\Windows\\SysWow64\\*", "*:\\Program Files*", "*:\\Windows\\*")) + | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name + object_file_path process_name process_path process_id EventCode dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_non_discord_app_access_discord_leveldb_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." @@ -30,7 +32,8 @@ tags: asset_type: Endpoint confidence: 30 impact: 30 - message: A non-discord process $process_name$ accessing discord "leveldb" file on $dest$ + message: A non-discord process $process_name$ accessing discord "leveldb" file on + $dest$ mitre_attack_id: - T1012 observable: @@ -56,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_non_system_account_targeting_lsass.yml b/detections/endpoint/windows_non_system_account_targeting_lsass.yml index c46a17bdd9..e5df2652ed 100644 --- a/detections/endpoint/windows_non_system_account_targeting_lsass.yml +++ b/detections/endpoint/windows_non_system_account_targeting_lsass.yml @@ -1,15 +1,18 @@ name: Windows Non-System Account Targeting Lsass id: b1ce9a72-73cf-11ec-981b-acde48001122 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-09' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies non SYSTEM accounts requesting access - to lsass.exe. This behavior may be related to credential dumping or applications - requiring access to credentials. Triaging this event will require understanding - the GrantedAccess from the SourceImage. In addition, whether the account is privileged - or not. Review the process requesting permissions and review parallel processes. +description: The following analytic identifies non-SYSTEM accounts requesting access + to lsass.exe. This detection leverages Sysmon EventCode 10 logs to monitor access + attempts to the Local Security Authority Subsystem Service (lsass.exe) by non-SYSTEM + users. This activity is significant as it may indicate credential dumping attempts + or unauthorized access to sensitive credentials. If confirmed malicious, an attacker + could potentially extract credentials from memory, leading to privilege escalation + or lateral movement within the network. Immediate investigation is required to determine + the legitimacy of the access request and to mitigate any potential threats. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe NOT (SourceUser="NT AUTHORITY\\*") @@ -72,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_odbcconf_load_dll.yml b/detections/endpoint/windows_odbcconf_load_dll.yml index 9a86ece3fe..e1b1a3efc6 100644 --- a/detections/endpoint/windows_odbcconf_load_dll.yml +++ b/detections/endpoint/windows_odbcconf_load_dll.yml @@ -1,14 +1,18 @@ name: Windows Odbcconf Load DLL id: 141e7fca-a9f0-40fd-a539-9aac8be41f1b -version: 1 -date: '2022-06-28' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies odbcconf.exe, Windows Open Database - Connectivity utility, utilizing the action function of regsvr to load a DLL. An - example will look like - odbcconf.exe /A { REGSVR T1218-2.dll }. During triage, - review parent process, parallel procesess and file modifications. +description: The following analytic detects the execution of odbcconf.exe with the + regsvr action to load a DLL. This is identified by monitoring command-line arguments + in process creation logs from Endpoint Detection and Response (EDR) agents. This + activity is significant as it may indicate an attempt to execute arbitrary code + via DLL loading, a common technique used in various attack vectors. If confirmed + malicious, this could allow an attacker to execute code with the privileges of the + odbcconf.exe process, potentially leading to system compromise or further lateral + movement. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.008/atomic_red_team/windows-sysmon-odbc-regsvr.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.008/atomic_red_team/windows-sysmon-odbc-regsvr.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_odbcconf_load_response_file.yml b/detections/endpoint/windows_odbcconf_load_response_file.yml index 2fdf375847..126f117ddd 100644 --- a/detections/endpoint/windows_odbcconf_load_response_file.yml +++ b/detections/endpoint/windows_odbcconf_load_response_file.yml @@ -1,15 +1,18 @@ name: Windows Odbcconf Load Response File id: 1acafff9-1347-4b40-abae-f35aa4ba85c1 -version: 1 -date: '2022-06-30' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the odbcconf.exe, Windows Open Database - Connectivity utility, loading up a resource file. The file extension is arbitrary - and may be named anything. The resource file itself may have different commands - supported by Odbcconf to load up a DLL (REGSVR) on disk or additional commands. - During triage, review file modifications and parallel processes. +description: The following analytic detects the execution of odbcconf.exe with a response + file, which may contain commands to load a DLL (REGSVR) or other instructions. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments. This activity is significant as it + may indicate an attempt to execute arbitrary code or load malicious DLLs, potentially + leading to unauthorized actions. If confirmed malicious, this could allow an attacker + to gain code execution, escalate privileges, or establish persistence within the + environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.008/atomic_red_team/windows-sysmon-odbc-rsp.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.008/atomic_red_team/windows-sysmon-odbc-rsp.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_office_product_spawning_msdt.yml b/detections/endpoint/windows_office_product_spawning_msdt.yml index 23f93728bc..bf57ad3258 100644 --- a/detections/endpoint/windows_office_product_spawning_msdt.yml +++ b/detections/endpoint/windows_office_product_spawning_msdt.yml @@ -1,25 +1,27 @@ name: Windows Office Product Spawning MSDT id: 127eba64-c981-40bf-8589-1830638864a7 -version: 4 -date: '2023-11-07' +version: 5 +date: '2024-05-25' author: Michael Haag, Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a Microsoft Office product spawning - the Windows msdt.exe process. MSDT is a Diagnostics Troubleshooting Wizard native - to Windows. This behavior is related to a recently identified sample utilizing protocol - handlers to evade preventative controls, including if macros are disabled in the - document. During triage, review file modifications for html. In addition, parallel - processes including PowerShell and CertUtil. +description: The following analytic detects a Microsoft Office product spawning the + Windows msdt.exe process. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where Office applications + are the parent process. This activity is significant as it may indicate an attempt + to exploit protocol handlers to bypass security controls, even if macros are disabled. + If confirmed malicious, this behavior could allow an attacker to execute arbitrary + code, potentially leading to system compromise, data exfiltration, or further lateral + movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","mspub.exe","visio.exe","onenote.exe","onenotem.exe","onenoteviewer.exe","onenoteim.exe","msaccess.exe") - Processes.process_name=msdt.exe by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process - Processes.process_name Processes.original_file_name Processes.process Processes.process_id - Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `windows_office_product_spawning_msdt_filter`' + Processes.process_name=msdt.exe by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.original_file_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `windows_office_product_spawning_msdt_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -91,7 +93,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/msdt.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/msdt.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_papercut_ng_spawn_shell.yml b/detections/endpoint/windows_papercut_ng_spawn_shell.yml index 98ace8f7e9..e738167a8d 100644 --- a/detections/endpoint/windows_papercut_ng_spawn_shell.yml +++ b/detections/endpoint/windows_papercut_ng_spawn_shell.yml @@ -1,16 +1,20 @@ name: Windows PaperCut NG Spawn Shell id: a602d9a2-aaea-45f8-bf0f-d851168d61ca -version: 1 -date: '2023-05-15' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic is designed to detect instances where the PaperCut - NG application (pc-app.exe) spawns a Windows shell, specifically cmd.exe or PowerShell. - This behavior may indicate potential malicious activity, such as an attacker attempting - to gain unauthorized access or execute harmful commands on the affected system. +description: The following analytic detects instances where the PaperCut NG application + (pc-app.exe) spawns a Windows shell, such as cmd.exe or PowerShell. This behavior + is identified using Endpoint Detection and Response (EDR) telemetry, focusing on + process creation events where the parent process is pc-app.exe. This activity is + significant as it may indicate an attacker attempting to gain unauthorized access + or execute malicious commands on the system. If confirmed malicious, this could + lead to unauthorized code execution, privilege escalation, or further compromise + of the affected environment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=pc-app.exe `process_cmd` OR `process_powershell` OR Processes.process_name=java.exe by Processes.dest @@ -79,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/papercutng-app-spawn_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/papercutng-app-spawn_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_parent_pid_spoofing_with_explorer.yml b/detections/endpoint/windows_parent_pid_spoofing_with_explorer.yml index 188294c35e..93b1e11509 100644 --- a/detections/endpoint/windows_parent_pid_spoofing_with_explorer.yml +++ b/detections/endpoint/windows_parent_pid_spoofing_with_explorer.yml @@ -1,27 +1,25 @@ name: Windows Parent PID Spoofing with Explorer id: 17f8f69c-5d00-4c88-9c6f-493bbdef20a1 -version: 1 -date: '2023-11-21' +version: 2 +date: '2024-05-25' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a suspicious explorer.exe process that has "/root" process commandline. - The presence of this parameter is considered a significant indicator as it could indicate attempts at spoofing the parent process - by a specific program or malware. By spoofing the parent process, the malicious entity aims to circumvent detection mechanisms and - operate undetected within the system. - This technique of manipulating the command-line parameter (/root) of explorer.exe is a form of masquerading utilized by certain malware - or suspicious processes. The objective is to obscure the true nature of the activity by imitating a legitimate system process. By doing so, - it attempts to evade scrutiny and evade detection by security measures. -search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process="*explorer.exe*" Processes.process="*/root,*" - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_parent_pid_spoofing_with_explorer_filter`' +description: The following analytic identifies a suspicious `explorer.exe` process + with the `/root` command-line parameter. This detection leverages Endpoint Detection + and Response (EDR) telemetry, focusing on process and command-line data. The presence + of `/root` in `explorer.exe` is significant as it may indicate parent process spoofing, + a technique used by malware to evade detection. If confirmed malicious, this activity + could allow an attacker to operate undetected, potentially leading to unauthorized + access, privilege escalation, or persistent threats within the environment. +search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process="*explorer.exe*" + Processes.process="*/root,*" by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.original_file_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_parent_pid_spoofing_with_explorer_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -71,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134/explorer_root_proc_cmdline/explorer_root.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1134/explorer_root_proc_cmdline/explorer_root.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_password_managers_discovery.yml b/detections/endpoint/windows_password_managers_discovery.yml index 698a4022fb..05abef9387 100644 --- a/detections/endpoint/windows_password_managers_discovery.yml +++ b/detections/endpoint/windows_password_managers_discovery.yml @@ -1,20 +1,18 @@ name: Windows Password Managers Discovery id: a3b3bc96-1c4f-4eba-8218-027cac739a48 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line that retrieves - information related to password manager software. This technique was seen in several - post exploitation tools like winpeas that are being used by Ransomware Prestige - to gather this type of information. Password Managers applications are designed - to store user credentials, normally in an encrypted database. Credentials are typically - accessible after a user provides a master password that unlocks the database. After - the database is unlocked, these credentials may be copied to memory. These databases - can be stored as files on disk. Due to this password manager software designed adversaries - may find or look for keywords related to the Password Manager databases that can - be stolen or extracted for further attacks. +description: The following analytic identifies command-line activity that searches + for files related to password manager software, such as "*.kdbx*" and "*credential*". + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process execution logs. This activity is significant because attackers often target + password manager databases to extract stored credentials, which can be used for + further exploitation. If confirmed malicious, this behavior could lead to unauthorized + access to sensitive information, enabling attackers to escalate privileges, move + laterally, or exfiltrate critical data. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_pwd_db/dir-db-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_pwd_db/dir-db-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_phishing_outlook_drop_dll_in_form_dir.yml b/detections/endpoint/windows_phishing_outlook_drop_dll_in_form_dir.yml index 15aa065756..67dc39b952 100644 --- a/detections/endpoint/windows_phishing_outlook_drop_dll_in_form_dir.yml +++ b/detections/endpoint/windows_phishing_outlook_drop_dll_in_form_dir.yml @@ -1,26 +1,28 @@ name: Windows Phishing Outlook Drop Dll In FORM Dir id: fca01769-5163-4b3a-ae44-de874adfc9bc -version: 1 -date: '2024-03-20' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk data_source: - Sysmon EventID 11 type: TTP status: production -description: The following analytic identifies a suspicious outlook.exe process dropped a dll file. - This technique was seen in CVE-2024-21378, involves the loading of a custom MAPI form to execute a - potentially malicious DLL. Detecting such TTPs serves as a crucial pivot point to identify potential adversaries, - malware, or red team activity attempting to leverage this method within phishing campaigns. +description: The following analytic detects the creation of a DLL file by an outlook.exe + process in the AppData\Local\Microsoft\FORMS directory. This detection leverages + data from the Endpoint.Processes and Endpoint.Filesystem datamodels, focusing on + process and file creation events. This activity is significant as it may indicate + an attempt to exploit CVE-2024-21378, where a custom MAPI form loads a potentially + malicious DLL. If confirmed malicious, this could allow an attacker to execute arbitrary + code, leading to further system compromise or data exfiltration. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes - where Processes.process_name=outlook.exe - by _time span=1h Processes.process_id Processes.process_name Processes.process Processes.dest Processes.process_guid - | `drop_dm_object_name(Processes)` - | join process_guid, _time [ | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem - where Filesystem.file_name ="*.dll" Filesystem.file_path = "*\\AppData\\Local\\Microsoft\\FORMS\\IPM*" - by _time span=1h Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path Filesystem.process_guid - | `drop_dm_object_name(Filesystem)` - | fields file_name file_path process_name process_path process dest file_create_time _time process_guid] - | `windows_phishing_outlook_drop_dll_in_form_dir_filter`' + where Processes.process_name=outlook.exe by _time span=1h Processes.process_id Processes.process_name + Processes.process Processes.dest Processes.process_guid | `drop_dm_object_name(Processes)` + | join process_guid, _time [ | tstats `security_content_summariesonly` count min(_time) + as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_name + ="*.dll" Filesystem.file_path = "*\\AppData\\Local\\Microsoft\\FORMS\\IPM*" by _time + span=1h Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path + Filesystem.process_guid | `drop_dm_object_name(Filesystem)` | fields file_name file_path + process_name process_path process dest file_create_time _time process_guid] | `windows_phishing_outlook_drop_dll_in_form_dir_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, @@ -63,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/outlook_dropped_dll/outlook_phishing_form_dll.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/outlook_dropped_dll/outlook_phishing_form_dll.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_phishing_pdf_file_executes_url_link.yml b/detections/endpoint/windows_phishing_pdf_file_executes_url_link.yml index 6a755bf9aa..6c254b3742 100644 --- a/detections/endpoint/windows_phishing_pdf_file_executes_url_link.yml +++ b/detections/endpoint/windows_phishing_pdf_file_executes_url_link.yml @@ -1,18 +1,17 @@ name: Windows Phishing PDF File Executes URL Link id: 2fa9dec8-9d8e-46d3-96c1-202c06f0e6e1 -version: 1 -date: '2023-01-18' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is developed to detect suspicious pdf viewer processes - that have a browser application child processes. This event was seen in a pdf spear - phishing attachment containing a malicious URL link to download the actual payload. - When a user clicks the malicious link the pdf viewer application will execute a - process of the host default browser to connect to the malicious site. This anomaly - detection can be a good indicator that a possible pdf file has a link executed by - a user. The pdf viewer and browser list in this detection is still in progress, - add the common browser and pdf viewer you use in opening pdf in your network. +description: The following analytic detects suspicious PDF viewer processes spawning + browser application child processes. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process and parent process names. This activity + is significant as it may indicate a PDF spear-phishing attempt where a malicious + URL link is executed, leading to potential payload download. If confirmed malicious, + this could allow attackers to execute code, escalate privileges, or persist in the + environment by exploiting the user's browser to connect to a malicious site. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/phishing_pdf_uri/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/phishing_pdf_uri/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_phishing_recent_iso_exec_registry.yml b/detections/endpoint/windows_phishing_recent_iso_exec_registry.yml index 00770f6d66..5b665a92f8 100644 --- a/detections/endpoint/windows_phishing_recent_iso_exec_registry.yml +++ b/detections/endpoint/windows_phishing_recent_iso_exec_registry.yml @@ -1,16 +1,18 @@ name: Windows Phishing Recent ISO Exec Registry id: cb38ee66-8ae5-47de-bd66-231c7bbc0b2c -version: 2 -date: '2022-09-19' +version: 3 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following hunting analytic identifies registry artifacts when an - ISO container is opened, clicked or mounted on the Windows operating system. As - Microsoft makes changes to macro based document execution, adversaries have begun - to utilize container based initial access based phishing campaigns to evade preventative - controls. Once the ISO is clicked or mounted it will create a registry artifact - related to this event as a recent application executed or opened. +description: The following analytic detects the creation of registry artifacts when + an ISO container is opened, clicked, or mounted on a Windows operating system. It + leverages data from the Endpoint.Registry data model, specifically monitoring registry + keys related to recent ISO or IMG file executions. This activity is significant + as adversaries increasingly use container-based phishing campaigns to bypass macro-based + document execution controls. If confirmed malicious, this behavior could indicate + an initial access attempt, potentially leading to further exploitation, persistence, + or data exfiltration within the environment. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_possible_credential_dumping.yml b/detections/endpoint/windows_possible_credential_dumping.yml index 19ae5dcb59..075f0bb069 100644 --- a/detections/endpoint/windows_possible_credential_dumping.yml +++ b/detections/endpoint/windows_possible_credential_dumping.yml @@ -1,28 +1,17 @@ name: Windows Possible Credential Dumping id: e4723b92-7266-11ec-af45-acde48001122 -version: 3 -date: '2023-12-27' +version: 4 +date: '2024-05-31' author: Michael Haag, Splunk status: production type: TTP -description: 'The following analytic is an enhanced version of two previous analytics - that identifies common GrantedAccess permission requests and CallTrace DLLs in order - to detect credential dumping. - - GrantedAccess is the requested permissions by the SourceImage into the TargetImage. - - - CallTrace Stack trace of where open process is called. Included is the DLL and the - relative virtual address of the functions in the call stack right before the open - process call. - - dbgcore.dll or dbghelp.dll are two core Windows debug DLLs that have minidump functions - which provide a way for applications to produce crashdump files that contain a useful - subset of the entire process context. - - The idea behind using ntdll.dll is to blend in by using native api of ntdll.dll. - For example in sekurlsa module there are many ntdll exported api, like RtlCopyMemory, - used to execute this module which is related to lsass dumping.' +description: 'The following analytic detects potential credential dumping by identifying + specific GrantedAccess permission requests and CallTrace DLLs targeting the LSASS + process. It leverages Sysmon EventCode 10 logs, focusing on access requests to lsass.exe + and call traces involving debug and native API DLLs like dbgcore.dll, dbghelp.dll, + and ntdll.dll. This activity is significant as credential dumping can lead to unauthorized + access to sensitive credentials. If confirmed malicious, attackers could gain elevated + privileges and persist within the environment, posing a severe security risk.' data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*\\lsass.exe granted_access IN ("0x01000", @@ -94,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon_creddump.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_post_exploitation_risk_behavior.yml b/detections/endpoint/windows_post_exploitation_risk_behavior.yml index ff91d5abca..8c5248c6d0 100644 --- a/detections/endpoint/windows_post_exploitation_risk_behavior.yml +++ b/detections/endpoint/windows_post_exploitation_risk_behavior.yml @@ -1,32 +1,36 @@ name: Windows Post Exploitation Risk Behavior id: edb930df-64c2-4bb7-9b5c-889ed53fb973 -version: 1 -date: '2023-06-14' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: Correlation data_source: [] -description: The following correlation identifies a four or more number of distinct analytics associated with the Windows Post-Exploitation analytic story, which enables the identification of potentially suspicious behavior. Windows Post-Exploitation refers to the phase that occurs after an attacker successfully compromises a Windows system. During this stage, attackers strive to maintain persistence, gather sensitive information, escalate privileges, and exploit the compromised environment further. Timely detection of post-exploitation activities is crucial for prompt response and effective mitigation. Common post-exploitation detections encompass identifying suspicious processes or services running on the system, detecting unusual network connections or traffic patterns, identifying modifications to system files or registry entries, monitoring abnormal user account activities, and flagging unauthorized privilege escalations. Ensuring the detection of post-exploitation activities is essential to proactively prevent further compromise, minimize damage, and restore the security of the Windows environment. -search: '| 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 All_Risk.analyticstories IN ("*Windows Post-Exploitation*") - by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic - | `drop_dm_object_name(All_Risk)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | where source_count >= 4 - | `windows_post_exploitation_risk_behavior_filter`' -how_to_implement: 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. +description: The following analytic identifies four or more distinct post-exploitation + behaviors on a Windows system. It leverages data from the Risk data model in Splunk + Enterprise Security, focusing on multiple risk events and their associated MITRE + ATT&CK tactics and techniques. This activity is significant as it indicates potential + malicious actions following an initial compromise, such as persistence, privilege + escalation, or data exfiltration. If confirmed malicious, this behavior could allow + attackers to maintain control, escalate privileges, and further exploit the compromised + environment, leading to significant security breaches and data loss. +search: '| 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 All_Risk.analyticstories + IN ("*Windows Post-Exploitation*") by All_Risk.risk_object All_Risk.risk_object_type + All_Risk.annotations.mitre_attack.mitre_tactic | `drop_dm_object_name(All_Risk)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where + source_count >= 4 | `windows_post_exploitation_risk_behavior_filter`' +how_to_implement: 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. references: @@ -37,7 +41,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: An increase of Windows Post Exploitation behavior has been detected on $risk_object$ + message: An increase of Windows Post Exploitation behavior has been detected on + $risk_object$ mitre_attack_id: - T1012 - T1049 @@ -68,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/windows_post_exploitation/windows_post_exploitation_risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/windows_post_exploitation/windows_post_exploitation_risk.log source: wpe sourcetype: stash diff --git a/detections/endpoint/windows_powershell_add_module_to_global_assembly_cache.yml b/detections/endpoint/windows_powershell_add_module_to_global_assembly_cache.yml index ba8b0bb0bc..156612b04f 100644 --- a/detections/endpoint/windows_powershell_add_module_to_global_assembly_cache.yml +++ b/detections/endpoint/windows_powershell_add_module_to_global_assembly_cache.yml @@ -1,19 +1,18 @@ name: Windows PowerShell Add Module to Global Assembly Cache id: 3fc16961-97e5-4a5b-a079-e4ab0d9763eb -version: 1 -date: '2023-01-18' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: The following PowerShell Script Block analytic identifies the native - ability to add a DLL to the Windows Global Assembly Cache. Each computer where the - Common Language Runtime is installed has a machine-wide code cache called the Global - Assembly Cache. The Global Assembly Cache stores assemblies specifically designated - to be shared by several applications on the computer. By adding a DLL to the GAC, - this allows an adversary to call it via any other means across the operating systems. - This is native and built into Windows. Per the Microsoft blog, the more high fidelity - method may be to look for W3WP.exe spawning PowerShell that includes the same CommandLine - as identified in this analytic. +description: The following analytic detects the addition of a DLL to the Windows Global + Assembly Cache (GAC) using PowerShell. It leverages PowerShell Script Block Logging + to identify commands containing "system.enterpriseservices.internal.publish". This + activity is significant because adding a DLL to the GAC allows it to be shared across + multiple applications, potentially enabling an adversary to execute malicious code + system-wide. If confirmed malicious, this could lead to widespread code execution, + privilege escalation, and persistent access across the operating system, posing + a severe security risk. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN("*system.enterpriseservices.internal.publish*") @@ -58,7 +57,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/pwsh_publish_powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/pwsh_publish_powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_powershell_cryptography_namespace.yml b/detections/endpoint/windows_powershell_cryptography_namespace.yml index 9ccf5e25b6..e3dee7cefc 100644 --- a/detections/endpoint/windows_powershell_cryptography_namespace.yml +++ b/detections/endpoint/windows_powershell_cryptography_namespace.yml @@ -1,23 +1,26 @@ name: Windows Powershell Cryptography Namespace id: f8b482f4-6d62-49fa-a905-dfa15698317b -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104 that is processing cryptography namespace library. This technique - was seen in several powershell malware, loader, downloader and stager that will - decrypt or decode the next malicious stager or the actual payload. This Anomaly - detection can be a good indicator that a powershell process to decrypt code. We - recommend to further check the parent_process_name, the file or data it tries to - decrypt, network connection and user who execute the script. +description: The following analytic detects suspicious PowerShell script execution + involving the cryptography namespace via EventCode 4104. It leverages PowerShell + Script Block Logging to identify scripts using cryptographic functions, excluding + common hashes like SHA and MD5. This activity is significant as it is often associated + with malware that decrypts or decodes additional malicious payloads. If confirmed + malicious, this could allow an attacker to execute further code, escalate privileges, + or establish persistence within the environment. Analysts should investigate the + parent process, decrypted data, network connections, and the user executing the + script. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*System.Security.Cryptography*" AND NOT(ScriptBlockText IN ("*SHA*", "*MD5*", "*DeriveBytes*")) | stats count min(_time) - as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powershell_cryptography_namespace_filter`' + as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID + | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_powershell_cryptography_namespace_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -30,7 +33,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A suspicious powershell script contains cryptography command detected on host $dest$ + message: A suspicious powershell script contains cryptography command detected on + host $dest$ mitre_attack_id: - T1059.001 - T1059 @@ -59,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/asyncrat_crypto_pwh_namespace/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/asyncrat_crypto_pwh_namespace/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml index 996c65e489..08cd5b08aa 100644 --- a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml +++ b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml @@ -1,29 +1,39 @@ name: Windows PowerShell Get CIMInstance Remote Computer id: d8c972eb-ed84-431a-8869-ca4bd83257d1 -version: 1 -date: '2023-03-27' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk type: Anomaly status: production data_source: - Powershell Script Block Logging 4104 -description: This analytic identifies the use of Get-CimInstance cmdlet with the -ComputerName parameter, which indicates that the cmdlet is being used to retrieve information from a remote computer. This can be useful for detecting instances of remote access, such as when an attacker uses PowerShell to connect to a remote system and gather information. By monitoring for this cmdlet with the -ComputerName parameter, security analysts can identify potential malicious activity on remote systems and take appropriate action to mitigate any threats. -search: '`powershell` EventCode=4104 ScriptBlockText="*get-ciminstance*" AND ScriptBlockText="*computername*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_powershell_get_ciminstance_remote_computer_filter`' +description: The following analytic detects the use of the Get-CimInstance cmdlet + with the -ComputerName parameter, indicating an attempt to retrieve information + from a remote computer. It leverages PowerShell Script Block Logging to identify + this specific command execution. This activity is significant as it may indicate + unauthorized remote access or information gathering by an attacker. If confirmed + malicious, this could allow the attacker to collect sensitive data from remote systems, + potentially leading to further exploitation or lateral movement within the network. +search: '`powershell` EventCode=4104 ScriptBlockText="*get-ciminstance*" AND ScriptBlockText="*computername*" | + stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer user_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_powershell_get_ciminstance_remote_computer_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: This is meant to be a low risk RBA anomaly analytic or to be used for hunting. Enable this with a low risk score and let it generate risk in the risk index. +known_false_positives: This is meant to be a low risk RBA anomaly analytic or to be + used for hunting. Enable this with a low risk score and let it generate risk in + the risk index. references: - - https://learn.microsoft.com/en-us/powershell/module/cimcmdlets/get-ciminstance?view=powershell-7.3 +- https://learn.microsoft.com/en-us/powershell/module/cimcmdlets/get-ciminstance?view=powershell-7.3 tags: analytic_story: - Active Directory Lateral Movement asset_type: Endpoint confidence: 50 impact: 30 - message: A PowerShell Cmdlet Get-CIMInstnace was ran on $Computer$, attempting to connect to a remote host. + message: A PowerShell Cmdlet Get-CIMInstnace was ran on $Computer$, attempting to + connect to a remote host. mitre_attack_id: - T1059.001 observable: @@ -45,6 +55,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/get_ciminstance_windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/get_ciminstance_windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_powershell_iis_components_webglobalmodule_usage.yml b/detections/endpoint/windows_powershell_iis_components_webglobalmodule_usage.yml index e7f1109ce2..6414336358 100644 --- a/detections/endpoint/windows_powershell_iis_components_webglobalmodule_usage.yml +++ b/detections/endpoint/windows_powershell_iis_components_webglobalmodule_usage.yml @@ -1,15 +1,18 @@ name: Windows PowerShell IIS Components WebGlobalModule Usage id: 33fc9f6f-0ce7-4696-924e-a69ec61a3d57 -version: 1 -date: '2022-12-21' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the usage of PowerShell Cmdlets - New-WebGlobalModule, - Enable-WebGlobalModule and Set-WebGlobalModule being utilized to create (new), enable - (start) or modify a current IIS Module. These commands are equivalent to AppCmd.exe - parameters. Adversaries may utilize these cmdlets as they are lesser known and perform - the same activity as AppCmd. +description: The following analytic detects the usage of PowerShell Cmdlets - New-WebGlobalModule, + Enable-WebGlobalModule, and Set-WebGlobalModule, which are used to create, enable, + or modify IIS Modules. This detection leverages PowerShell Script Block Logging, + specifically monitoring EventCode 4104 for these cmdlets. This activity is significant + as adversaries may use these lesser-known cmdlets to manipulate IIS configurations, + similar to AppCmd.exe, potentially bypassing traditional defenses. If confirmed + malicious, this could allow attackers to persist in the environment, manipulate + web server behavior, or escalate privileges. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText IN("*New-WebGlobalModule*","*Enable-WebGlobalModule*","*Set-WebGlobalModule*") @@ -58,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/4104_windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/4104_windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_powershell_import_applocker_policy.yml b/detections/endpoint/windows_powershell_import_applocker_policy.yml index d13d5541e1..bab67f0b21 100644 --- a/detections/endpoint/windows_powershell_import_applocker_policy.yml +++ b/detections/endpoint/windows_powershell_import_applocker_policy.yml @@ -1,20 +1,25 @@ name: Windows Powershell Import Applocker Policy id: 102af98d-0ca3-4aa4-98d6-7ab2b98b955a -version: 1 -date: '2022-06-30' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is to identify the imports of Windows PowerShell - Applocker commandlets. This technique was seen in Azorult malware where it drops - an xml Applocker policy that will deny several AV product and then loaded using - PowerShell Applocker commandlet. +description: The following analytic detects the import of Windows PowerShell Applocker + cmdlets, specifically identifying the use of "Import-Module Applocker" and "Set-AppLockerPolicy" + with an XML policy. It leverages PowerShell Script Block Logging (EventCode 4104) + to capture and analyze script block text. This activity is significant as it may + indicate an attempt to enforce restrictive Applocker policies, potentially used + by malware like Azorult to disable antivirus products. If confirmed malicious, this + could allow an attacker to bypass security controls, leading to further system compromise + and persistence. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText="*Import-Module Applocker*" ScriptBlockText="*Set-AppLockerPolicy *" ScriptBlockText="* -XMLPolicy *" | stats count min(_time) as firstTime max(_time) - as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_powershell_import_applocker_policy_filter`' + as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest + | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_powershell_import_applocker_policy_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -58,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/import_applocker_policy/windows-powershell-xml2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/import_applocker_policy/windows-powershell-xml2.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_powershell_remotesigned_file.yml b/detections/endpoint/windows_powershell_remotesigned_file.yml index cad9533ed7..0c4c88c01c 100644 --- a/detections/endpoint/windows_powershell_remotesigned_file.yml +++ b/detections/endpoint/windows_powershell_remotesigned_file.yml @@ -1,17 +1,19 @@ name: Windows Powershell RemoteSigned File id: f7f7456b-470d-4a95-9703-698250645ff4 -version: 1 -date: '2023-06-16' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This analytic identifies the use of "remotesigned" execution policy for - a file. This security setting determines whether PowerShell scripts can be executed - on a computer. When the execution policy is set to "remotesigned," it allows locally - created scripts to run without any restrictions, but scripts downloaded from the - internet must have a digital signature from a trusted publisher. +description: The following analytic identifies the use of the "remotesigned" execution + policy for PowerShell scripts. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on command-line executions containing "remotesigned" and + "-File". This activity is significant because the "remotesigned" policy allows locally + created scripts to run without restrictions, posing a potential security risk. If + confirmed malicious, an attacker could execute unauthorized scripts, leading to + code execution, privilege escalation, or persistence within the environment. search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_powershell` Processes.process="* remotesigned *" Processes.process="* -File *" by Processes.dest Processes.user Processes.parent_process @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_remotesigned/remotesigned_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_remotesigned/remotesigned_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_powershell_scheduletask.yml b/detections/endpoint/windows_powershell_scheduletask.yml index f0ff39be13..aefdb37203 100644 --- a/detections/endpoint/windows_powershell_scheduletask.yml +++ b/detections/endpoint/windows_powershell_scheduletask.yml @@ -1,24 +1,32 @@ name: Windows PowerShell ScheduleTask id: ddf82fcb-e9ee-40e3-8712-a50b5bf323fc -version: 1 -date: '2023-06-12' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: Anomaly data_source: - Powershell Script Block Logging 4104 -description: "The following analytic detects potential malicious activities related to PowerShell's task scheduling cmdlets. It looks for anomalies in PowerShell logs, specifically EventCode 4104, associated with script block logging. The analytic flags unusual or suspicious use patterns of key task-related cmdlets such as 'New-ScheduledTask', 'Set-ScheduledTask', and others, which are often used by attackers for persistence and remote execution of malicious code. - If a true positive is found, it suggests an possible attacker is attempting to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, PowerShell Script Block Logging needs to be enabled on some or all endpoints. Analysts should be aware of benign administrative tasks that can trigger alerts and tune the analytic accordingly to reduce false positives. - Upon triage, review the PowerShell logs for any unusual or unexpected cmdlet usage, IP addresses, user accounts, or timestamps. If these factors align with known malicious behavior patterns, immediate mitigation steps, such as isolation of the affected systems, user account changes, and relevant threat hunting activities, should be initiated. This proactive analysis significantly enhances an organization's capacity to swiftly respond to, and potentially prevent, the execution of advanced persistent threats in their network." -search: '`powershell` EventCode=4104 ScriptBlockText IN ("*New-ScheduledTask*", "*New-ScheduledTaskAction*", "*New-ScheduledTaskSettingsSet*", "*New-ScheduledTaskTrigger*", "*Register-ClusteredScheduledTask*", "*Register-ScheduledTask*", "*Set-ClusteredScheduledTask*", "*Set-ScheduledTask*", "*Start-ScheduledTask*", "*Enable-ScheduledTask*") - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_powershell_scheduletask_filter`' +description: "The following analytic detects potential malicious activities involving + PowerShell's task scheduling cmdlets. It leverages PowerShell Script Block Logging + (EventCode 4104) to identify unusual or suspicious use of cmdlets like 'New-ScheduledTask' + and 'Set-ScheduledTask'. This activity is significant as attackers often use these + cmdlets for persistence and remote execution of malicious code. If confirmed malicious, + this could allow attackers to maintain access, deliver additional payloads, or execute + ransomware, leading to data theft or other severe impacts. Immediate investigation + and mitigation are crucial to prevent further compromise." +search: '`powershell` EventCode=4104 ScriptBlockText IN ("*New-ScheduledTask*", "*New-ScheduledTaskAction*", + "*New-ScheduledTaskSettingsSet*", "*New-ScheduledTaskTrigger*", "*Register-ClusteredScheduledTask*", + "*Register-ScheduledTask*", "*Set-ClusteredScheduledTask*", "*Set-ScheduledTask*", + "*Start-ScheduledTask*", "*Enable-ScheduledTask*") | stats count min(_time) as firstTime + max(_time) as lastTime by EventCode ScriptBlockText Computer user_id | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_powershell_scheduletask_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: Benign administrative tasks can also trigger alerts, necessitating a firm understanding of the typical system behavior and precise tuning of the analytic to reduce false positives. +known_false_positives: Benign administrative tasks can also trigger alerts, necessitating + a firm understanding of the typical system behavior and precise tuning of the analytic + to reduce false positives. references: - https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/?view=windowsserver2022-ps - https://thedfirreport.com/2023/06/12/a-truly-graceful-wipe-out/ @@ -30,7 +38,8 @@ tags: - af9fd58f-c4ac-4bf2-a9ba-224b71ff25fd confidence: 50 impact: 50 - message: The PowerShell cmdlets related to task creation, modification and start occurred on $Computer$ by $user_id$. + message: The PowerShell cmdlets related to task creation, modification and start + occurred on $Computer$ by $user_id$. mitre_attack_id: - T1053.005 - T1059.001 @@ -58,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/pwsh_scheduledtask.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/atomic_red_team/pwsh_scheduledtask.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml index 506dab9dc4..eda87ec83a 100644 --- a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml +++ b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml @@ -1,21 +1,32 @@ name: Windows PowerShell WMI Win32 ScheduledJob id: 47c69803-2c09-408b-b40a-063c064cbb16 -version: 1 -date: '2023-03-27' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk type: TTP status: production data_source: - Powershell Script Block Logging 4104 -description: The following analytic detects the use of the PowerShell script block logging mechanism to detect the use of the Win32_ScheduledJob WMI class. This class allows the creation and management of scheduled tasks on Windows systems. However, due to security concerns, the class has been disabled by default in Windows systems, and its use must be explicitly enabled by modifying the registry. As a result, the detection of the use of this class may indicate malicious activity, especially if the class was enabled on the system by the attacker. Therefore, it is recommended to monitor the use of Win32_ScheduledJob through PowerShell script block logging and to investigate any suspicious activity. -search: '`powershell` EventCode=4104 ScriptBlockText="*win32_scheduledjob*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user - | `security_content_ctime(firstTime)` +description: The following analytic detects the use of the Win32_ScheduledJob WMI + class via PowerShell script block logging. This class, which manages scheduled tasks, + is disabled by default due to security concerns and must be explicitly enabled through + registry modifications. The detection leverages PowerShell event code 4104 and script + block text analysis. Monitoring this activity is crucial as it may indicate malicious + intent, especially if the class was enabled by an attacker. If confirmed malicious, + this could allow attackers to persist in the environment by creating scheduled tasks. +search: '`powershell` EventCode=4104 ScriptBlockText="*win32_scheduledjob*" | stats + count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powershell_wmi_win32_scheduledjob_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. -known_false_positives: False positives may be present based on legacy applications or utilities. Win32_ScheduledJob uses the Remote Procedure Call (RPC) protocol to create scheduled tasks on remote computers. It uses the DCOM (Distributed Component Object Model) infrastructure to establish a connection with the remote computer and invoke the necessary methods. The RPC service needs to be running on both the local and remote computers for the communication to take place. +known_false_positives: False positives may be present based on legacy applications + or utilities. Win32_ScheduledJob uses the Remote Procedure Call (RPC) protocol to + create scheduled tasks on remote computers. It uses the DCOM (Distributed Component + Object Model) infrastructure to establish a connection with the remote computer + and invoke the necessary methods. The RPC service needs to be running on both the + local and remote computers for the communication to take place. references: - https://securityonline.info/wmiexec-regout-get-outputdata-response-from-registry/ - https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob @@ -25,7 +36,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 80 - message: PowerShell attempting to create a task via WMI - Win32_ScheduledJob, was ran on $dest$. + message: PowerShell attempting to create a task via WMI - Win32_ScheduledJob, was + ran on $dest$. mitre_attack_id: - T1059.001 - T1059 @@ -48,7 +60,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/win32_scheduledjob_windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/win32_scheduledjob_windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/endpoint/windows_powersploit_gpp_discovery.yml b/detections/endpoint/windows_powersploit_gpp_discovery.yml index 714700fe95..6fb35c4eaf 100644 --- a/detections/endpoint/windows_powersploit_gpp_discovery.yml +++ b/detections/endpoint/windows_powersploit_gpp_discovery.yml @@ -1,19 +1,23 @@ name: Windows PowerSploit GPP Discovery id: 0130a0df-83a1-4647-9011-841e950ff302 -version: 1 -date: '2023-03-16' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies the use of the Get-GPPPassword PowerShell commandlet employed to search for unsecured credentials Group Policy Preferences (GPP). - GPP are tools that allow administrators to create domain policies with embedded credentials. These policies allow administrators to set local accounts. - These group policies are stored in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL share and decrypt the password (using the AES key that has been made public). - While Microsoft released a patch that impedes Administrators to create unsecure credentials, existing Group Policy Preferences files with passwords are not removed from SYSVOL. +description: The following analytic detects the execution of the Get-GPPPassword PowerShell + cmdlet, which is used to search for unsecured credentials in Group Policy Preferences + (GPP). This detection leverages PowerShell Script Block Logging to identify specific + script block text associated with this cmdlet. Monitoring this activity is crucial + as it can indicate an attempt to retrieve and decrypt stored credentials from SYSVOL, + potentially leading to unauthorized access. If confirmed malicious, this activity + could allow an attacker to escalate privileges or move laterally within the network + by exploiting exposed credentials. search: ' `powershell` EventCode=4104 (ScriptBlockText=Get-GPPPassword OR ScriptBlockText=Get-CachedGPPPassword) - | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer + UserID EventCode ScriptBlockText | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powersploit_gpp_discovery_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here @@ -22,7 +26,7 @@ known_false_positives: Unknown references: - https://attack.mitre.org/techniques/T1552/006/ - https://pentestlab.blog/2017/03/20/group-policy-preferences/ -- https://adsecurity.org/?p=2288 +- https://adsecurity.org/?p=2288 - https://www.hackingarticles.in/credential-dumping-group-policy-preferences-gpp/ - https://adsecurity.org/?p=2288 - https://support.microsoft.com/en-us/topic/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13-2014-60734e15-af79-26ca-ea53-8cd617073c30 @@ -61,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.006/powershell_gpp_discovery/win-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.006/powershell_gpp_discovery/win-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_powerview_ad_access_control_list_enumeration.yml b/detections/endpoint/windows_powerview_ad_access_control_list_enumeration.yml index 564d807e30..4b9c329ff4 100644 --- a/detections/endpoint/windows_powerview_ad_access_control_list_enumeration.yml +++ b/detections/endpoint/windows_powerview_ad_access_control_list_enumeration.yml @@ -1,26 +1,29 @@ name: Windows PowerView AD Access Control List Enumeration id: 39405650-c364-4e1e-a740-32a63ef042a6 -version: 1 -date: '2023-04-20' +version: 2 +date: '2024-05-17' author: Mauricio Velazco, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets `Get-ObjectAcl` or `Get-DomainObjectAcl`. This commandlets - are used to enumerate Access Control List permissions given to Active Directory objects. In an active directory environment, an object is an entity that represents an available resource within - the organizations network, such as domain controllers, users, groups, computers, shares, etc. Maintaining Active Directory permissions is complicated and hard to manage, especially in complex - and large environments with multiple domains. Weak permissions may allow adversaries and red teamers to escalate their privileges in Active Directory. PowerView is a common tool leveraged - by attackers to identify and exploit configuration weaknesses. -search: ' `powershell` EventCode=4104 (ScriptBlockText=*get-objectacl* OR ScriptBlockText=*Get-DomainObjectAcl* ) - | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer UserID EventCode ScriptBlockText - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of PowerView PowerShell + cmdlets `Get-ObjectAcl` or `Get-DomainObjectAcl`, which are used to enumerate Access + Control List (ACL) permissions for Active Directory objects. It leverages Event + ID 4104 from PowerShell Script Block Logging to identify this activity. This behavior + is significant as it may indicate an attempt to discover weak permissions in Active + Directory, potentially leading to privilege escalation. If confirmed malicious, + attackers could exploit these permissions to gain unauthorized access or escalate + their privileges within the network. +search: ' `powershell` EventCode=4104 (ScriptBlockText=*get-objectacl* OR ScriptBlockText=*Get-DomainObjectAcl* + ) | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer + UserID EventCode ScriptBlockText | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powerview_ad_access_control_list_enumeration_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= -known_false_positives: Administrators may leverage PowerView for legitimate purposes, filter as needed. +known_false_positives: Administrators may leverage PowerView for legitimate purposes, + filter as needed. references: - https://attack.mitre.org/techniques/T1078/002/ - https://medium.com/r3d-buck3t/enumerating-access-controls-in-active-directory-c06e2efa8b89 @@ -58,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/powerview_acl_enumeration/windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.002/powerview_acl_enumeration/windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_powerview_constrained_delegation_discovery.yml b/detections/endpoint/windows_powerview_constrained_delegation_discovery.yml index 05c1cbd404..cac12014b8 100644 --- a/detections/endpoint/windows_powerview_constrained_delegation_discovery.yml +++ b/detections/endpoint/windows_powerview_constrained_delegation_discovery.yml @@ -1,20 +1,24 @@ name: Windows PowerView Constrained Delegation Discovery id: 86dc8176-6e6c-42d6-9684-5444c6557ab3 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify commandlets used by the PowerView hacking tool leveraged to discover - Windows endpoints with Kerberos Constrained Delegation. Red Teams and adversaries - alike may leverage use this technique for situational awareness and Active Directory - Discovery. +description: The following analytic detects the use of PowerView commandlets to discover + Windows endpoints with Kerberos Constrained Delegation. It leverages PowerShell + Script Block Logging (EventCode=4104) to identify specific commandlets like `Get-DomainComputer` + or `Get-NetComputer` with the `-TrustedToAuth` parameter. This activity is significant + as it indicates potential reconnaissance efforts by adversaries or Red Teams to + map out privileged delegation settings in Active Directory. If confirmed malicious, + this could allow attackers to identify high-value targets for further exploitation, + potentially leading to privilege escalation or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainComputer*" OR ScriptBlockText - = "*Get-NetComputer*") AND (ScriptBlockText = "*-TrustedToAuth*") | stats count min(_time) - as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` +search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainComputer*" OR + ScriptBlockText = "*Get-NetComputer*") AND (ScriptBlockText = "*-TrustedToAuth*") + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powerview_constrained_delegation_discovery_filter`' how_to_implement: The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add @@ -56,13 +60,14 @@ tags: - _time - EventCode - ScriptBlockText - - ComputerName - - User + - Computer + - UserID risk_score: 35 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_powerview_constrained_delegation_discovery/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_powerview_constrained_delegation_discovery/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_powerview_kerberos_service_ticket_request.yml b/detections/endpoint/windows_powerview_kerberos_service_ticket_request.yml index baa5231f89..fd8f21bf0a 100644 --- a/detections/endpoint/windows_powerview_kerberos_service_ticket_request.yml +++ b/detections/endpoint/windows_powerview_kerberos_service_ticket_request.yml @@ -1,25 +1,24 @@ name: Windows PowerView Kerberos Service Ticket Request id: 970455a1-4ac2-47e1-a9a5-9e75443ddcb9 -version: 1 -date: '2022-06-22' +version: 2 +date: '2024-05-31' author: Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainSPNTicket` commandlets with specific - parameters. This commandlet is a part of PowerView, a PowerShell tool used to perform - enumeration and discovery on Windows Active Directory networks. As the name suggests, - this commandlet is used to request the kerberos ticket for a specified service principal - name (SPN). Once the ticket is received, it may be cracked using password cracking - tools like hashcat to extract the password of the SPN account. Red Teams and adversaries - alike may leverage PowerView and these commandlets to identify accounts that can - be attacked with the Kerberoasting technique. +description: The following analytic detects the execution of the `Get-DomainSPNTicket` + commandlet, part of the PowerView tool, by leveraging PowerShell Script Block Logging + (EventCode=4104). This commandlet requests Kerberos service tickets for specified + service principal names (SPNs). Monitoring this activity is crucial as it can indicate + attempts to perform Kerberoasting, a technique used to extract SPN account passwords + via cracking tools like hashcat. If confirmed malicious, this activity could allow + attackers to gain unauthorized access to sensitive accounts, potentially leading + to privilege escalation and further network compromise. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText=*Get-DomainSPNTicket* | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText - Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_powerview_kerberos_service_ticket_request_filter`' + Computer UserID | rename Computer as dest | rename UserID as user| `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_powerview_kerberos_service_ticket_request_filter`' how_to_implement: The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. @@ -62,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/powerview/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/powerview/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_powerview_spn_discovery.yml b/detections/endpoint/windows_powerview_spn_discovery.yml index 56c9c54800..d4542f0745 100644 --- a/detections/endpoint/windows_powerview_spn_discovery.yml +++ b/detections/endpoint/windows_powerview_spn_discovery.yml @@ -1,19 +1,18 @@ name: Windows PowerView SPN Discovery id: a7093c28-796c-4ebb-9997-e2c18b870837 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-13' author: Gowthamaraj Rajendran, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the execution of the `Get-DomainUser` or `Get-NetUSer` commandlets with - specific parameters. These commandlets are part of PowerView, a PowerShell tool - used to perform enumeration and discovery on Windows Active Directory networks. - As the names suggest, these commandlets are used to identify domain users in a network - and combining them with the `-SPN` parameter allows adversaries to discover domain - accounts associated with a Service Principal Name (SPN). Red Teams and adversaries - alike may leverage PowerView and these commandlets to identify accounts that can - be attacked with the Kerberoasting technique. +description: The following analytic detects the execution of the `Get-DomainUser` + or `Get-NetUser` PowerShell cmdlets with the `-SPN` parameter, indicating the use + of PowerView for SPN discovery. It leverages PowerShell Script Block Logging (EventCode=4104) + to identify these specific commands. This activity is significant as it suggests + an attempt to enumerate domain accounts associated with Service Principal Names + (SPNs), a common precursor to Kerberoasting attacks. If confirmed malicious, this + could allow an attacker to identify and target accounts for credential theft, potentially + leading to unauthorized access and privilege escalation within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 (ScriptBlockText =*Get-NetUser* OR ScriptBlockText=*Get-DomainUser*) @@ -62,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/powerview-2/windows-powershell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1558.003/powerview-2/windows-powershell.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_powerview_unconstrained_delegation_discovery.yml b/detections/endpoint/windows_powerview_unconstrained_delegation_discovery.yml index ba692776de..8480b2bcdc 100644 --- a/detections/endpoint/windows_powerview_unconstrained_delegation_discovery.yml +++ b/detections/endpoint/windows_powerview_unconstrained_delegation_discovery.yml @@ -1,20 +1,24 @@ name: Windows PowerView Unconstrained Delegation Discovery id: fbf9e47f-e531-4fea-942d-5c95af7ed4d6 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify commandlets used by the PowerView hacking tool leveraged to discover - Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries - alike may leverage use this technique for situational awareness and Active Directory - Discovery. +description: The following analytic detects the use of PowerView commandlets to discover + Windows endpoints with Kerberos Unconstrained Delegation. It leverages PowerShell + Script Block Logging (EventCode=4104) to identify specific commands like `Get-DomainComputer` + or `Get-NetComputer` with the `-Unconstrained` parameter. This activity is significant + as it indicates potential reconnaissance efforts by adversaries or Red Teams to + map out privileged delegation settings in Active Directory. If confirmed malicious, + this could allow attackers to identify high-value targets for further exploitation, + potentially leading to privilege escalation or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 -search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainComputer*" OR ScriptBlockText - = "*Get-NetComputer*") AND (ScriptBlockText = "*-Unconstrained*") | stats count min(_time) - as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` +search: '`powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainComputer*" OR + ScriptBlockText = "*Get-NetComputer*") AND (ScriptBlockText = "*-Unconstrained*") + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_powerview_unconstrained_delegation_discovery_filter`' how_to_implement: The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add @@ -55,13 +59,14 @@ tags: - _time - EventCode - ScriptBlockText - - ComputerName - - User + - Computer + - UserID risk_score: 35 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_powerview_constrained_delegation_discovery/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1018/windows_powerview_constrained_delegation_discovery/windows-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_private_keys_discovery.yml b/detections/endpoint/windows_private_keys_discovery.yml index 684b7898ab..8434dab2bb 100644 --- a/detections/endpoint/windows_private_keys_discovery.yml +++ b/detections/endpoint/windows_private_keys_discovery.yml @@ -1,18 +1,19 @@ name: Windows Private Keys Discovery id: 5c1c2877-06c0-40ee-a1a2-db71f1372b5b -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-30' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line that retrieves - information related to private keys files. This technique was seen in several post - exploitation tools like winpeas that are being used by Ransomware Prestige to search - for private key certificates on the compromised host for insecurely stored credentials. - This files can be used by adversaries to gain privileges, persistence or remote - service authentication to collect more sensitive information. Some private keys - required password for operation, so in this case adversaries may need to have that - passphrase either via keylogging or brute force attack. +description: The following analytic identifies processes that retrieve information + related to private key files, often used by post-exploitation tools like winpeas. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on command-line executions that search for private key certificates. This + activity is significant as it indicates potential attempts to locate insecurely + stored credentials, which adversaries can exploit for privilege escalation, persistence, + or remote service authentication. If confirmed malicious, this behavior could allow + attackers to access sensitive information, escalate privileges, or maintain persistence + within the compromised environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,7 +80,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_private_key/dir-private-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/winpeas_search_private_key/dir-private-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml b/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml index f7c19c1c09..260cd7c510 100644 --- a/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml +++ b/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml @@ -1,79 +1,109 @@ ---- name: Windows Privilege Escalation Suspicious Process Elevation id: 6a80300a-9f8a-4f22-bd3e-09ca577cfdfc -version: 1 -date: '2023-11-30' +version: 2 +date: '2024-05-23' author: Steven Dick status: production type: TTP -description: The following analytic detects when any low->high integrity level process running from a user account spawns an elevated (high/system integrity) process in a suspicious location or with system level process integrity. This behavior may indicate when a threat actor has successfully elevated privileges. +description: The following analytic detects when a process running with low or medium + integrity from a user account spawns an elevated process with high or system integrity + in suspicious locations. This behavior is identified using process execution data + from Windows process monitoring or Sysmon Event ID 1. This activity is significant + as it may indicate a threat actor successfully elevating privileges, which is a + common tactic in advanced attacks. If confirmed malicious, this could allow the + attacker to execute code with higher privileges, potentially leading to full system + compromise and persistent access. data_source: - Sysmon EventID 1 search: >- - | tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("low","medium","high") NOT Processes.user IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","DWM-*","*$") by Processes.dest, Processes.user, Processes.parent_process_guid, Processes.parent_process, Processes.parent_process_name Processes.process_name Processes.process, Processes.process_path, Processes.process_guid, - Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` | eval join_guid = process_guid, integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) | rename user as src_user, parent_process* as orig_parent_process*, process* as parent_process* | join max=0 dest join_guid [| tstats - `security_content_summariesonly` count max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_integrity_level IN ("system") NOT Processes.user IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","DWM-*","*$")) OR (Processes.process_integrity_level IN ("high","system") AND (Processes.parent_process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") OR Processes.process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*"))) by Processes.dest, - Processes.user, Processes.parent_process_guid, Processes.process_name, Processes.process, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` | eval elevated_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) | rename parent_process_guid as join_guid ] | where - elevated_integrity_level > integrity_level OR user != elevated_user | fields dest, user, src_user, parent_process_name, parent_process, parent_process_path, parent_process_guid, parent_process_integrity_level, parent_process_current_directory, process_name, process, process_path, process_guid, process_integrity_level, process_current_directory, orig_parent_process_name, orig_parent_process, orig_parent_process_guid, firstTime, lastTime, count | `security_content_ctime(firstTime)` | + | tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes + where Processes.process_integrity_level IN ("low","medium","high") NOT Processes.user + IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","DWM-*","*$") by Processes.dest, + Processes.user, Processes.parent_process_guid, Processes.parent_process, Processes.parent_process_name + Processes.process_name Processes.process, Processes.process_path, Processes.process_guid, + Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` + | eval join_guid = process_guid, integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) + | rename user as src_user, parent_process* as orig_parent_process*, process* as + parent_process* | join max=0 dest join_guid [| tstats + `security_content_summariesonly` count max(_time) as lastTime from datamodel=Endpoint.Processes + where (Processes.process_integrity_level IN ("system") NOT Processes.user IN ("*SYSTEM","*LOCAL + SERVICE","*NETWORK SERVICE","DWM-*","*$")) OR (Processes.process_integrity_level + IN ("high","system") AND (Processes.parent_process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") + OR Processes.process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*"))) + by Processes.dest, + Processes.user, Processes.parent_process_guid, Processes.process_name, Processes.process, + Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory + | `drop_dm_object_name(Processes)` | eval elevated_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) + | rename parent_process_guid as join_guid ] | where + elevated_integrity_level > integrity_level OR user != elevated_user | fields dest, + user, src_user, parent_process_name, parent_process, parent_process_path, parent_process_guid, + parent_process_integrity_level, parent_process_current_directory, process_name, + process, process_path, process_guid, process_integrity_level, process_current_directory, + orig_parent_process_name, orig_parent_process, orig_parent_process_guid, firstTime, + lastTime, count | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_privilege_escalation_suspicious_process_elevation_filter` -how_to_implement: Target environment must ingest process execution data sources such as Windows process monitoring and/or Sysmon EID 1. -known_false_positives: False positives may be generated by administrators installing benign applications using run-as/elevation. +how_to_implement: Target environment must ingest process execution data sources such + as Windows process monitoring and/or Sysmon EID 1. +known_false_positives: False positives may be generated by administrators installing + benign applications using run-as/elevation. references: - - https://attack.mitre.org/techniques/T1068/ - - https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor - - https://redcanary.com/blog/getsystem-offsec/ - - https://atomicredteam.io/privilege-escalation/T1134.001/ +- https://attack.mitre.org/techniques/T1068/ +- https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor +- https://redcanary.com/blog/getsystem-offsec/ +- https://atomicredteam.io/privilege-escalation/T1134.001/ tags: analytic_story: - - Windows Privilege Escalation + - Windows Privilege Escalation asset_type: Endpoint confidence: 40 impact: 100 - message: The user $src_user$ launched a process [$parent_process_name$] which spawned a suspicious elevated integrity process [$process_name$]. + message: The user $src_user$ launched a process [$parent_process_name$] which spawned + a suspicious elevated integrity process [$process_name$]. mitre_attack_id: - - T1068 - - T1548 - - T1134 + - T1068 + - T1548 + - T1134 observable: - - name: dest - role: - - Victim - type: Hostname - - name: user - role: - - Victim - type: User - - name: src_user - role: - - Victim - type: User - - name: process_name - role: - - Attacker - type: Other + - name: dest + role: + - Victim + type: Hostname + - name: user + role: + - Victim + type: User + - name: src_user + role: + - Victim + type: User + - name: process_name + role: + - Attacker + type: Other product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - Processes.dest - - Processes.user - - Processes.parent_process_guid - - Processes.parent_process - - Processes.parent_process_name - - Processes.process_name - - Processes.process - - Processes.process_path - - Processes.process_guid - - Processes.process_integrity_level - - Processes.process_current_directory + - _time + - Processes.dest + - Processes.user + - Processes.parent_process_guid + - Processes.parent_process + - Processes.parent_process_name + - Processes.process_name + - Processes.process + - Processes.process_path + - Processes.process_guid + - Processes.process_integrity_level + - Processes.process_current_directory risk_score: 40 security_domain: endpoint tests: - - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog - update_timestamp: true - name: True Positive Test \ No newline at end of file +- attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: XmlWinEventLog + update_timestamp: true + name: True Positive Test diff --git a/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml b/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml index 9b7995d414..61bd65496c 100644 --- a/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml +++ b/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml @@ -1,66 +1,79 @@ ---- name: Windows Privilege Escalation System Process Without System Parent id: 5a5351cd-ba7e-499e-ad82-2ce160ffa637 -version: 1 -date: '2023-11-30' +version: 2 +date: '2024-05-28' author: Steven Dick status: production type: TTP -description: The following analytic detects any system integrity level process that was spawned by a process not running as a system account. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service. +description: The following analytic detects any system integrity level process spawned + by a non-system account. It leverages Sysmon Event ID 1, focusing on process integrity + and parent user data. This behavior is significant as it often indicates successful + privilege escalation to SYSTEM from a user-controlled process or service. If confirmed + malicious, this activity could allow an attacker to gain full control over the system, + execute arbitrary code, and potentially compromise the entire environment. data_source: - Sysmon EventID 1 search: >- - `sysmon` EventCode=1 IntegrityLevel="system" ParentUser=* NOT ParentUser IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","*DWM-*","*$","-") | eval src_user = replace(ParentUser,"^[^\\\]+\\\\","") | stats count min(_time) as firstTime max(_time) as lastTime values(process_name) as process_name values(process) as process, values(process_path) as process_path, values(process_current_directory) as process_current_directory values(parent_process) as parent_process by dest, user, src_user, - parent_process_name, parent_process_guid | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_privilege_escalation_system_process_without_system_parent_filter` -how_to_implement: Target environment must ingest sysmon data, specifically Event ID 1 with process integrity and parent user data. + `sysmon` EventCode=1 IntegrityLevel="system" ParentUser=* NOT ParentUser IN ("*SYSTEM","*LOCAL + SERVICE","*NETWORK SERVICE","*DWM-*","*$","-") | eval src_user = replace(ParentUser,"^[^\\\]+\\\\","") + | stats count min(_time) as firstTime max(_time) as lastTime values(process_name) + as process_name values(process) as process, values(process_path) as process_path, + values(process_current_directory) as process_current_directory values(parent_process) + as parent_process by dest, user, src_user, + parent_process_name, parent_process_guid | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | `windows_privilege_escalation_system_process_without_system_parent_filter` +how_to_implement: Target environment must ingest sysmon data, specifically Event ID + 1 with process integrity and parent user data. known_false_positives: Unknown references: - - https://attack.mitre.org/techniques/T1068/ - - https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor - - https://redcanary.com/blog/getsystem-offsec/ - - https://atomicredteam.io/privilege-escalation/T1134.001/ +- https://attack.mitre.org/techniques/T1068/ +- https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor +- https://redcanary.com/blog/getsystem-offsec/ +- https://atomicredteam.io/privilege-escalation/T1134.001/ tags: analytic_story: - - Windows Privilege Escalation + - Windows Privilege Escalation asset_type: Endpoint confidence: 80 impact: 100 - message: The process [$process_name$] on $dest$ was launched with system level integrity by $src_user$. + message: The process [$process_name$] on $dest$ was launched with system level integrity + by $src_user$. mitre_attack_id: - - T1068 - - T1548 - - T1134 + - T1068 + - T1548 + - T1134 observable: - - name: dest - role: - - Victim - type: Hostname - - name: src_user - role: - - Victim - type: User - - name: process_name - role: - - Attacker - type: Other + - name: dest + role: + - Victim + type: Hostname + - name: src_user + role: + - Victim + type: User + - name: process_name + role: + - Attacker + type: Other product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - dest - - user - - ParentUser - - parent_process_name - - parent_process_guid - - IntegrityLevel + - _time + - dest + - user + - ParentUser + - parent_process_name + - parent_process_guid + - IntegrityLevel risk_score: 80 security_domain: endpoint tests: - - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog - update_timestamp: true - name: True Positive Test +- attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: XmlWinEventLog + update_timestamp: true + name: True Positive Test diff --git a/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml b/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml index 41c97a1f19..72c1a9026f 100644 --- a/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml +++ b/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml @@ -1,68 +1,94 @@ ---- name: Windows Privilege Escalation User Process Spawn System Process id: c9687a28-39ad-43c6-8bcf-eaf061ba0cbe -version: 1 -date: '2023-11-30' +version: 2 +date: '2024-05-13' author: Steven Dick status: production type: TTP -description: The following analytic detects when any process low->high integrity level process spawns a system integrity process from a user controlled location. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service. +description: The following analytic detects when a process with low, medium, or high + integrity spawns a system integrity process from a user-controlled location. This + behavior is indicative of privilege escalation attempts where attackers elevate + their privileges to SYSTEM level from a user-controlled process or service. The + detection leverages Sysmon data, specifically Event ID 15, to identify such transitions. + Monitoring this activity is crucial as it can signify an attacker gaining SYSTEM-level + access, potentially leading to full control over the affected system, unauthorized + access to sensitive data, and further malicious activities. data_source: - Sysmon EventID 1 search: >- - | tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("low","medium","high") NOT Processes.user IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","DWM-*","*$") AND Processes.process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") by Processes.dest, Processes.user, Processes.parent_process_guid, Processes.parent_process, Processes.parent_process_name Processes.process_name - Processes.process, Processes.process_path, Processes.process_guid, Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` | eval join_guid = process_guid | join max=0 dest join_guid [| tstats `security_content_summariesonly` count max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("system") AND Processes.parent_process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") by - Processes.dest, Processes.user, Processes.parent_process_guid, Processes.process_name, Processes.process, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` | rename parent_process_guid as join_guid, process* as system_process*, user as system_user ] | fields dest, user, parent_process, parent_process_name, parent_process_guid, process, process_name, process_guid, process_integrity_level,process_path, - process_current_directory, system_process_name, system_process, system_process_path, system_process_integrity_level, system_process_current_directory, system_user, firstTime, lastTime, count | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_privilege_escalation_user_process_spawn_system_process_filter` -how_to_implement: Target environment must ingest sysmon data, specifically Event ID 15. + | tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes + where Processes.process_integrity_level IN ("low","medium","high") NOT Processes.user + IN ("*SYSTEM","*LOCAL SERVICE","*NETWORK SERVICE","DWM-*","*$") AND Processes.process_path + IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") by Processes.dest, + Processes.user, Processes.parent_process_guid, Processes.parent_process, Processes.parent_process_name + Processes.process_name + Processes.process, Processes.process_path, Processes.process_guid, Processes.process_integrity_level, + Processes.process_current_directory | `drop_dm_object_name(Processes)` | eval join_guid + = process_guid | join max=0 dest join_guid [| tstats `security_content_summariesonly` + count max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_integrity_level + IN ("system") AND Processes.parent_process_path IN ("*\\\\*","*\\Users\\*","*\\Temp\\*","*\\ProgramData\\*") + by + Processes.dest, Processes.user, Processes.parent_process_guid, Processes.process_name, + Processes.process, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory + | `drop_dm_object_name(Processes)` | rename parent_process_guid as join_guid, process* + as system_process*, user as system_user ] | fields dest, user, parent_process, parent_process_name, + parent_process_guid, process, process_name, process_guid, process_integrity_level,process_path, + process_current_directory, system_process_name, system_process, system_process_path, + system_process_integrity_level, system_process_current_directory, system_user, firstTime, + lastTime, count | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_privilege_escalation_user_process_spawn_system_process_filter` +how_to_implement: Target environment must ingest sysmon data, specifically Event ID + 15. known_false_positives: Unknown references: - - https://attack.mitre.org/techniques/T1068/ - - https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor - - https://redcanary.com/blog/getsystem-offsec/ - - https://atomicredteam.io/privilege-escalation/T1134.001/ +- https://attack.mitre.org/techniques/T1068/ +- https://vuls.cert.org/confluence/display/Wiki/2021/06/21/Finding+Privilege+Escalation+Vulnerabilities+in+Windows+using+Process+Monitor +- https://redcanary.com/blog/getsystem-offsec/ +- https://atomicredteam.io/privilege-escalation/T1134.001/ tags: analytic_story: - - Windows Privilege Escalation + - Windows Privilege Escalation asset_type: Endpoint confidence: 80 impact: 100 - message: The user $user$ launched a process [$process_name$] which spawned a system level integrity process [$system_process$]. + message: The user $user$ launched a process [$process_name$] which spawned a system + level integrity process [$system_process$]. mitre_attack_id: - - T1068 - - T1548 - - T1134 + - T1068 + - T1548 + - T1134 observable: - - name: dest - role: - - Victim - type: Hostname - - name: user - role: - - Victim - type: User - - name: process_name - role: - - Attacker - type: Other + - name: dest + role: + - Victim + type: Hostname + - name: user + role: + - Victim + type: User + - name: process_name + role: + - Attacker + type: Other product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - dest - - user - - ParentUser - - parent_process_name - - parent_process_guid - - IntegrityLevel + - _time + - dest + - user + - ParentUser + - parent_process_name + - parent_process_guid + - IntegrityLevel risk_score: 80 security_domain: endpoint tests: - - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog - update_timestamp: true - name: True Positive Test +- attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/windows_escalation_behavior/windows_escalation_behavior_sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: XmlWinEventLog + update_timestamp: true + name: True Positive Test diff --git a/detections/endpoint/windows_process_commandline_discovery.yml b/detections/endpoint/windows_process_commandline_discovery.yml index 38db348055..8f0e4adcdb 100644 --- a/detections/endpoint/windows_process_commandline_discovery.yml +++ b/detections/endpoint/windows_process_commandline_discovery.yml @@ -1,22 +1,27 @@ name: Windows Process Commandline Discovery id: 67d2a52e-a7e2-4a5d-ae44-a21212048bc2 -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 1 -description: The following analytic detects Windows Management Instrumentation Command-line (WMIC) command - used to retrieve information about running processes and specifically fetches the command lines used to launch those processes. - This Hunting detection can be a good indicator for possible suspicious user or process getting list of process with its command line using wmic application which is not a - common practice for a non-technical user. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where `process_wmic` Processes.process= "* process *" Processes.process= "* get commandline *" by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_process_commandline_discovery_filter`' +description: The following analytic detects the use of Windows Management Instrumentation + Command-line (WMIC) to retrieve information about running processes, specifically + targeting the command lines used to launch those processes. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on logs containing + process details and command-line executions. This activity is significant as it + may indicate suspicious behavior, such as a user or process gathering detailed process + information, which is uncommon for non-technical users. If confirmed malicious, + this could allow an attacker to gain insights into running processes, aiding in + further exploitation or lateral movement. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where `process_wmic` Processes.process= + "* process *" Processes.process= "* get commandline *" by Processes.dest Processes.user + Processes.parent_process Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_process_commandline_discovery_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -26,7 +31,8 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: Administrators or power users may use this command for troubleshooting. Filter as needed. +known_false_positives: Administrators or power users may use this command for troubleshooting. + Filter as needed. references: - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a tags: @@ -35,7 +41,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 30 - message: Activity related to process commandline discovery detected on $dest$ using wmic.exe. + message: Activity related to process commandline discovery detected on $dest$ using + wmic.exe. mitre_attack_id: - T1057 observable: @@ -65,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1057/process_commandline_discovery/wmic-cmdline-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1057/process_commandline_discovery/wmic-cmdline-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_process_injection_in_non_service_searchindexer.yml b/detections/endpoint/windows_process_injection_in_non_service_searchindexer.yml index 880e6bb0bd..8eee5c8a5b 100644 --- a/detections/endpoint/windows_process_injection_in_non_service_searchindexer.yml +++ b/detections/endpoint/windows_process_injection_in_non_service_searchindexer.yml @@ -1,26 +1,26 @@ name: Windows Process Injection In Non-Service SearchIndexer id: d131673f-ede1-47f2-93a1-0108d3e7fafd -version: 1 -date: '2024-01-03' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies a non-service searchindexer.exe process. - QakBot, a notorious banking trojan and information stealer, often deploys a process named "searchindexer.exe" - as part of its malicious activities. This legitimate Windows process, "Search Indexer," is manipulated by - QakBot to masquerade and evade detection within the system. The malware uses this deceptive tactic to - camouflage its presence, remaining inconspicuous while performing unauthorized actions like data exfiltration, - keystroke logging, and communication with command and control servers. By adopting the guise of a genuine system process, - the malicious "searchindexer.exe" process helps QakBot evade scrutiny and continue its malevolent operations without arousing suspicion. +description: The following analytic identifies instances of the searchindexer.exe + process that are not spawned by services.exe, indicating potential process injection. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process names and parent processes. This activity is significant because + QakBot malware often uses a fake searchindexer.exe to evade detection and perform + malicious actions such as data exfiltration and keystroke logging. If confirmed + malicious, this activity could allow attackers to maintain persistence, steal sensitive + information, and communicate with command and control servers. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name != services.exe Processes.process_name=searchindexer.exe - by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_process_injection_in_non_service_searchindexer_filter`' + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name + != services.exe Processes.process_name=searchindexer.exe by Processes.dest Processes.user + Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_process_injection_in_non_service_searchindexer_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -71,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/non-service-searchindexer/seaarch-indexer-non-service.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/non-service-searchindexer/seaarch-indexer-non-service.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_process_injection_into_notepad.yml b/detections/endpoint/windows_process_injection_into_notepad.yml index b13bc011e0..5402b29917 100644 --- a/detections/endpoint/windows_process_injection_into_notepad.yml +++ b/detections/endpoint/windows_process_injection_into_notepad.yml @@ -1,23 +1,32 @@ name: Windows Process Injection into Notepad id: b8340d0f-ba48-4391-bea7-9e793c5aae36 -version: 1 -date: '2023-02-22' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk type: Anomaly status: production data_source: - Sysmon EventID 10 -description: The following analytic utilizes Sysmon to identify process injection into Notepad.exe, based on GrantedAccess requests - 0x40 and 0x1fffff. This particular behavior is attributed to the defaults of the SliverC2 framework by BishopFox. - By default, the analytic filters out any SourceImage paths of System32, Syswow64 and program files. Add more as needed, or remove and monitor what is consistently injecting into notepad.exe. - This particular behavior will occur from a source image that is the initial payload dropped. -search: '`sysmon` EventCode=10 TargetImage IN (*\\notepad.exe) NOT (SourceImage IN ("*\\system32\\*","*\\syswow64\\*","*\\Program Files\\*")) GrantedAccess IN ("0x40","0x1fffff") | stats count min(_time) as firstTime max(_time) as lastTime by dest SourceImage TargetImage GrantedAccess CallTrace - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_process_injection_into_notepad_filter`' +description: The following analytic detects process injection into Notepad.exe using + Sysmon EventCode 10. It identifies suspicious GrantedAccess requests (0x40 and 0x1fffff) + to Notepad.exe, excluding common system paths like System32, Syswow64, and Program + Files. This behavior is often associated with the SliverC2 framework by BishopFox. + Monitoring this activity is crucial as it may indicate an initial payload attempting + to execute malicious code within Notepad.exe. If confirmed malicious, this could + allow attackers to execute arbitrary code, potentially leading to privilege escalation + or persistent access within the environment. +search: '`sysmon` EventCode=10 TargetImage IN (*\\notepad.exe) NOT (SourceImage IN + ("*\\system32\\*","*\\syswow64\\*","*\\Program Files\\*")) GrantedAccess IN ("0x40","0x1fffff") + | stats count min(_time) as firstTime max(_time) as lastTime by dest SourceImage + TargetImage GrantedAccess CallTrace | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_process_injection_into_notepad_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: False positives may be present based on SourceImage paths. If removing the paths is important, realize svchost and many native binaries inject into notepad consistently. Restrict or tune as needed. +known_false_positives: False positives may be present based on SourceImage paths. + If removing the paths is important, realize svchost and many native binaries inject + into notepad consistently. Restrict or tune as needed. references: - https://dominicbreuker.com/post/learning_sliver_c2_08_implant_basics/ - https://www.cybereason.com/blog/sliver-c2-leveraged-by-many-threat-actors @@ -27,7 +36,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 40 - message: An instance of $SourceImage$ injecting into $TargetImage$ was identified on endpoint $dest$. + message: An instance of $SourceImage$ injecting into $TargetImage$ was identified + on endpoint $dest$. mitre_attack_id: - T1055 - T1055.002 @@ -50,17 +60,18 @@ tags: - Splunk Cloud required_fields: - _time - - dest - - SourceImage - - TargetImage - - GrantedAccess + - dest + - SourceImage + - TargetImage + - GrantedAccess - CallTrace risk_score: 32 security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/T1055_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/T1055_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/endpoint/windows_process_injection_of_wermgr_to_known_browser.yml b/detections/endpoint/windows_process_injection_of_wermgr_to_known_browser.yml index 1add87c910..0079c49fc0 100644 --- a/detections/endpoint/windows_process_injection_of_wermgr_to_known_browser.yml +++ b/detections/endpoint/windows_process_injection_of_wermgr_to_known_browser.yml @@ -1,18 +1,18 @@ name: Windows Process Injection Of Wermgr to Known Browser id: aec755a5-3a2c-4be0-ab34-6540e68644e9 -version: 1 -date: '2022-10-28' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies the suspicious Remote Thread execution of wermgr.exe - process to "firefox.exe", "chrome.exe" and other known browsers. This technique - was seen in Qakbot malware that executes its malicious code by injecting its code - in legitimate Windows Operating System processes such as wermgr.exe to steal information - in the compromised host. This TTP detection can be a good pivot to detect wermgr.exe - process injected with qakbot code that tries to remote thread code execution in - known browsers like firefox and edge which is not a common behavior of this wermgr.exe - application. +description: The following analytic identifies the suspicious remote thread execution + of the wermgr.exe process into known browsers such as firefox.exe, chrome.exe, and + others. It leverages Sysmon EventCode 8 logs to detect this behavior by monitoring + SourceImage and TargetImage fields. This activity is significant because it is indicative + of Qakbot malware, which injects malicious code into legitimate processes to steal + information. If confirmed malicious, this activity could allow attackers to execute + arbitrary code, escalate privileges, and exfiltrate sensitive data from the compromised + host. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 SourceImage = "*\\wermgr.exe" TargetImage IN ("*\\firefox.exe", @@ -66,7 +66,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/remote_thread/sysmon_wermgr_remote.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/remote_thread/sysmon_wermgr_remote.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_process_injection_remote_thread.yml b/detections/endpoint/windows_process_injection_remote_thread.yml index 6b1e0960ae..8435afb15e 100644 --- a/detections/endpoint/windows_process_injection_remote_thread.yml +++ b/detections/endpoint/windows_process_injection_remote_thread.yml @@ -1,24 +1,26 @@ name: Windows Process Injection Remote Thread id: 8a618ade-ca8f-4d04-b972-2d526ba59924 -version: 1 -date: '2023-06-15' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies a suspicious remote thread execution - in some process being abused by threat actor and malware like qakbot. Qakbot is - one of the malware using this technique to load its malicious dll module or malicious - code in the targeted host. This TTP can be a good pivot to verify what is the behavior - of the targeted Image process after this detection trigger. look for network connection, - child process execution, file access and many more that helps to verify the indication - of malware infection. +description: The following analytic detects suspicious remote thread execution in + processes such as Taskmgr.exe, calc.exe, and notepad.exe, which may indicate process + injection by malware like Qakbot. This detection leverages Sysmon EventCode 8 to + identify remote thread creation in specific target processes. This activity is significant + as it often signifies an attempt by malware to inject malicious code into legitimate + processes, potentially leading to unauthorized code execution. If confirmed malicious, + this could allow attackers to execute arbitrary code, escalate privileges, or maintain + persistence on the compromised host. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 TargetImage IN ("*\\Taskmgr.exe", "*\\calc.exe", "*\\notepad.exe", "*\\rdpclip.exe", "*\\explorer.exe", "*\\wermgr.exe", "*\\ping.exe", "*\\OneDriveSetup.exe", - "*\\dxdiag.exe", "*\\mobsync.exe", "*\\msra.exe", "*\\xwizard.exe","*\\cmd.exe", "*\\powershell.exe") | stats count - min(_time) as firstTime max(_time) as lastTime by TargetImage TargetProcessId SourceProcessId EventCode - StartAddress SourceImage dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + "*\\dxdiag.exe", "*\\mobsync.exe", "*\\msra.exe", "*\\xwizard.exe","*\\cmd.exe", + "*\\powershell.exe") | stats count min(_time) as firstTime max(_time) as lastTime + by TargetImage TargetProcessId SourceProcessId EventCode StartAddress SourceImage + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_process_injection_remote_thread_filter`' how_to_implement: To successfully implement this search, you must be ingesting data that records process activity from your hosts like remote thread EventCode=8 of @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr2/sysmon_wermgr2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr2/sysmon_wermgr2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_process_injection_wermgr_child_process.yml b/detections/endpoint/windows_process_injection_wermgr_child_process.yml index 6ac021e53a..16b9b8a305 100644 --- a/detections/endpoint/windows_process_injection_wermgr_child_process.yml +++ b/detections/endpoint/windows_process_injection_wermgr_child_process.yml @@ -1,17 +1,18 @@ name: Windows Process Injection Wermgr Child Process id: 360ae6b0-38b5-4328-9e2b-bc9436cddb17 -version: 1 -date: '2022-10-27' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a suspicious wermgr.exe parent process - having a child process not related to error, fault or windows werfault event. This - technique was seen in Qakbot malware where it inject its malicious code in wermgr - to evade detections and hide from the analyst to execute its recon and its malicious - behavior. This Anomaly detection can be a good pivot to start investigating a possible - qakbot infection in the network. The Wermgr.exe process is not known to have other - child processes aside from itself or werfault.exe +description: The following analytic identifies a suspicious instance of wermgr.exe + spawning a child process unrelated to error or fault handling. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process relationships + and command-line executions. This activity is significant as it can indicate Qakbot + malware, which injects malicious code into wermgr.exe to evade detection and execute + malicious actions. If confirmed malicious, this behavior could allow an attacker + to conduct reconnaissance, execute arbitrary code, and persist within the network, + posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr/sysmon_wermgr.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_wermgr/sysmon_wermgr.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_process_injection_with_public_source_path.yml b/detections/endpoint/windows_process_injection_with_public_source_path.yml index bc57883040..9353d63f25 100644 --- a/detections/endpoint/windows_process_injection_with_public_source_path.yml +++ b/detections/endpoint/windows_process_injection_with_public_source_path.yml @@ -1,14 +1,18 @@ name: Windows Process Injection With Public Source Path id: 492f09cf-5d60-4d87-99dd-0bc325532dda -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-10' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process in a non-standard file path - on Windows attempting to create a remote thread into a process. This Windows API,CreateRemoteThread, - is commonly used by adversaries for process injection to evade detections or gain - privilege escalation. +description: The following analytic detects a process from a non-standard file path + on Windows attempting to create a remote thread in another process. This is identified + using Sysmon EventCode 8, focusing on processes not originating from typical system + directories. This behavior is significant as it often indicates process injection, + a technique used by adversaries to evade detection or escalate privileges. If confirmed + malicious, this activity could allow an attacker to execute arbitrary code within + another process, potentially leading to unauthorized actions and further compromise + of the system. data_source: - Sysmon EventID 8 search: '`sysmon` EventCode=8 TargetImage = "*.exe" AND NOT(SourceImage IN("C:\\Windows\\*", @@ -70,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/create_remote_thread/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/create_remote_thread/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_process_with_namedpipe_commandline.yml b/detections/endpoint/windows_process_with_namedpipe_commandline.yml index ebaaeafe35..ff2054e86f 100644 --- a/detections/endpoint/windows_process_with_namedpipe_commandline.yml +++ b/detections/endpoint/windows_process_with_namedpipe_commandline.yml @@ -1,18 +1,18 @@ name: Windows Process With NamedPipe CommandLine id: e64399d4-94a8-11ec-a9da-acde48001122 -version: 1 -date: '2022-02-23' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for process commandline that contains named - pipe. This technique was seen in some adversaries, threat actor and malware like - olympic destroyer to communicate to its other child processes after process injection - that serve as defense evasion and privilege escalation. On the other hand this analytic - may catch some normal process that using this technique for example browser application. - In that scenario we include common process path we've seen during testing that cause - false positive which is the program files. False positive may still be arise if - the normal application is in other folder path. +description: The following analytic detects processes with command lines containing + named pipes. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process command-line executions. This behavior is significant as it + is often used by adversaries, such as those behind the Olympic Destroyer malware, + for inter-process communication post-injection, aiding in defense evasion and privilege + escalation. If confirmed malicious, this activity could allow attackers to maintain + persistence, escalate privileges, or evade defenses, potentially leading to further + compromise of the system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/olympic_destroyer/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/olympic_destroyer/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_process_writing_file_to_world_writable_path.yml b/detections/endpoint/windows_process_writing_file_to_world_writable_path.yml index 1f0033d53f..5b80780b15 100644 --- a/detections/endpoint/windows_process_writing_file_to_world_writable_path.yml +++ b/detections/endpoint/windows_process_writing_file_to_world_writable_path.yml @@ -1,25 +1,46 @@ name: Windows Process Writing File to World Writable Path id: c051b68c-60f7-4022-b3ad-773bec7a225b -version: 1 -date: '2024-04-17' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk data_source: [] type: Hunting status: production -description: The following analytic identifies a process writing a file, specifically a .txt, to a world writable path. This technique is used by adversaries to deliver payloads to a system. It is not common for living off the land binaries to write to these paths. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name=*.txt Filesystem.file_path IN ("*\\Windows\\Tasks\\*", "*\\Windows\\Temp\\*", "*\\Windows\\tracing\\*", "*\\Windows\\PLA\\Reports\\*", "*\\Windows\\PLA\\Rules\\*", "*\\Windows\\PLA\\Templates\\*", "*\\Windows\\PLA\\Reports\\en-US\\*", "*\\Windows\\PLA\\Rules\\en-US\\*", "*\\Windows\\Registration\\CRMLog\\*", "*\\Windows\\System32\\Tasks\\*", "*\\Windows\\System32\\Com\\dmp\\*", "*\\Windows\\System32\\LogFiles\\WMI\\*", "*\\Windows\\System32\\Microsoft\\Crypto\\RSA\\MachineKeys\\*", "*\\Windows\\System32\\spool\\PRINTERS\\*", "*\\Windows\\System32\\spool\\SERVERS\\*", "*\\Windows\\System32\\spool\\drivers\\color\\*", "*\\Windows\\System32\\Tasks\\Microsoft\\Windows\\RemoteApp and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\*", "*\\Windows\\SysWOW64\\Com\\dmp\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\RemoteApp and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\System\\*") by Filesystem.dest, Filesystem.user, Filesystem.file_name Filesystem.file_path - | `drop_dm_object_name("Filesystem")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_process_writing_file_to_world_writable_path_filter`' +description: The following analytic identifies a process writing a .txt file to a + world writable path. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on file creation events within specific directories. This + activity is significant as adversaries often use such techniques to deliver payloads + to a system, which is uncommon for legitimate processes. If confirmed malicious, + this behavior could allow attackers to execute arbitrary code, escalate privileges, + or maintain persistence within the environment, posing a significant security risk. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name=*.txt + Filesystem.file_path IN ("*\\Windows\\Tasks\\*", "*\\Windows\\Temp\\*", "*\\Windows\\tracing\\*", + "*\\Windows\\PLA\\Reports\\*", "*\\Windows\\PLA\\Rules\\*", "*\\Windows\\PLA\\Templates\\*", + "*\\Windows\\PLA\\Reports\\en-US\\*", "*\\Windows\\PLA\\Rules\\en-US\\*", "*\\Windows\\Registration\\CRMLog\\*", + "*\\Windows\\System32\\Tasks\\*", "*\\Windows\\System32\\Com\\dmp\\*", "*\\Windows\\System32\\LogFiles\\WMI\\*", + "*\\Windows\\System32\\Microsoft\\Crypto\\RSA\\MachineKeys\\*", "*\\Windows\\System32\\spool\\PRINTERS\\*", + "*\\Windows\\System32\\spool\\SERVERS\\*", "*\\Windows\\System32\\spool\\drivers\\color\\*", + "*\\Windows\\System32\\Tasks\\Microsoft\\Windows\\RemoteApp and Desktop Connections + Update\\*", "*\\Windows\\SysWOW64\\Tasks\\*", "*\\Windows\\SysWOW64\\Com\\dmp\\*", + "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\RemoteApp + and Desktop Connections Update\\*", "*\\Windows\\SysWOW64\\Tasks\\Microsoft\\Windows\\PLA\\System\\*") + by Filesystem.dest, Filesystem.user, Filesystem.file_name Filesystem.file_path | + `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_process_writing_file_to_world_writable_path_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, - you must ingest logs that contain the file creation event, process name, file path and, file name. - These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to - the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` - data model. Use the Splunk Common Information Model (CIM) to normalize the field - names and speed up the data modeling process. -known_false_positives: False positives may occur if legitimate software writes to these paths. Modify the search to include additional file name extensions. To enhance it further, adding a join on Processes.process_name may assist with restricting the analytic to specific process names. Investigate the process and file to determine if it is malicious. + you must ingest logs that contain the file creation event, process name, file path + and, file name. These logs must be processed using the appropriate Splunk Technology + Add-ons that are specific to the EDR product. The logs must also be mapped to the + `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information + Model (CIM) to normalize the field names and speed up the data modeling process. +known_false_positives: False positives may occur if legitimate software writes to + these paths. Modify the search to include additional file name extensions. To enhance + it further, adding a join on Processes.process_name may assist with restricting + the analytic to specific process names. Investigate the process and file to determine + if it is malicious. references: - https://research.splunk.com/endpoint/efbcf8ee-bc75-47f1-8985-a5c638c4faf0/ tags: @@ -28,7 +49,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A process wrote a file name- [$file_name$] to a world writable file path [$file_path$] on host- [$dest$]. + message: A process wrote a file name- [$file_name$] to a world writable file path + [$file_path$] on host- [$dest$]. mitre_attack_id: - T1218.005 observable: @@ -56,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/mshta_tasks_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.005/atomic_red_team/mshta_tasks_windows-sysmon.log sourcetype: xmlwineventlog - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational \ No newline at end of file + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational diff --git a/detections/endpoint/windows_processes_killed_by_industroyer2_malware.yml b/detections/endpoint/windows_processes_killed_by_industroyer2_malware.yml index 89e82ebcf6..e0a30efa52 100644 --- a/detections/endpoint/windows_processes_killed_by_industroyer2_malware.yml +++ b/detections/endpoint/windows_processes_killed_by_industroyer2_malware.yml @@ -1,15 +1,18 @@ name: Windows Processes Killed By Industroyer2 Malware id: d8bea5ca-9d4a-4249-8b56-64a619109835 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to look for known processes killed by industroyer2 - malware. This technique was seen in the industroyer2 malware attack that tries to - kill several processes of windows host machines related to the energy facility network. - This anomaly might be a good indicator to check which process kill these processes - or why the process was killed. +description: The following analytic detects the termination of specific processes + by the Industroyer2 malware. It leverages Sysmon EventCode 5 to identify when processes + like "PServiceControl.exe" and "PService_PPD.exe" are killed. This activity is significant + as it targets processes related to energy facility networks, indicating a potential + attack on critical infrastructure. If confirmed malicious, this could lead to disruption + of essential services, loss of control over energy systems, and significant operational + impact. Immediate investigation is required to determine the cause and mitigate + any potential threats. data_source: - Sysmon EventID 5 search: '`sysmon` EventCode=5 process_name IN ("PServiceControl.exe", "PService_PPD.exe") @@ -62,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/industroyer2/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/industroyer2/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_protocol_tunneling_with_plink.yml b/detections/endpoint/windows_protocol_tunneling_with_plink.yml index 1807530c44..9acb8d813b 100644 --- a/detections/endpoint/windows_protocol_tunneling_with_plink.yml +++ b/detections/endpoint/windows_protocol_tunneling_with_plink.yml @@ -1,15 +1,18 @@ name: Windows Protocol Tunneling with Plink id: 8aac5e1e-0fab-4437-af0b-c6e60af23eed -version: 1 -date: '2022-09-15' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of Plink being utilized to - proxy egress or laterally in an organization. The analytic is limited to specific - Plink options on the command-line, including -R -L and -D which will have the remote - and local IP address or port and -l for a username. Modify the options as seen fit - for your organization. +description: The following analytic detects the use of Plink for protocol tunneling, + either for egress or lateral movement within an organization. It identifies specific + Plink command-line options (-R, -L, -D, -l) by analyzing process execution logs + from Endpoint Detection and Response (EDR) agents. This activity is significant + as it may indicate an attempt to bypass network security controls or establish unauthorized + connections. If confirmed malicious, this could allow an attacker to exfiltrate + data, move laterally across the network, or maintain persistent access, posing a + severe threat to the organization's security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,7 +88,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/plink/plink-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/plink/plink-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_proxy_via_netsh.yml b/detections/endpoint/windows_proxy_via_netsh.yml index 7af5aa8699..b98c7ba434 100644 --- a/detections/endpoint/windows_proxy_via_netsh.yml +++ b/detections/endpoint/windows_proxy_via_netsh.yml @@ -1,18 +1,21 @@ name: Windows Proxy Via Netsh id: c137bfe8-6036-4cff-b77b-4e327dd0a1cf -version: 1 -date: '2023-05-25' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This search looks for processes launching netsh.exe for connection proxy. - Netsh is a command-line scripting utility that allows you to, either locally or - remotely, display or modify the network configuration of a computer that is currently - running. Netsh can be used as a persistence proxy technique to execute a helper - DLL when netsh.exe is executed. In this search, we are looking for processes spawned - by netsh.exe and executing commands via the command line. +description: The following analytic identifies the use of netsh.exe to configure a + connection proxy, which can be leveraged for persistence by executing a helper DLL. + It detects this activity by analyzing process creation events from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions involving "portproxy" + and "v4tov4" parameters. This activity is significant because it indicates potential + unauthorized network configuration changes, which could be used to maintain persistence + or redirect network traffic. If confirmed malicious, this could allow an attacker + to maintain covert access or manipulate network communications, posing a significant + security risk. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_netsh` Processes.process = "* portproxy *" Processes.process = "* v4tov4 *" by Processes.parent_process_name @@ -72,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.001/netsh_portproxy/volt_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.001/netsh_portproxy/volt_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_proxy_via_registry.yml b/detections/endpoint/windows_proxy_via_registry.yml index b5a8023d8f..1632eb4c23 100644 --- a/detections/endpoint/windows_proxy_via_registry.yml +++ b/detections/endpoint/windows_proxy_via_registry.yml @@ -1,25 +1,26 @@ name: Windows Proxy Via Registry id: 0270455b-1385-4579-9ac5-e77046c508ae -version: 1 -date: '2023-05-25' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: This search looks for processes launching netsh.exe for connection proxy. Netsh is a command-line - scripting utility that allows you to, either locally or remotely, display or modify - the network configuration of a computer that is currently running. Netsh can be - used as a persistence proxy technique to execute a helper DLL when netsh.exe is - executed. In this search, we are looking for processes spawned by netsh.exe and - executing commands via the command line. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry - where Registry.registry_path ="*\\System\\CurrentControlSet\\Services\\PortProxy\\v4tov4\\tcp*" - by Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.action Registry.dest Registry.user - | `security_content_ctime(lastTime)` - | `security_content_ctime(firstTime)` - | `drop_dm_object_name(Registry)` +description: The following analytic detects the modification of registry keys related + to the Windows Proxy settings via netsh.exe. It leverages data from the Endpoint.Registry + data model, focusing on changes to the registry path "*\\System\\CurrentControlSet\\Services\\PortProxy\\v4tov4\\tcp*". + This activity is significant because netsh.exe can be used to establish a persistent + proxy, potentially allowing an attacker to execute a helper DLL whenever netsh.exe + runs. If confirmed malicious, this could enable the attacker to maintain persistence, + manipulate network configurations, and potentially exfiltrate data or further compromise + the system. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime + max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path + ="*\\System\\CurrentControlSet\\Services\\PortProxy\\v4tov4\\tcp*" by Registry.registry_path + Registry.registry_key_name Registry.registry_value_name Registry.action Registry.dest Registry.user + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` | `windows_proxy_via_registry_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your @@ -63,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.001/netsh_portproxy/volt_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.001/netsh_portproxy/volt_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_query_registry_browser_list_application.yml b/detections/endpoint/windows_query_registry_browser_list_application.yml index 730049090c..0d91467a1e 100644 --- a/detections/endpoint/windows_query_registry_browser_list_application.yml +++ b/detections/endpoint/windows_query_registry_browser_list_application.yml @@ -1,27 +1,31 @@ name: Windows Query Registry Browser List Application id: 45ebd21c-f4bf-4ced-bd49-d25b6526cebb -version: 1 -date: '2023-04-25' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: The following analytic identifies a suspicious process accessing default internet browsers registry entry. - This registry is used by Windows to store information about default internet browsers installed on a system. - Malware, adversaries or red-teamers can abuse this registry key to collect data about the installed internet browsers and their associated settings. - This information can be used to steal sensitive data such as login credentials, browsing history, and saved passwords. - We observed noise that needs to be filter out so we add several known path of Windows Application to make this detection more stable. -search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\SOFTWARE\\Clients\\StartMenuInternet\\*", "*\\SOFTWARE\\Clients\\StartMenuInternet\\*") - AND NOT (process_path IN ("*:\\Windows\\System32\\*", "*:\\Windows\\SysWow64\\*", "*:\\Program Files*", "*:\\Windows\\*")) - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_query_registry_browser_list_application_filter`' +description: The following analytic detects a suspicious process accessing the registry + entries for default internet browsers. It leverages Windows Security Event logs, + specifically event code 4663, to identify access attempts to these registry paths. + This activity is significant because adversaries can exploit this registry key to + gather information about installed browsers and their settings, potentially leading + to the theft of sensitive data such as login credentials and browsing history. If + confirmed malicious, this behavior could enable attackers to exfiltrate sensitive + information and compromise user accounts. +search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\SOFTWARE\\Clients\\StartMenuInternet\\*", + "*\\SOFTWARE\\Clients\\StartMenuInternet\\*") AND NOT (process_path IN ("*:\\Windows\\System32\\*", + "*:\\Windows\\SysWow64\\*", "*:\\Program Files*", "*:\\Windows\\*")) | stats count + min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path + process_name process_path process_id EventCode dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_query_registry_browser_list_application_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." -known_false_positives: uninstall application may access this registry to remove the entry of the target application. filter is needed. +known_false_positives: uninstall application may access this registry to remove the + entry of the target application. filter is needed. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer tags: @@ -30,7 +34,7 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A suspicious process accessing installed default browser registry on $dest$ + message: A suspicious process accessing installed default browser registry on $dest$ mitre_attack_id: - T1012 observable: @@ -56,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/browser_list/ar3_4663_redline_reg.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/browser_list/ar3_4663_redline_reg.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_query_registry_reg_save.yml b/detections/endpoint/windows_query_registry_reg_save.yml index daa3ebe21b..8e299c1a7b 100644 --- a/detections/endpoint/windows_query_registry_reg_save.yml +++ b/detections/endpoint/windows_query_registry_reg_save.yml @@ -1,17 +1,17 @@ name: Windows Query Registry Reg Save id: cbee60c1-b776-456f-83c2-faa56bdbe6c6 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process execution of reg.exe with - "save" parameter. This reg.exe parameter is commonly being abused by threat actors, - adversaries and red-teamers to dump credentials or to check the registry modification - capabilities of certain users or administrators in targeted hosts. This approach - was seen in post-exploitation tool like winpeas where it uses "reg save" and "reg - restore" to check registry modification restriction in targeted host after gaining - access to it. +description: The following analytic detects the execution of the reg.exe process with + the "save" parameter. This detection leverages data from Endpoint Detection and + Response (EDR) agents, focusing on process execution logs and command-line arguments. + This activity is significant because threat actors often use the "reg save" command + to dump credentials or test registry modification capabilities on compromised hosts. + If confirmed malicious, this behavior could allow attackers to escalate privileges, + persist in the environment, or access sensitive information stored in the registry. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_query_registry_uninstall_program_list.yml b/detections/endpoint/windows_query_registry_uninstall_program_list.yml index b4a3f63fdb..b6d63d8d56 100644 --- a/detections/endpoint/windows_query_registry_uninstall_program_list.yml +++ b/detections/endpoint/windows_query_registry_uninstall_program_list.yml @@ -1,25 +1,28 @@ name: Windows Query Registry UnInstall Program List id: 535fd4fc-7151-4062-9d7e-e896bea77bf6 -version: 1 -date: '2023-04-25' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: The following analytic identifies a suspicious query on uninstall application list in Windows OS registry. - This registry is commonly used by legitimate software to store information about installed applications on a Windows system, such as their name, version, publisher, and installation path. - However, malware, adversaries or even red-teamers can abuse this registry key to retrieve information stored in the "Uninstall" key to gather data about installed applications in the target host. - This Anomaly detection can be a good pivot to detect a possible suspicious process accessing this registry which is not commonly accessed by a normal user. -search: '`wineventlog_security` EventCode=4663 object_file_path="\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*" - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_query_registry_uninstall_program_list_filter`' +description: The following analytic detects a suspicious query on the uninstall application + list in the Windows OS registry. It leverages Windows Security Event logs, specifically + event code 4663, to identify access to the "Uninstall" registry key. This activity + is significant because adversaries or malware can exploit this key to gather information + about installed applications, aiding in further attacks. If confirmed malicious, + this behavior could allow attackers to map out installed software, potentially identifying + vulnerabilities or software to exploit, leading to further system compromise. +search: '`wineventlog_security` EventCode=4663 object_file_path="\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*" + | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name + object_file_path process_name process_path process_id EventCode dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_query_registry_uninstall_program_list_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." -known_false_positives: Uninstall application may access this registry to remove the entry of the target application. Filter is needed. +known_false_positives: Uninstall application may access this registry to remove the + entry of the target application. Filter is needed. references: - https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer tags: @@ -28,7 +31,7 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A suspicious process $process_name$ accessing uninstall registry on $dest$ + message: A suspicious process $process_name$ accessing uninstall registry on $dest$ mitre_attack_id: - T1012 observable: @@ -54,6 +57,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/recon_registry/recon-reg-redline-security-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/recon_registry/recon-reg-redline-security-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_raccine_scheduled_task_deletion.yml b/detections/endpoint/windows_raccine_scheduled_task_deletion.yml index 250667861a..fda8529ff6 100644 --- a/detections/endpoint/windows_raccine_scheduled_task_deletion.yml +++ b/detections/endpoint/windows_raccine_scheduled_task_deletion.yml @@ -1,15 +1,17 @@ name: Windows Raccine Scheduled Task Deletion id: c9f010da-57ab-11ec-82bd-acde48001122 -version: 1 -date: '2021-12-07' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the Raccine Rules Updater scheduled - task being deleted. Adversaries may attempt to remove this task in order to prevent - the update of Raccine. Raccine is a "ransomware vaccine" created by security researcher - Florian Roth, designed to intercept and prevent precursors and active ransomware - behavior. +description: The following analytic identifies the deletion of the Raccine Rules Updater + scheduled task using the `schtasks.exe` command. This detection leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process names and command-line + executions. This activity is significant because adversaries may delete this task + to disable Raccine, a tool designed to prevent ransomware attacks. If confirmed + malicious, this action could allow ransomware to execute without interference, leading + to potential data encryption and loss. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/windows-sysmon_raccine.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.001/atomic_red_team/windows-sysmon_raccine.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_rapid_authentication_on_multiple_hosts.yml b/detections/endpoint/windows_rapid_authentication_on_multiple_hosts.yml index 0737a0cc85..745a615e16 100644 --- a/detections/endpoint/windows_rapid_authentication_on_multiple_hosts.yml +++ b/detections/endpoint/windows_rapid_authentication_on_multiple_hosts.yml @@ -1,26 +1,29 @@ name: Windows Rapid Authentication On Multiple Hosts id: 62606c77-d53d-4182-9371-b02cdbbbcef7 -version: 1 -date: '2023-03-23' +version: 2 +date: '2024-05-16' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 4624 -description: The following analytic leverages Event ID 4624 to identify a source computer authenticating to a large number of remote endpoints within an Active Directory network. - Specifically, the logic will trigger when a source endpoint authenticates to 30 or more target computers within a 5 minute timespan. This behavior could represent an adversary who is - moving laterally across the environment or enumerating network shares in the search for sensitive files. - As environments differ across organizations, security teams should customize the thresholds of this detection as needed. -search: ' `wineventlog_security` EventCode=4624 LogonType=3 TargetUserName!="ANONYMOUS LOGON" TargetUserName!="*$" - | bucket span=5m _time - | stats dc(Computer) AS unique_targets values(Computer) as host_targets by _time, IpAddress, TargetUserName - | where unique_targets > 30 - | `windows_rapid_authentication_on_multiple_hosts_filter`' +description: The following analytic detects a source computer authenticating to 30 + or more remote endpoints within a 5-minute timespan using Event ID 4624. This behavior + is identified by analyzing Windows Event Logs for LogonType 3 events and counting + unique target computers. Such activity is significant as it may indicate lateral + movement or network share enumeration by an adversary. If confirmed malicious, this + could lead to unauthorized access to multiple systems, potentially compromising + sensitive data and escalating privileges within the network. +search: ' `wineventlog_security` EventCode=4624 LogonType=3 TargetUserName!="ANONYMOUS + LOGON" TargetUserName!="*$" | bucket span=5m _time | stats dc(Computer) AS unique_targets + values(Computer) as host_targets by _time, IpAddress, TargetUserName | where unique_targets + > 30 | `windows_rapid_authentication_on_multiple_hosts_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. -known_false_positives: Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed. +known_false_positives: Vulnerability scanners or system administration tools may also + trigger this detection. Filter as needed. references: - https://attack.mitre.org/techniques/T1135/ - https://thedfirreport.com/2023/01/23/sharefinder-how-threat-actors-discover-file-shares/ @@ -32,7 +35,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 60 - message: The source computer with ip address $IpAddress$ authenticated to a large number of remote endpoints within 5 minutes. + message: The source computer with ip address $IpAddress$ authenticated to a large + number of remote endpoints within 5 minutes. mitre_attack_id: - T1003.002 observable: @@ -60,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/rapid_authentication_multiple_hosts/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1135/rapid_authentication_multiple_hosts/windows-security.log source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_rasautou_dll_execution.yml b/detections/endpoint/windows_rasautou_dll_execution.yml index 38736f2cec..ab0e7049ac 100644 --- a/detections/endpoint/windows_rasautou_dll_execution.yml +++ b/detections/endpoint/windows_rasautou_dll_execution.yml @@ -1,14 +1,18 @@ name: Windows Rasautou DLL Execution id: 6f42b8be-8e96-11ec-ad5a-acde48001122 -version: 1 -date: '2022-02-15' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the Windows Windows Remote Auto Dialer, - rasautou.exe executing an arbitrary DLL. This technique is used to execute arbitrary - shellcode or DLLs via the rasautou.exe LOLBin capability. During triage, review - parent and child process behavior including file and image loads. +description: The following analytic detects the execution of an arbitrary DLL by the + Windows Remote Auto Dialer (rasautou.exe). This behavior is identified by analyzing + process creation events where rasautou.exe is executed with specific command-line + arguments. This activity is significant because it leverages a Living Off The Land + Binary (LOLBin) to execute potentially malicious code, bypassing traditional security + controls. If confirmed malicious, this technique could allow an attacker to execute + arbitrary code, potentially leading to system compromise, privilege escalation, + or persistent access within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +84,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055.001/rasautou/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055.001/rasautou/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml b/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml index 5a801f2b58..7f86e6ccc8 100644 --- a/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml +++ b/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml @@ -1,20 +1,24 @@ name: Windows Raw Access To Disk Volume Partition id: a85aa37e-9647-11ec-90c5-acde48001122 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to look for suspicious raw access read to device disk - partition of the host machine. This technique was seen in several attacks by adversaries - or threat actor to wipe, encrypt or overwrite the boot sector of each partition - as part of their impact payload for example the "hermeticwiper" malware. This detection - is a good indicator that there is a process try to read or write on boot sector. +description: The following analytic detects suspicious raw access reads to the device + disk partition of a host machine. It leverages Sysmon EventCode 9 logs to identify + processes attempting to read or write to the boot sector, excluding legitimate system + processes. This activity is significant as it is commonly associated with destructive + actions by adversaries, such as wiping, encrypting, or overwriting the boot sector, + as seen in attacks involving malware like HermeticWiper. If confirmed malicious, + this behavior could lead to severe impacts, including system inoperability, data + loss, or compromised boot integrity. data_source: - Sysmon EventID 9 search: '`sysmon` EventCode=9 Device = \\Device\\HarddiskVolume* NOT (Image IN("*\\Windows\\System32\\*", "*\\Windows\\SysWOW64\\*")) | stats count min(_time) as firstTime max(_time) as - lastTime by dest signature signature_id process_guid process_name process_path Device | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_raw_access_to_disk_volume_partition_filter`' + lastTime by dest signature signature_id process_guid process_name process_path Device + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_raw_access_to_disk_volume_partition_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least @@ -51,12 +55,12 @@ tags: - Splunk Cloud required_fields: - _time - - dest + - dest - signature - signature_id - process_guid - process_name - - process_path + - process_path - Device - EventCode - Image @@ -65,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/hermetic_wiper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml b/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml index a3362e926e..11751c9edc 100644 --- a/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml +++ b/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml @@ -1,22 +1,24 @@ name: Windows Raw Access To Master Boot Record Drive id: 7b83f666-900c-11ec-a2d9-acde48001122 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-11' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is to look for suspicious raw access read to drive where - the master boot record is placed. This technique was seen in several attacks by - adversaries or threat actor to wipe, encrypt or overwrite the master boot record - code as part of their impact payload. This detection is a good indicator that there - is a process try to read or write on MBR sector. +description: The following analytic detects suspicious raw access reads to the drive + containing the Master Boot Record (MBR). It leverages Sysmon EventCode 9 to identify + processes attempting to read or write to the MBR sector, excluding legitimate system + processes. This activity is significant because adversaries often target the MBR + to wipe, encrypt, or overwrite it as part of their impact payload. If confirmed + malicious, this could lead to system instability, data loss, or a complete system + compromise, severely impacting the organization's operations. data_source: - Sysmon EventID 9 search: '`sysmon` EventCode=9 Device = \\Device\\Harddisk0\\DR0 NOT (Image IN("*\\Windows\\System32\\*", "*\\Windows\\SysWOW64\\*")) | stats count min(_time) as firstTime max(_time) as lastTime by Computer Image Device ProcessGuid ProcessId EventDescription EventCode - | rename Computer as dest - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_raw_access_to_master_boot_record_drive_filter`' + | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_raw_access_to_master_boot_record_drive_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least @@ -68,6 +70,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1561.002/mbr_raw_access/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1561.002/mbr_raw_access/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_rdp_connection_successful.yml b/detections/endpoint/windows_rdp_connection_successful.yml index 8202261148..8733534473 100644 --- a/detections/endpoint/windows_rdp_connection_successful.yml +++ b/detections/endpoint/windows_rdp_connection_successful.yml @@ -1,23 +1,30 @@ name: Windows RDP Connection Successful id: ceaed840-56b3-4a70-b8e1-d762b1c5c08c -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Hunting data_source: - Windows Event Log RemoteConnectionManager 1149 -description: The following analytic identifies successful remote desktop connections. Utilize this analytic to hunt for successful attempts. In addition, the query may be modified for EventCode=1148 to potentially identify failed attempts. In testing, 1148 would not generate based on a failed logon attempt. - Note this analytic requires enabling and a stanza in a inputs.conf. -search: '`remoteconnectionmanager` EventCode=1149 - | stats count min(_time) as firstTime max(_time) as lastTime by Computer, user_id - | `security_content_ctime(firstTime)` +description: The following analytic detects successful Remote Desktop Protocol (RDP) + connections by monitoring EventCode 1149 from the Windows TerminalServices RemoteConnectionManager + Operational log. This detection is significant as successful RDP connections can + indicate remote access to a system, which may be leveraged by attackers to control + or exfiltrate data. If confirmed malicious, this activity could lead to unauthorized + access, data theft, or further lateral movement within the network. Monitoring successful + RDP connections is crucial for identifying potential security breaches and mitigating + risks promptly. +search: '`remoteconnectionmanager` EventCode=1149 | stats count min(_time) as firstTime + max(_time) as lastTime by Computer, user_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename Computer as dest | `windows_rdp_connection_successful_filter`' -how_to_implement: The following analyic requires the WIndows TerminalServices RemoteConnectionManager Operational log to be enabled and ingested into Splunk. For the inputs, review https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706. -known_false_positives: False positives will be present, filter as needed or restrict to critical assets on the perimeter. +how_to_implement: The following analyic requires the WIndows TerminalServices RemoteConnectionManager + Operational log to be enabled and ingested into Splunk. For the inputs, review https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706. +known_false_positives: False positives will be present, filter as needed or restrict + to critical assets on the perimeter. references: - - https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706 - - https://doublepulsar.com/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6 +- https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706 +- https://doublepulsar.com/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6 tags: analytic_story: - Active Directory Lateral Movement @@ -49,6 +56,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1563.002/windows_rdp_connection_successful/windows-xml.log - source: WinEventLog:Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1563.002/windows_rdp_connection_successful/windows-xml.log + source: + WinEventLog:Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_registry_bootexecute_modification.yml b/detections/endpoint/windows_registry_bootexecute_modification.yml index 422d8f208d..c2ba83897b 100644 --- a/detections/endpoint/windows_registry_bootexecute_modification.yml +++ b/detections/endpoint/windows_registry_bootexecute_modification.yml @@ -1,23 +1,35 @@ name: Windows Registry BootExecute Modification id: eabbac3a-45aa-4659-920f-6b8cff383fb8 -version: 1 -date: '2023-05-03' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: This analytic monitors the BootExecute registry key for any modifications from its default value, which could indicate potential malicious activity. The BootExecute registry key, located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager, manages the list of applications and services that are executed during system boot. By default, the BootExecute value is set to "autocheck autochk *". Attackers might attempt to modify this value to achieve persistence, load malicious code, or tamper with the system's boot process. +description: The following analytic detects modifications to the BootExecute registry + key, which manages applications and services executed during system boot. It leverages + data from the Endpoint.Registry data model, focusing on changes to the registry + path "HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\BootExecute". This + activity is significant because unauthorized changes to this key can indicate attempts + to achieve persistence, load malicious code, or tamper with the boot process. If + confirmed malicious, this could allow an attacker to maintain persistence, execute + arbitrary code at boot, or disrupt system operations. search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry - WHERE Registry.registry_path="HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\BootExecute" BY _time span=1h Registry.dest Registry.registry_path Registry.registry_key_name - Registry.registry_value_name Registry.registry_value_data Registry.process_guid, Registry.action - | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) + WHERE Registry.registry_path="HKLM\\System\\CurrentControlSet\\Control\\Session + Manager\\BootExecute" BY _time span=1h Registry.dest Registry.registry_path Registry.registry_key_name + Registry.registry_value_name Registry.registry_value_data Registry.process_guid, + Registry.action | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `windows_registry_bootexecute_modification_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on Windows Registry that include the name of the path and key responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. +how_to_implement: To successfully implement this search you need to be ingesting information + on Windows Registry that include the name of the path and key responsible for the + changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. + In addition, confirm the latest CIM App 4.20 or higher is installed and the latest + TA for the endpoint product. known_false_positives: False positives may be present and will need to be filtered. references: - - https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ +- https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ tags: analytic_story: - Windows BootKits @@ -25,7 +37,8 @@ tags: atomic_guid: [] confidence: 100 impact: 100 - message: The Registry BootExecute value was modified on $dest$ and should be reviewed immediately. + message: The Registry BootExecute value was modified on $dest$ and should be reviewed + immediately. mitre_attack_id: - T1542 - T1547.001 @@ -41,17 +54,18 @@ tags: risk_score: 100 required_fields: - _time - - Registry.dest - - Registry.registry_path + - Registry.dest + - Registry.registry_path - Registry.registry_key_name - - Registry.registry_value_name - - Registry.registry_value_data + - Registry.registry_value_name + - Registry.registry_value_data - Registry.process_guid - Registry.action security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.001/atomic_red_team/bootexecute-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.001/atomic_red_team/bootexecute-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_registry_certificate_added.yml b/detections/endpoint/windows_registry_certificate_added.yml index a759a266f8..a74e8c78bc 100644 --- a/detections/endpoint/windows_registry_certificate_added.yml +++ b/detections/endpoint/windows_registry_certificate_added.yml @@ -1,19 +1,18 @@ name: Windows Registry Certificate Added id: 5ee98b2f-8b9e-457a-8bdc-dd41aaba9e87 -version: 2 -date: '2023-04-27' +version: 3 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies installation of a root CA certificate - by monitoring the registry. The base paths may be found [here](https://gist.github.com/mattifestation/75d6117707bcf8c26845b3cbb6ad2b6b/raw/ae65ef15c706140ffc2e165615204e20f2903028/RootCAInstallationDetection.xml). - In short, there are specific certificate registry paths that will be written to - (SetValue) when a new certificate is added. The high-fidelity events to pay attention - to are SetValue events where the TargetObject property ends with "\Blob" - as this indicates the direct installation or modification of a root certificate - binary blob. The other high fidelity reference will be which process is making the - registry modifications. There are very few processes that modify these day to day, - therefore monitoring for all to start (hunting) provides a great beginning. +description: The following analytic detects the installation of a root CA certificate + by monitoring specific registry paths for SetValue events. It leverages data from + the Endpoint datamodel, focusing on registry paths containing "certificates" and + registry values named "Blob." This activity is significant because unauthorized + root CA certificates can compromise the integrity of encrypted communications and + facilitate man-in-the-middle attacks. If confirmed malicious, this could allow an + attacker to intercept, decrypt, or manipulate sensitive data, leading to severe + security breaches. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -21,9 +20,7 @@ search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint where Registry.registry_path IN ("*\\certificates\\*") AND Registry.registry_value_name="Blob" by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.process_guid Registry.registry_key_name Registry.registry_value_data | - `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_registry_certificate_added_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from @@ -67,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.002/atomic_red_team/certblob_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.002/atomic_red_team/certblob_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_registry_delete_task_sd.yml b/detections/endpoint/windows_registry_delete_task_sd.yml index daecfd42a2..ddbac21920 100644 --- a/detections/endpoint/windows_registry_delete_task_sd.yml +++ b/detections/endpoint/windows_registry_delete_task_sd.yml @@ -1,18 +1,18 @@ name: Windows Registry Delete Task SD id: ffeb7893-ff06-446f-815b-33ca73224e92 -version: 1 -date: '2022-04-13' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies a process attempting to delete a scheduled - task SD (Security Descriptor) from within the registry path of that task. This may - occur from a non-standard process running and may not come from reg.exe. This particular - behavior will remove the actual Task Name from the Task Scheduler GUI and from the - command-line query - schtasks.exe /query. In addition, in order to perform this - action, the user context will need to be SYSTEM. - - Identifying the deletion of a scheduled task's Security Descriptor from the registry is significant for a SOC as it may indicate malicious activity attempting to remove evidence of a scheduled task, potentially for defense evasion purposes. If a true positive is detected, it suggests an attacker with privileged access attempting to remove traces of their activities, which can have a significant impact on the security and functionality of affected systems. Immediate investigation and response are required to mitigate further risks and preserve the integrity of the environment. +description: The following analytic detects a process attempting to delete a scheduled + task's Security Descriptor (SD) from the registry path of that task. It leverages + the Endpoint.Registry data model to identify registry actions performed by the SYSTEM + user, specifically targeting deletions or modifications of the SD value. This activity + is significant as it may indicate an attempt to remove evidence of a scheduled task + for defense evasion. If confirmed malicious, it suggests an attacker with privileged + access trying to hide their tracks, potentially compromising system integrity and + security. Immediate investigation is required. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -72,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/taskschedule/sd_delete_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/taskschedule/sd_delete_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_registry_modification_for_safe_mode_persistence.yml b/detections/endpoint/windows_registry_modification_for_safe_mode_persistence.yml index a1c18bcdd1..98fc743a01 100644 --- a/detections/endpoint/windows_registry_modification_for_safe_mode_persistence.yml +++ b/detections/endpoint/windows_registry_modification_for_safe_mode_persistence.yml @@ -1,16 +1,18 @@ name: Windows Registry Modification for Safe Mode Persistence id: c6149154-c9d8-11eb-9da7-acde48001122 -version: 4 -date: '2023-04-27' +version: 5 +date: '2024-05-20' author: Teoderick Contreras, Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a modification or registry add to the - safeboot registry as an autostart mechanism. This technique is utilized by adversaries - to persist a driver or service into Safe Mode. Two keys are monitored in this analytic, Minimal - and Network. adding values to Minimal will load into Safe Mode and by adding into - Network it will provide the service or drive the ability to perform network connections - in Safe Mode. +description: The following analytic identifies modifications to the SafeBoot registry + keys, specifically within the Minimal and Network paths. This detection leverages + registry activity logs from endpoint data sources like Sysmon or EDR tools. Monitoring + these keys is crucial as adversaries can use them to persist drivers or services + in Safe Mode, with Network allowing network connections. If confirmed malicious, + this activity could enable attackers to maintain persistence even in Safe Mode, + potentially bypassing certain security measures and facilitating further malicious + actions. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -18,9 +20,7 @@ search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint where Registry.registry_path IN ("*SYSTEM\\CurrentControlSet\\Control\\SafeBoot\\Minimal\\*","*SYSTEM\\CurrentControlSet\\Control\\SafeBoot\\Network\\*") by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.process_guid Registry.registry_key_name Registry.registry_value_data | - `drop_dm_object_name(Registry)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_registry_modification_for_safe_mode_persistence_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 @@ -68,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_registry_payload_injection.yml b/detections/endpoint/windows_registry_payload_injection.yml index c662385fb3..fc5a636e73 100644 --- a/detections/endpoint/windows_registry_payload_injection.yml +++ b/detections/endpoint/windows_registry_payload_injection.yml @@ -1,15 +1,18 @@ name: Windows Registry Payload Injection id: c6b2d80f-179a-41a1-b95e-ce5601d7427a -version: 1 -date: '2023-06-15' +version: 2 +date: '2024-05-10' author: Steven Dick status: production type: TTP -description: The following analytic identifies when suspiciouly long data is written - to the registry. This behavior is often associated with certain fileless malware - threats or persistence techniques used by threat actors. Data stored in the registy - is considered fileless since it does not get written to disk and is traditionally - not well defended since normal users can modify thier own registry. +description: The following analytic detects suspiciously long data written to the + Windows registry, a behavior often linked to fileless malware or persistence techniques. + It leverages Endpoint Detection and Response (EDR) telemetry, focusing on registry + events with data lengths exceeding 512 characters. This activity is significant + as it can indicate an attempt to evade traditional file-based defenses, making it + crucial for SOC monitoring. If confirmed malicious, this technique could allow attackers + to maintain persistence, execute code, or manipulate system configurations without + leaving a conventional file footprint. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) @@ -91,6 +94,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_registry_sip_provider_modification.yml b/detections/endpoint/windows_registry_sip_provider_modification.yml index 32652368ee..b3936c9b6a 100644 --- a/detections/endpoint/windows_registry_sip_provider_modification.yml +++ b/detections/endpoint/windows_registry_sip_provider_modification.yml @@ -1,28 +1,43 @@ name: 'Windows Registry SIP Provider Modification' id: 3b4e18cb-497f-4073-85ad-1ada7c2107ab -version: 1 -date: '2023-10-10' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: 'The following analytic detects modifications to the Windows Registry SIP Provider. It identifies this behavior by monitoring Sysmon EventID 7, which logs registry modification events. The analytic specifically looks for changes in registry paths and values associated with Cryptography Providers and OID Encoding Types. This behavior is worth identifying as it may indicate an attempt to subvert trust controls, a technique often used by adversaries to bypass security measures and maintain persistence in an environment. If a true positive is found, it suggests an attacker is trying to manipulate the system''s cryptographic functions, potentially leading to unauthorized access, data theft, or other damaging outcomes. Upon triage, review the registry paths and values modified, and look for concurrent processes to identify the attack source. Review the path of the SIP being added. This approach helps analysts detect potential threats earlier and mitigate the risks.' +description: 'The following analytic detects modifications to the Windows Registry + SIP Provider. It leverages Sysmon Event ID 7 to monitor registry changes in paths + and values related to Cryptography Providers and OID Encoding Types. This activity + is significant as it may indicate an attempt to subvert trust controls, a common + tactic for bypassing security measures and maintaining persistence. If confirmed + malicious, an attacker could manipulate the system''s cryptographic functions, potentially + leading to unauthorized access, data theft, or other damaging outcomes. Review the + modified registry paths and concurrent processes to identify the attack source.' search: '| tstats `security_content_summariesonly` count values(Registry.registry_key_name) as registry_key_name values(Registry.registry_path) as registry_path min(_time) - as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path IN ("*\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\*", "*\\SOFTWARE\\Microsoft\\Cryptography\\OID\\EncodingType*", "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\Providers\\*", "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\OID\\EncodingType*") Registry.registry_value_name IN ("Dll","$DLL") by - Registry.dest , Registry.user Registry.registry_value_name, Registry.registry_value_data | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` - | `drop_dm_object_name(Registry)`| `windows_registry_sip_provider_modification_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: Be aware of potential false positives - legitimate applications may cause benign activities to be flagged. + as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path + IN ("*\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\*", "*\\SOFTWARE\\Microsoft\\Cryptography\\OID\\EncodingType*", + "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\Providers\\*", "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\OID\\EncodingType*") + Registry.registry_value_name IN ("Dll","$DLL") by Registry.dest , Registry.user + Registry.registry_value_name, Registry.registry_value_data | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)`| `windows_registry_sip_provider_modification_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: Be aware of potential false positives - legitimate applications + may cause benign activities to be flagged. references: - - https://attack.mitre.org/techniques/T1553/003/ - - https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_sip_persistence.yml - - https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf - - https://github.com/gtworek/PSBits/tree/master/SIP - - https://github.com/mattifestation/PoCSubjectInterfacePackage - - https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/ +- https://attack.mitre.org/techniques/T1553/003/ +- https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_sip_persistence.yml +- https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf +- https://github.com/gtworek/PSBits/tree/master/SIP +- https://github.com/mattifestation/PoCSubjectInterfacePackage +- https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/ tags: analytic_story: - Subvert Trust Controls SIP and Trust Provider Hijacking @@ -52,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/sip_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/sip_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_regsvr32_renamed_binary.yml b/detections/endpoint/windows_regsvr32_renamed_binary.yml index 0a89c6c59a..364564698a 100644 --- a/detections/endpoint/windows_regsvr32_renamed_binary.yml +++ b/detections/endpoint/windows_regsvr32_renamed_binary.yml @@ -1,16 +1,17 @@ name: Windows Regsvr32 Renamed Binary id: 7349a9e9-3cf6-4171-bb0c-75607a8dcd1a -version: 1 -date: '2022-10-27' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following hunting analytic identifies renamed instances of regsv32.exe - executing. regsv32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. - During investigation, validate if it is the legitimate regsv32.exe executing and - what dll module content it is loading. This query relies on the original filename - or internal name from the PE meta data. Expand the query as needed by looking for - specific command line arguments outlined in other analytics. +description: The following analytic identifies instances where the regsvr32.exe binary + has been renamed and executed. This detection leverages Endpoint Detection and Response + (EDR) data, specifically focusing on the original filename metadata. Renaming regsvr32.exe + is significant as it can be an evasion technique used by attackers to bypass security + controls. If confirmed malicious, this activity could allow an attacker to execute + arbitrary DLLs, potentially leading to code execution, privilege escalation, or + persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -68,7 +69,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_3/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/qakbot/qbot_3/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_access_software_brc4_loaded_dll.yml b/detections/endpoint/windows_remote_access_software_brc4_loaded_dll.yml index b386490ea8..8a7d263fbc 100644 --- a/detections/endpoint/windows_remote_access_software_brc4_loaded_dll.yml +++ b/detections/endpoint/windows_remote_access_software_brc4_loaded_dll.yml @@ -1,24 +1,18 @@ name: Windows Remote Access Software BRC4 Loaded Dll id: 73cf5dcb-cf36-4167-8bbe-384fe5384d05 -version: 1 -date: '2022-08-24' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following anomaly detection identifies the behavior related to 4 - native Windows DLLs being loaded by a non-standard process. Identified by MDSec - during their research into Brute Ratel, MDSec identified a high signal analytic - by calling out these 4 DLLs being loaded into a process. LogonCLI.dll is the Net - Logon Client DLL and is related to users and other domain services to get authenticated. - Credui.dll is Credential Manager User Interface. Credential managers receive notifications - when authentication information changes. For example, credential managers are notified - when a user logs on or an account password changes. Samcli.dll is the Security Accounts - Manager Client DLL. Adversaries may attempt to extract credential material from - the Security Account Manager (SAM) database either through in-memory techniques - or through the Windows Registry where the SAM database is stored. Dbghelp.dll is - Windows Image Helper. Windows Image Helper is commonly seen in credential dumping - due to native functions. All of these modules are important to monitor and track - and combined may lead to credentail access or dumping. +description: The following analytic identifies the loading of four specific Windows + DLLs (credui.dll, dbghelp.dll, samcli.dll, winhttp.dll) by a non-standard process. + This detection leverages Sysmon EventCode 7 to monitor DLL load events and flags + when all four DLLs are loaded within a short time frame. This activity is significant + as it may indicate the presence of Brute Ratel C4, a sophisticated remote access + tool used for credential dumping and other malicious activities. If confirmed malicious, + this behavior could lead to unauthorized access, credential theft, and further compromise + of the affected system. data_source: - Sysmon EventID 7 search: '`sysmon` EventCode=7 |bin _time span=30s | eval BRC4_AnomalyLoadedDll=case(OriginalFileName=="credui.dll", @@ -77,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/brute_ratel/iso_version_dll_campaign/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_access_software_hunt.yml b/detections/endpoint/windows_remote_access_software_hunt.yml index 816bedf210..cb2269e501 100644 --- a/detections/endpoint/windows_remote_access_software_hunt.yml +++ b/detections/endpoint/windows_remote_access_software_hunt.yml @@ -1,17 +1,18 @@ name: Windows Remote Access Software Hunt id: 8bd22c9f-05a2-4db1-b131-29271f28cb0a -version: 1 -date: '2022-08-22' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic is meant to help organizations understand - what remote access software is being used in the environment. When reviewing this - hunt, confirm the software identified is authorized to be utilized. Based on fidelity, - create a new analytic for specific utilities banned within the organization. Adversaries - use these utilities to retain remote access capabilities to the environment. Utilities - in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review - the lookup for the entire list and add any others. +description: The following analytic identifies the use of remote access software within + the environment. It leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process execution logs. This detection is significant as unauthorized + remote access tools can be used by adversaries to maintain persistent access to + compromised systems. If confirmed malicious, this activity could allow attackers + to remotely control systems, exfiltrate data, or further infiltrate the network. + Review the identified software to ensure it is authorized and take action against + any unauthorized utilities. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -77,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_access_software_rms_registry.yml b/detections/endpoint/windows_remote_access_software_rms_registry.yml index a7687d5d71..bb79c75394 100644 --- a/detections/endpoint/windows_remote_access_software_rms_registry.yml +++ b/detections/endpoint/windows_remote_access_software_rms_registry.yml @@ -1,15 +1,18 @@ name: Windows Remote Access Software RMS Registry id: e5b7b5a9-e471-4be8-8c5d-4083983ba329 -version: 1 -date: '2022-06-22' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is to identify a modification or creation of Windows - registry related to the Remote Manipulator System (RMS) Remote Admin tool. RMS is - a legitimate tool developed by russian organization TektonIT and has been observed - being abused by adversaries to gain remote access to the targeted host. Azorult - malware utilized RMS to gain remote access. +description: The following analytic detects the creation or modification of Windows + registry entries related to the Remote Manipulator System (RMS) Remote Admin tool. + It leverages data from the Endpoint.Registry datamodel, focusing on registry paths + containing "SYSTEM\\Remote Manipulator System." This activity is significant because + RMS, while legitimate, is often abused by adversaries, such as in the Azorult malware + campaigns, to gain unauthorized remote access. If confirmed malicious, this could + allow attackers to remotely control the targeted host, leading to potential data + exfiltration, system manipulation, or further network compromise. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -58,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_assistance_spawning_process.yml b/detections/endpoint/windows_remote_assistance_spawning_process.yml index 337b743522..9a76051121 100644 --- a/detections/endpoint/windows_remote_assistance_spawning_process.yml +++ b/detections/endpoint/windows_remote_assistance_spawning_process.yml @@ -1,16 +1,18 @@ name: Windows Remote Assistance Spawning Process id: ced50492-8849-11ec-9f68-acde48001122 -version: 1 -date: '2022-02-07' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the use of Microsoft Remote Assistance, - msra.exe, spawning PowerShell.exe or cmd.exe as a child process. Msra.exe by default - has no command-line arguments and typically spawns itself. It will generate a network - connection to the remote system that is connected. This behavior is indicative of - another process injected into msra.exe. Review the parent process or cross process - events to identify source. +description: The following analytic detects Microsoft Remote Assistance (msra.exe) + spawning PowerShell.exe or cmd.exe as a child process. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process creation + events where msra.exe is the parent process. This activity is significant because + msra.exe typically does not spawn command-line interfaces, indicating potential + process injection or misuse. If confirmed malicious, an attacker could use this + technique to execute arbitrary commands, escalate privileges, or maintain persistence + on the compromised system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -78,6 +80,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/msra/msra-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/msra/msra-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_remote_create_service.yml b/detections/endpoint/windows_remote_create_service.yml index 8e0c377a9d..e904d6be26 100644 --- a/detections/endpoint/windows_remote_create_service.yml +++ b/detections/endpoint/windows_remote_create_service.yml @@ -1,16 +1,19 @@ name: Windows Remote Create Service id: 0dc44d03-8c00-482d-ba7c-796ba7ab18c9 -version: 1 -date: '2023-03-20' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This analytic identifies an endpoint that remotely connects to another - endpoint to create a new service using sc.exe. On the remote endpoint, the new service - will be created and this action will trigger the creation of EventCode 7045 along - with all the resulting service information. +description: The following analytic identifies the creation of a new service on a + remote endpoint using sc.exe. It leverages data from Endpoint Detection and Response + (EDR) agents, specifically monitoring for EventCode 7045, which indicates a new + service creation. This activity is significant as it may indicate lateral movement + or remote code execution attempts by an attacker. If confirmed malicious, this could + allow the attacker to establish persistence, escalate privileges, or execute arbitrary + code on the remote system, potentially leading to further compromise of the network. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=sc.exe Processes.process IN ("*create*") Processes.process="*\\\\*" by Processes.dest @@ -82,7 +85,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/atomic_red_team/remote_service_create_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/atomic_red_team/remote_service_create_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_service_rdpwinst_tool_execution.yml b/detections/endpoint/windows_remote_service_rdpwinst_tool_execution.yml index 632ba7614e..8a4638c731 100644 --- a/detections/endpoint/windows_remote_service_rdpwinst_tool_execution.yml +++ b/detections/endpoint/windows_remote_service_rdpwinst_tool_execution.yml @@ -1,15 +1,18 @@ name: Windows Remote Service Rdpwinst Tool Execution id: c8127f87-c7c9-4036-89ed-8fe4b30e678c -version: 1 -date: '2022-06-24' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies RDPWInst.exe tool, which is a RDP wrapper - library tool designed to enable remote desktop host support and concurrent RDP session - on reduced functionality system. Unfortunately, this open project was abused by - adversaries to enable RDP connection to the targeted host for remote access and - potentially be for lateral movement. +description: The following analytic detects the execution of the RDPWInst.exe tool, + which is an RDP wrapper library used to enable remote desktop host support and concurrent + RDP sessions. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names, original file names, and specific command-line + arguments. This activity is significant because adversaries can abuse this tool + to establish unauthorized RDP connections, facilitating remote access and potential + lateral movement within the network. If confirmed malicious, this could lead to + unauthorized access, data exfiltration, and further compromise of the targeted host. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -69,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_services_allow_rdp_in_firewall.yml b/detections/endpoint/windows_remote_services_allow_rdp_in_firewall.yml index bc802b0584..4e48f92957 100644 --- a/detections/endpoint/windows_remote_services_allow_rdp_in_firewall.yml +++ b/detections/endpoint/windows_remote_services_allow_rdp_in_firewall.yml @@ -1,17 +1,18 @@ name: Windows Remote Services Allow Rdp In Firewall id: 9170cb54-ea15-41e1-9dfc-9f3363ce9b02 -version: 1 -date: '2022-06-21' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows firewall - to enable remote desktop protocol on a targeted machine. This technique was seen - in several adversaries, malware or red teamer to remotely access the compromised - or targeted host by allowing this protocol in firewall. Even this protocol might - be allowed in some production environment, This TTP behavior is a good pivot to - check who and why the user want to enable this feature through firewall which is - also common traits of attack to start lateral movement. +description: The following analytic detects modifications to the Windows firewall + to enable Remote Desktop Protocol (RDP) on a targeted machine. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line executions + involving "netsh.exe" to allow TCP port 3389. This activity is significant as it + may indicate an adversary attempting to gain remote access to a compromised host, + a common tactic for lateral movement. If confirmed malicious, this could allow attackers + to remotely control the system, leading to potential data exfiltration or further + network compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as cmdline @@ -70,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_services_allow_remote_assistance.yml b/detections/endpoint/windows_remote_services_allow_remote_assistance.yml index 789ffad566..0c1d265e0b 100644 --- a/detections/endpoint/windows_remote_services_allow_remote_assistance.yml +++ b/detections/endpoint/windows_remote_services_allow_remote_assistance.yml @@ -1,18 +1,18 @@ name: Windows Remote Services Allow Remote Assistance id: 9bce3a97-bc97-4e89-a1aa-ead151c82fbb -version: 1 -date: '2022-06-21' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic is to identify a modification in the Windows registry - to enable remote desktop assistance on a targeted machine. This technique was seen - in several adversaries, malware or red teamer like azorult to remotely access the - compromised or targeted host by enabling this protocol in registry. Even this protocol - might be allowed in some production environment, This Anomaly behavior is a good - pivot to check who and why the user want to enable this feature through registry - which is un-common. And as per stated in microsoft documentation the default value - of this registry is false that makes this a good indicator of suspicious behavior. +description: The following analytic detects modifications in the Windows registry + to enable remote desktop assistance on a targeted machine. It leverages data from + the Endpoint.Registry datamodel, specifically monitoring changes to the "Control\\Terminal + Server\\fAllowToGetHelp" registry path. This activity is significant because enabling + remote assistance via registry is uncommon and often associated with adversaries + or malware like Azorult. If confirmed malicious, this could allow an attacker to + remotely access and control the compromised host, leading to potential data exfiltration + or further system compromise. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -63,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_remote_services_rdp_enable.yml b/detections/endpoint/windows_remote_services_rdp_enable.yml index 6dfeead045..8cdb6f35ef 100644 --- a/detections/endpoint/windows_remote_services_rdp_enable.yml +++ b/detections/endpoint/windows_remote_services_rdp_enable.yml @@ -1,17 +1,18 @@ name: Windows Remote Services Rdp Enable id: 8fbd2e88-4ea5-40b9-9217-fd0855e08cc0 -version: 1 -date: '2022-06-21' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic is to identify a modification in the Windows registry - to enable remote desktop protocol on a targeted machine. This technique was seen - in several adversaries, malware or red teamer to remotely access the compromised - or targeted host by enabling this protocol in registry. Even this protocol might - be allowed in some production environment, This TTP behavior is a good pivot to - check who and why the user want to enable this feature through registry which is - un-common. +description: The following analytic detects modifications in the Windows registry + to enable Remote Desktop Protocol (RDP) on a targeted machine. It leverages data + from the Endpoint.Registry datamodel, specifically monitoring changes to the "fDenyTSConnections" + registry value. This activity is significant as enabling RDP via registry is uncommon + and often associated with adversaries or malware attempting to gain remote access. + If confirmed malicious, this could allow attackers to remotely control the compromised + host, potentially leading to further exploitation and lateral movement within the + network. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -61,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_replication_through_removable_media.yml b/detections/endpoint/windows_replication_through_removable_media.yml index f290098c33..a22f38ca07 100644 --- a/detections/endpoint/windows_replication_through_removable_media.yml +++ b/detections/endpoint/windows_replication_through_removable_media.yml @@ -1,21 +1,17 @@ name: Windows Replication Through Removable Media id: 60df805d-4605-41c8-bbba-57baa6a4eb97 -version: 1 -date: '2023-09-07' +version: 2 +date: '2024-05-14' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic is developed to detect suspicious executable or script - files created or dropped in the root drive of a targeted host. This technique is - commonly used by threat actors, adversaries or even red teamers to replicate or - spread in possible removable drives. Back then, WORM malware was popular for this - technique where it would drop a copy of itself in the root drive to be able to spread - or to have a lateral movement in other network machines. Nowadays, Ransomware like - CHAOS ransomware also use this technique to spread its malicious code in possible - removable drives. This TTP detection can be a good indicator that a process might - create a persistence technique or lateral movement of a targeted machine. We suggest - checking the process name that creates this event, the file created, user type, - and the reason why that executable or scripts are dropped in the root drive. +description: The following analytic detects the creation or dropping of executable + or script files in the root directory of a removable drive. It leverages data from + the Endpoint.Filesystem datamodel, focusing on specific file types and their creation + paths. This activity is significant as it may indicate an attempt to spread malware, + such as ransomware, via removable media. If confirmed malicious, this behavior could + lead to unauthorized code execution, lateral movement, or persistence within the + network, potentially compromising sensitive data and systems. data_source: - Sysmon EventID 11 search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -24,8 +20,8 @@ search: '|tstats `security_content_summariesonly` count min(_time) as firstTime = *.com OR Filesystem.file_name = *.vbs OR Filesystem.file_name = *.vbe OR Filesystem.file_name = *.js OR Filesystem.file_name= *.bat OR Filesystem.file_name = *.cmd OR Filesystem.file_name = *.pif) by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name - Filesystem.file_path Filesystem.user Filesystem.dest | `drop_dm_object_name(Filesystem)` | eval - dropped_file_path = split(file_path, "\\") | eval dropped_file_path_split_count + Filesystem.file_path Filesystem.user Filesystem.dest | `drop_dm_object_name(Filesystem)` + | eval dropped_file_path = split(file_path, "\\") | eval dropped_file_path_split_count = mvcount(dropped_file_path) | eval root_drive = mvindex(dropped_file_path,0) | where LIKE(root_drive, "%:") AND dropped_file_path_split_count = 2 AND root_drive!= "C:" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` @@ -46,8 +42,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 80 - message: executable or script $file_path$ was dropped in root drive $root_drive$ in - $dest$ + message: executable or script $file_path$ was dropped in root drive $root_drive$ + in $dest$ mitre_attack_id: - T1091 observable: @@ -75,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/spread_in_root_drives/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/spread_in_root_drives/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_root_domain_linked_policies_discovery.yml b/detections/endpoint/windows_root_domain_linked_policies_discovery.yml index 26140307d7..c1fd6ba784 100644 --- a/detections/endpoint/windows_root_domain_linked_policies_discovery.yml +++ b/detections/endpoint/windows_root_domain_linked_policies_discovery.yml @@ -1,22 +1,23 @@ name: Windows Root Domain linked policies Discovery id: 80ffaede-1f12-49d5-a86e-b4b599b68b3c -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) - to identify the `[Adsisearcher]` type accelerator being used to query Active Directory - for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate - root domain linked policies for situational awareness and Active Directory Discovery. +description: The following analytic detects the use of the `[Adsisearcher]` type accelerator + in PowerShell to query Active Directory for root domain linked policies. It leverages + PowerShell Script Block Logging (EventCode=4104) to identify this activity. This + behavior is significant as it may indicate an attempt by adversaries or Red Teams + to gain situational awareness and perform Active Directory Discovery. If confirmed + malicious, this activity could allow attackers to map out domain policies, potentially + aiding in further exploitation or lateral movement within the network. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText = "*[adsisearcher]*" ScriptBlockText = "*.SearchRooT*" ScriptBlockText = "*.gplink*" | stats count min(_time) as firstTime - max(_time) as lastTime by EventCode ScriptBlockText Computer user_id - | rename Computer as dest, user_id as user - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + max(_time) as lastTime by EventCode ScriptBlockText Computer user_id | rename Computer + as dest, user_id as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_root_domain_linked_policies_discovery_filter`' how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or @@ -33,7 +34,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: Windows PowerShell [Adsisearcher] was used user enumeration on endpoint $dest$ + message: Windows PowerShell [Adsisearcher] was used user enumeration on endpoint + $dest$ mitre_attack_id: - T1087.002 - T1087 @@ -57,6 +59,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/adsi_discovery/windows-powershell-xml1.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.002/adsi_discovery/windows-powershell-xml1.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_rundll32_apply_user_settings_changes.yml b/detections/endpoint/windows_rundll32_apply_user_settings_changes.yml index 3d601e86fc..08b286b748 100644 --- a/detections/endpoint/windows_rundll32_apply_user_settings_changes.yml +++ b/detections/endpoint/windows_rundll32_apply_user_settings_changes.yml @@ -1,25 +1,26 @@ name: Windows Rundll32 Apply User Settings Changes id: b9fb8d97-dbc9-4a09-804c-ff0e3862bb2d -version: 1 -date: '2023-12-12' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This search is to detect a suspicious rundll32 commandline to update a user's system parameters related to desktop backgrounds, - display settings, and visual themes. Specifically, it triggers the system to refresh and apply changes to the user-specific settings, - such as wallpaper modifications or visual theme updates, ensuring that the changes take effect without the need to restart the system or log out - and log back in. This technique was seen in Rhysida Ransomware and script as part of its defense evasion. This technique is not a common practice - to lock a screen and maybe a good indicator of compromise. - This command could also potentially be exploited by malware to disguise its activities or make unauthorized changes to a user's system settings - without their knowledge or consent. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name=rundll32.exe Processes.process= "*user32.dll,UpdatePerUserSystemParameters*" - by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.parent_process_name - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of a suspicious rundll32 + command line that updates user-specific system parameters, such as desktop backgrounds, + display settings, and visual themes. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on command-line executions involving "user32.dll,UpdatePerUserSystemParameters." + This activity is significant as it is uncommon for legitimate purposes and has been + observed in Rhysida Ransomware for defense evasion. If confirmed malicious, this + could allow an attacker to disguise activities or make unauthorized system changes, + potentially leading to persistent unauthorized access. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name=rundll32.exe + Processes.process= "*user32.dll,UpdatePerUserSystemParameters*" by Processes.dest + Processes.user Processes.parent_process Processes.process_name Processes.process + Processes.process_id Processes.parent_process_id Processes.parent_process_name | + `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_rundll32_apply_user_settings_changes_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -71,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/update_per_user_system/rundll32_updateperusersystem.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.011/update_per_user_system/rundll32_updateperusersystem.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_rundll32_webdav_with_network_connection.yml b/detections/endpoint/windows_rundll32_webdav_with_network_connection.yml index 2fbf258721..71b1d73175 100644 --- a/detections/endpoint/windows_rundll32_webdav_with_network_connection.yml +++ b/detections/endpoint/windows_rundll32_webdav_with_network_connection.yml @@ -1,15 +1,18 @@ name: Windows Rundll32 WebDav With Network Connection id: f03355e0-28b5-4e9b-815a-6adffc63b38c -version: 1 -date: '2024-01-30' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk type: TTP status: experimental data_source: [] -description: The following analytic identifies rundll32.exe with the commandline arguments - loading davclnt.dll function - davsetcookie - to be used to access a remote WebDav - instance. The analytic attempts to use join from Processes and All_Traffic to identify - the network connection. This particular behavior was recently showcased in CVE-2023-23397. +description: The following analytic detects the execution of rundll32.exe with command-line + arguments loading davclnt.dll and the davsetcookie function to access a remote WebDav + instance. It uses data from Endpoint Detection and Response (EDR) agents, correlating + process execution and network traffic data. This activity is significant as it may + indicate exploitation of CVE-2023-23397, a known vulnerability. If confirmed malicious, + this could allow an attacker to establish unauthorized remote connections, potentially + leading to data exfiltration or further network compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.parent_process_name=svchost.exe `process_rundll32` Processes.process IN ("*\\windows\\system32\\davclnt.dll,*davsetcookie*", @@ -93,6 +96,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/cve-2023-23397/webdav_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/cve-2023-23397/webdav_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_scheduled_task_created_via_xml.yml b/detections/endpoint/windows_scheduled_task_created_via_xml.yml index eed62c0abc..fe8cfebc59 100644 --- a/detections/endpoint/windows_scheduled_task_created_via_xml.yml +++ b/detections/endpoint/windows_scheduled_task_created_via_xml.yml @@ -1,30 +1,20 @@ name: Windows Scheduled Task Created Via XML id: 7e03b682-3965-4598-8e91-a60a40a3f7e4 -version: 2 -date: '2023-12-27' +version: 3 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: 'The following analytic detects the creation of suspicious scheduled - tasks in Windows, specifically tasks created using schtasks.exe with the -create - flag and an XML parameter in the command-line. This technique is commonly employed - by threat actors, adversaries, and red teamers to establish persistence or achieve - privilege escalation on targeted hosts. Notably, malware like Trickbot and Winter-Vivern - have been observed using XML files to create scheduled tasks. Monitoring and investigating - this activity is crucial to mitigate potential security risks. It is important to - be aware that scripts or administrators may trigger this analytic, leading to potential - false positives. To minimize false positives, adjust the filter based on the parent - process or application. - - When a true positive is detected, it suggests an attacker''s attempt to gain persistence - or execute additional malicious payloads, potentially resulting in data theft, ransomware, - or other damaging outcomes. During triage, review the source of the scheduled task, - the command to be executed, and capture any relevant on-disk artifacts. Analyze - concurrent processes to identify the source of the attack. This analytic enables - analysts to detect and respond to potential threats early, mitigating the associated - risks effectively.' +description: 'The following analytic detects the creation of scheduled tasks in Windows + using schtasks.exe with the -create flag and an XML parameter. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on command-line + executions and process details. This activity is significant as it is a common technique + for establishing persistence or achieving privilege escalation, often used by malware + like Trickbot and Winter-Vivern. If confirmed malicious, this could allow attackers + to maintain access, execute additional payloads, and potentially lead to data theft + or ransomware deployment.' search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=schtasks.exe Processes.process=*create* Processes.process="* /xml *" by Processes.user Processes.parent_process_name @@ -89,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/scheduledtask/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/scheduledtask/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_scheduled_task_service_spawned_shell.yml b/detections/endpoint/windows_scheduled_task_service_spawned_shell.yml index bc6e8234ef..5890126fb4 100644 --- a/detections/endpoint/windows_scheduled_task_service_spawned_shell.yml +++ b/detections/endpoint/windows_scheduled_task_service_spawned_shell.yml @@ -1,16 +1,18 @@ name: Windows Scheduled Task Service Spawned Shell id: d8120352-3b62-4e3c-8cb6-7b47584dd5e8 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-14' author: Steven Dick status: production type: TTP -description: The following analytic identifies when the Task Scheduler service "svchost.exe - -k netsvcs -p -s Schedule" is the parent process to common command line, scripting, - or shell execution binaries. Attackers often abuse the task scheduler service with - these binaries as an execution and persistence mechanism in order to blend in with - normal Windows operations. This TTP is also commonly seen for legitimate purposes - such as business scripts or application updates. +description: The following analytic detects when the Task Scheduler service ("svchost.exe + -k netsvcs -p -s Schedule") spawns common command line, scripting, or shell execution + binaries such as "powershell.exe" or "cmd.exe". This detection leverages data from + Endpoint Detection and Response (EDR) agents, focusing on process and parent process + relationships. This activity is significant as attackers often abuse the Task Scheduler + for execution and persistence, blending in with legitimate Windows operations. If + confirmed malicious, this could allow attackers to execute arbitrary code, maintain + persistence, or escalate privileges within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/gootloader/partial_ttps/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_scheduled_task_with_highest_privileges.yml b/detections/endpoint/windows_scheduled_task_with_highest_privileges.yml index ca477a2fdf..4b0730ba79 100644 --- a/detections/endpoint/windows_scheduled_task_with_highest_privileges.yml +++ b/detections/endpoint/windows_scheduled_task_with_highest_privileges.yml @@ -1,22 +1,18 @@ name: Windows Scheduled Task with Highest Privileges id: 2f15e1a4-0fc2-49dd-919e-cbbe60699218 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: TTP -description: 'The following analytic detects the creation of a new task with the highest - execution privilege via Schtasks.exe. This tactic is often observed in AsyncRAT - attacks, where the scheduled task is used for persistence and privilege escalation. - AsyncRAT sets up a scheduled task with parameters ''/rl'' and ''highest'', triggering - this technique. It''s a strong indicator of potential malware or adversaries seeking - to establish persistence and escalate privileges through scheduled tasks. This is - crucial for a Security Operations Center (SOC) as it can prevent unauthorized system - access and potential data breaches. - - The analytic works by monitoring logs for process name, parent process, and command-line - executions. In the presence of the ''*/rl '' and '' highest *'' commands in a schtasks.exe - process, an alert is triggered.' +description: 'The following analytic detects the creation of a new scheduled task + with the highest execution privileges via Schtasks.exe. It leverages Endpoint Detection + and Response (EDR) logs to monitor for specific command-line parameters (''/rl'' + and ''highest'') in schtasks.exe executions. This activity is significant as it + is commonly used in AsyncRAT attacks for persistence and privilege escalation. If + confirmed malicious, this could allow an attacker to maintain persistent access + and execute tasks with elevated privileges, potentially leading to unauthorized + system access and data breaches.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/asyncrat_highest_priv_schtasks/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/asyncrat_highest_priv_schtasks/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_schtasks_create_run_as_system.yml b/detections/endpoint/windows_schtasks_create_run_as_system.yml index da147aa140..b92dfcc83b 100644 --- a/detections/endpoint/windows_schtasks_create_run_as_system.yml +++ b/detections/endpoint/windows_schtasks_create_run_as_system.yml @@ -1,19 +1,18 @@ name: Windows Schtasks Create Run As System id: 41a0e58e-884c-11ec-9976-acde48001122 -version: 1 -date: '2022-02-07' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the creation of a new task to start - and run as an elevated user - SYSTEM using Schtasks.exe. This behavior is commonly - used by adversaries to spawn a process in an elevated state. If a true positive - is found, it suggests an attacker is attempting to persist within the environment - or potentially deliver additional malicious payloads, leading to data theft, ransomware, - or other damaging outcomes. Upon triage, review the scheduled task's source and - the command to be executed. Capture and inspect any relevant on-disk artifacts, - and look for concurrent processes to identify the attack source. This approach helps - analysts detect potential threats earlier and mitigate the risks. +description: The following analytic detects the creation of a new scheduled task using + Schtasks.exe to run as the SYSTEM user. This detection leverages data from Endpoint + Detection and Response (EDR) agents, focusing on command-line executions and process + details. This activity is significant as it often indicates an attempt to gain elevated + privileges or maintain persistence within the environment. If confirmed malicious, + an attacker could execute code with SYSTEM-level privileges, potentially leading + to data theft, ransomware deployment, or further system compromise. Immediate investigation + and mitigation are crucial to prevent further damage. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtask_system/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/schtask_system/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_screen_capture_via_powershell.yml b/detections/endpoint/windows_screen_capture_via_powershell.yml index 7116db78e6..3a7e848183 100644 --- a/detections/endpoint/windows_screen_capture_via_powershell.yml +++ b/detections/endpoint/windows_screen_capture_via_powershell.yml @@ -1,18 +1,23 @@ name: Windows Screen Capture Via Powershell id: 5e0b1936-8f99-4399-8ee2-9edc5b32e170 -version: 1 -date: '2023-04-05' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Powershell Script Block Logging 4104 -description: The following analytic identifies a potential PowerShell script that captures screen images on compromised or targeted hosts. This technique was observed in the Winter-Vivern malware, which attempts to capture desktop screens using a PowerShell script and send the images to its C2 server as part of its exfiltration strategy. This TTP serves as a useful indicator that a PowerShell process may be gathering desktop screenshots from a host system, potentially signaling malicious activity. -search: '`powershell` EventCode=4104 ScriptBlockText = "*[Drawing.Graphics]::FromImage(*" AND ScriptBlockText = "*New-Object Drawing.Bitmap*" - AND ScriptBlockText = "*.CopyFromScreen*" - | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of a PowerShell script designed + to capture screen images on a host. It leverages PowerShell Script Block Logging + to identify specific script block text patterns associated with screen capture activities. + This behavior is significant as it may indicate an attempt to exfiltrate sensitive + information by capturing desktop screenshots. If confirmed malicious, this activity + could allow an attacker to gather visual data from the compromised system, potentially + leading to data breaches or further exploitation. +search: '`powershell` EventCode=4104 ScriptBlockText = "*[Drawing.Graphics]::FromImage(*" + AND ScriptBlockText = "*New-Object Drawing.Bitmap*" AND ScriptBlockText = "*.CopyFromScreen*" + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText + Computer UserID | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_screen_capture_via_powershell_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here @@ -32,7 +37,8 @@ tags: dataset: - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_exfiltration/windows-powershell-xml.log impact: 70 - message: A PowerShell script was identified possibly performing screen captures on $Computer$. + message: A PowerShell script was identified possibly performing screen captures + on $Computer$. mitre_attack_id: - T1113 observable: @@ -55,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_exfiltration/windows-powershell-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winter-vivern/pwh_exfiltration/windows-powershell-xml.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/endpoint/windows_security_support_provider_reg_query.yml b/detections/endpoint/windows_security_support_provider_reg_query.yml index d06b1106af..5f71816289 100644 --- a/detections/endpoint/windows_security_support_provider_reg_query.yml +++ b/detections/endpoint/windows_security_support_provider_reg_query.yml @@ -1,19 +1,19 @@ name: Windows Security Support Provider Reg Query id: 31302468-93c9-4eca-9ae3-2d41f53a4e2b -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line related to the - discovery of possible Security Support Providers in the registry. This technique - is being abused by adversaries or post exploitation tools like winpeas to gather - LSA protection and configuration in the registry in the targeted host. This registry - entry can contain several information related to LSA that validates users for local - and remote sign-ins and enforces local security policies. Understanding LSA protection - may give a good information in accessing LSA content in memory which is commonly - attack by adversaries and tool like mimikatz to scrape password hashes or clear - plain text passwords. +description: The following analytic identifies command-line activity querying the + registry for Security Support Providers (SSPs) related to Local Security Authority + (LSA) protection and configuration. This detection leverages Endpoint Detection + and Response (EDR) telemetry, focusing on processes accessing specific LSA registry + paths. Monitoring this activity is crucial as adversaries and post-exploitation + tools like winpeas may use it to gather information on LSA protections, potentially + leading to credential theft. If confirmed malicious, attackers could exploit this + to scrape password hashes or plaintext passwords from memory, significantly compromising + system security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,7 +79,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_server_software_component_gacutil_install_to_gac.yml b/detections/endpoint/windows_server_software_component_gacutil_install_to_gac.yml index 9641ebcd98..1cad2e24b4 100644 --- a/detections/endpoint/windows_server_software_component_gacutil_install_to_gac.yml +++ b/detections/endpoint/windows_server_software_component_gacutil_install_to_gac.yml @@ -1,20 +1,17 @@ name: Windows Server Software Component GACUtil Install to GAC id: 7c025ef0-9e65-4c57-be39-1c13dbb1613e -version: 1 -date: '2023-01-17' +version: 2 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the Windows SDK utility - GACUtil.exe, - being utilized to add a DLL into the Global Assembly Cache (GAC). Each computer - where the Common Language Runtime is installed has a machine-wide code cache called - the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically - designated to be shared by several applications on the computer. By adding a DLL - to the GAC, this allows an adversary to call it via any other means across the operating - systems. As outlined by Microsoft in their blog, it is not common to see this spawning - from W3WP.exe, however, in a non-development environment it may not be common at - all. Note that in order to utilize GACutil.exe, The Windows SDK must be installed, - this is not a native binary. +description: The following analytic detects the use of GACUtil.exe to add a DLL into + the Global Assembly Cache (GAC). It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line executions. This activity + is significant because adding a DLL to the GAC allows it to be called by any application, + potentially enabling widespread code execution. If confirmed malicious, this could + allow an attacker to execute arbitrary code across the operating system, leading + to privilege escalation or persistent access. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -90,7 +87,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/gacutil_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1505.004/gacutil_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_service_create_sliverc2.yml b/detections/endpoint/windows_service_create_sliverc2.yml index d415038410..f328e79128 100644 --- a/detections/endpoint/windows_service_create_sliverc2.yml +++ b/detections/endpoint/windows_service_create_sliverc2.yml @@ -1,24 +1,31 @@ name: Windows Service Create SliverC2 id: 89dad3ee-57ec-43dc-9044-131c4edd663f -version: 1 -date: '2023-03-03' +version: 2 +date: '2024-05-25' author: Michael Haag, Splunk type: TTP status: production data_source: - Windows Event Log System 7045 -description: When an adversary utilizes SliverC2 to laterally move with the Psexec module, it will create a service with the name and description of "Sliver" and "Sliver Implant". Note that these may be easily changed and are specific to only SliverC2. - We have also created the same regex as Microsoft has outlined to attempt to capture the suspicious service path (regex101 reference). -search: '`wineventlog_system` EventCode=7045 ServiceName="sliver" - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ImagePath ServiceName ServiceType | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `windows_service_create_sliverc2_filter`' -how_to_implement: To implement this analytic, the Windows EventCode 7045 will need to be logged from the System Event log. The Windows TA for Splunk is also recommended. -known_false_positives: False positives should be limited, but if another service out there is named Sliver, filtering may be needed. +description: The following analytic detects the creation of a Windows service named + "Sliver" with the description "Sliver Implant," indicative of SliverC2 lateral movement + using the PsExec module. It leverages Windows EventCode 7045 from the System Event + log to identify this activity. This behavior is significant as it may indicate an + adversary's attempt to establish persistence or execute commands remotely. If confirmed + malicious, this activity could allow attackers to maintain control over the compromised + system, execute arbitrary code, and further infiltrate the network. +search: '`wineventlog_system` EventCode=7045 ServiceName="sliver" | stats count min(_time) + as firstTime max(_time) as lastTime by Computer EventCode ImagePath ServiceName + ServiceType | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `windows_service_create_sliverc2_filter`' +how_to_implement: To implement this analytic, the Windows EventCode 7045 will need + to be logged from the System Event log. The Windows TA for Splunk is also recommended. +known_false_positives: False positives should be limited, but if another service out + there is named Sliver, filtering may be needed. references: - - https://github.com/BishopFox/sliver/blob/71f94928bf36c1557ea5fbeffa161b71116f56b2/client/command/exec/psexec.go#LL61C5-L61C16 - - https://www.microsoft.com/en-us/security/blog/2022/08/24/looking-for-the-sliver-lining-hunting-for-emerging-command-and-control-frameworks/ - - https://regex101.com/r/DWkkXm/1 +- https://github.com/BishopFox/sliver/blob/71f94928bf36c1557ea5fbeffa161b71116f56b2/client/command/exec/psexec.go#LL61C5-L61C16 +- https://www.microsoft.com/en-us/security/blog/2022/08/24/looking-for-the-sliver-lining-hunting-for-emerging-command-and-control-frameworks/ +- https://regex101.com/r/DWkkXm/1 tags: analytic_story: - BishopFox Sliver Adversary Emulation Framework @@ -49,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/sliver_windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/sliver/sliver_windows-system.log source: XmlWinEventLog:System - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_service_create_with_tscon.yml b/detections/endpoint/windows_service_create_with_tscon.yml index 0caef89aa7..2c3e6c81a1 100644 --- a/detections/endpoint/windows_service_create_with_tscon.yml +++ b/detections/endpoint/windows_service_create_with_tscon.yml @@ -1,21 +1,20 @@ name: Windows Service Create with Tscon id: c13b3d74-6b63-4db5-a841-4206f0370077 -version: 1 -date: '2023-03-29' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk type: TTP status: production data_source: - Sysmon EventID 1 -description: The following analytic detects potential RDP Hijacking attempts by monitoring - a series of actions taken by an attacker to gain unauthorized access to a remote - system. The attacker first runs the quser command to query the remote host for disconnected - user sessions. Upon identifying a disconnected session, they use the sc.exe command - to create a new Windows service with a binary path that launches tscon.exe. By specifying - the disconnected session ID and a destination ID, the attacker can transfer the - disconnected session to a new RDP session, effectively hijacking the user's session. - This analytic allows security teams to detect and respond to RDP Hijacking attempts, - mitigating potential risks and impacts on targeted systems. +description: The following analytic detects potential RDP Hijacking attempts by identifying + the creation of a Windows service using sc.exe with a binary path that includes + tscon.exe. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on process creation events and command-line arguments. This activity + is significant as it indicates an attacker may be trying to hijack a disconnected + RDP session, posing a risk of unauthorized access. If confirmed malicious, the attacker + could gain control over an existing user session, leading to potential data theft + or further system compromise. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=sc.exe Processes.process="*/dest:rdp-tcp*" by Processes.dest Processes.user Processes.parent_process_name @@ -96,6 +95,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1563.002/rdphijack/tscon_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1563.002/rdphijack/tscon_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_service_created_with_suspicious_service_path.yml b/detections/endpoint/windows_service_created_with_suspicious_service_path.yml index abc1cb847c..b3f638846a 100644 --- a/detections/endpoint/windows_service_created_with_suspicious_service_path.yml +++ b/detections/endpoint/windows_service_created_with_suspicious_service_path.yml @@ -1,20 +1,22 @@ name: Windows Service Created with Suspicious Service Path id: 429141be-8311-11eb-adb6-acde48001122 -version: 4 -date: '2024-04-26' +version: 5 +date: '2024-05-21' author: Teoderick Contreras, Mauricio Velazco, Splunk status: production type: TTP -description: The following analytics uses Windows Event Id 7045, `New Service Was - Installed`, to identify the creation of a Windows Service where the service binary - path path is located in a non-common Service folder in Windows. Red Teams and adversaries - alike may create malicious Services for lateral movement or remote code execution - as well as persistence and execution. The Clop ransomware has also been seen in - the wild abusing Windows services. +description: The following analytic detects the creation of a Windows Service with + a binary path located in uncommon directories, using Windows Event ID 7045. It leverages + logs from the `wineventlog_system` to identify services installed outside typical + system directories. This activity is significant as adversaries, including those + deploying Clop ransomware, often create malicious services for lateral movement, + remote code execution, persistence, and execution. If confirmed malicious, this + could allow attackers to maintain persistence, execute arbitrary code, and potentially + escalate privileges, posing a severe threat to the environment. data_source: - Windows Event Log System 7045 -search: ' `wineventlog_system` EventCode=7045 ImagePath = "*.exe" NOT (ImagePath - IN ("*:\\Windows\\*", "*:\\Program File*", "*:\\Programdata\\*", "*%systemroot%\\*")) +search: ' `wineventlog_system` EventCode=7045 ImagePath = "*.exe" NOT (ImagePath IN + ("*:\\Windows\\*", "*:\\Program File*", "*:\\Programdata\\*", "*%systemroot%\\*")) | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ImagePath ServiceName ServiceType StartType Computer UserID | rename Computer as dest| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_service_created_with_suspicious_service_path_filter`' @@ -39,7 +41,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 70 - message: A service $ImagePath$ was created from a non-standard path using $ServiceName$ on $dest$ + message: A service $ImagePath$ was created from a non-standard path using $ServiceName$ + on $dest$ mitre_attack_id: - T1569 - T1569.002 @@ -69,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/windows_service_created_with_suspicious_service_path/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/windows_service_created_with_suspicious_service_path/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_service_created_within_public_path.yml b/detections/endpoint/windows_service_created_within_public_path.yml index ea0aaff2e6..6992ebaa34 100644 --- a/detections/endpoint/windows_service_created_within_public_path.yml +++ b/detections/endpoint/windows_service_created_within_public_path.yml @@ -1,19 +1,22 @@ name: Windows Service Created Within Public Path id: 3abb2eda-4bb8-11ec-9ae4-3e22fbd008af -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-15' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytc uses Windows Event Id 7045, `New Service Was Installed`, - to identify the creation of a Windows Service where the service binary path is located - in public paths. This behavior could represent the installation of a malicious service. - Red Teams and adversaries alike may create malicious Services for lateral movement - or remote code execution +description: The following analytic detects the creation of a Windows Service with + its binary path located in public directories using Windows Event ID 7045. This + detection leverages logs from the `wineventlog_system` data source, focusing on + the `ImagePath` field to identify services installed outside standard system directories. + This activity is significant as it may indicate the installation of a malicious + service, often used by adversaries for lateral movement or remote code execution. + If confirmed malicious, this could allow attackers to execute arbitrary code, maintain + persistence, or further compromise the system. data_source: - Windows Event Log System 7045 -search: '`wineventlog_system` EventCode=7045 ImagePath = "*.exe" NOT (ImagePath - IN ("*:\\Windows\\*", "*:\\Program File*", "*:\\Programdata\\*", "*%systemroot%\\*")) +search: '`wineventlog_system` EventCode=7045 ImagePath = "*.exe" NOT (ImagePath IN + ("*:\\Windows\\*", "*:\\Program File*", "*:\\Programdata\\*", "*%systemroot%\\*")) | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ImagePath ServiceName ServiceType StartType Computer UserID | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_service_created_within_public_path_filter`' @@ -32,8 +35,7 @@ tags: asset_type: Endpoint confidence: 60 impact: 90 - message: A Windows Service $ServiceName$ with a public path was created on - $dest$ + message: A Windows Service $ServiceName$ with a public path was created on $dest$ mitre_attack_id: - T1543 - T1543.003 @@ -62,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/windows_service_created_with_suspicious_service_path/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1569.002/windows_service_created_with_suspicious_service_path/windows-xml.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_service_creation_on_remote_endpoint.yml b/detections/endpoint/windows_service_creation_on_remote_endpoint.yml index be63ca9c64..a2742671f3 100644 --- a/detections/endpoint/windows_service_creation_on_remote_endpoint.yml +++ b/detections/endpoint/windows_service_creation_on_remote_endpoint.yml @@ -1,14 +1,18 @@ name: Windows Service Creation on Remote Endpoint id: e0eea4fa-4274-11ec-882b-3e22fbd008af -version: 1 -date: '2021-11-10' +version: 2 +date: '2024-05-21' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `sc.exe` with command-line arguments - utilized to create a Windows Service on a remote endpoint. Red Teams and adversaries - alike may abuse the Service Control Manager for lateral movement and remote code - execution. +description: The following analytic identifies the creation of a Windows Service on + a remote endpoint using `sc.exe`. It detects this activity by analyzing process + execution logs from Endpoint Detection and Response (EDR) agents, focusing on command-line + arguments that include remote paths and service creation commands. This behavior + is significant because adversaries often exploit the Service Control Manager for + lateral movement and remote code execution. If confirmed malicious, this activity + could allow attackers to execute arbitrary code on remote systems, potentially leading + to further compromise and persistence within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -71,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_service_creation_using_registry_entry.yml b/detections/endpoint/windows_service_creation_using_registry_entry.yml index f814c81be8..642788bb65 100644 --- a/detections/endpoint/windows_service_creation_using_registry_entry.yml +++ b/detections/endpoint/windows_service_creation_using_registry_entry.yml @@ -1,23 +1,17 @@ name: Windows Service Creation Using Registry Entry id: 25212358-948e-11ec-ad47-acde48001122 -version: 3 -date: '2023-04-27' +version: 4 +date: '2024-05-30' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic detects when reg.exe modify registry keys that - define Windows services and their configurations in Windows to detect potential - threats earlier and mitigate the risks. This detection is made by a Splunk query - that searches for specific keywords in the process name, parent process name, user, - and process ID. This detection is important because it suggests that an attacker - has modified the registry keys that define Windows services and their configurations, - which can allow them to maintain access to the system and potentially move laterally - within the network. It is a common technique used by attackers to gain persistence - on a compromised system and its impact can lead to data theft, ransomware, or other - damaging outcomes. False positives can occur since legitimate uses of reg.exe to - modify registry keys for Windows services can also trigger this alert. Next steps - include reviewing the process and user context of the reg.exe activity and identify - any other concurrent processes that might be associated with the attack upon triage. +description: The following analytic detects the modification of registry keys that + define Windows services using reg.exe. This detection leverages Splunk to search + for specific keywords in the registry path, value name, and value data fields. This + activity is significant because it indicates potential unauthorized changes to service + configurations, a common persistence technique used by attackers. If confirmed malicious, + this could allow an attacker to maintain access, escalate privileges, or move laterally + within the network, leading to data theft, ransomware, or other damaging outcomes. data_source: - Sysmon EventID 12 - Sysmon EventID 13 @@ -73,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.011/change_registry_path_service/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.011/change_registry_path_service/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_service_initiation_on_remote_endpoint.yml b/detections/endpoint/windows_service_initiation_on_remote_endpoint.yml index efa85b2b60..2aa32d5e0e 100644 --- a/detections/endpoint/windows_service_initiation_on_remote_endpoint.yml +++ b/detections/endpoint/windows_service_initiation_on_remote_endpoint.yml @@ -1,14 +1,17 @@ name: Windows Service Initiation on Remote Endpoint id: 3f519894-4276-11ec-ab02-3e22fbd008af -version: 1 -date: '2021-11-10' +version: 2 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: TTP -description: This analytic looks for the execution of `sc.exe` with command-line arguments - utilized to start a Windows Service on a remote endpoint. Red Teams and adversaries - alike may abuse the Service Control Manager for lateral movement and remote code - execution. +description: The following analytic detects the execution of `sc.exe` with command-line + arguments used to start a Windows Service on a remote endpoint. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + command-line executions. This activity is significant because adversaries may exploit + the Service Control Manager for lateral movement and remote code execution. If confirmed + malicious, this could allow attackers to execute arbitrary code on remote systems, + potentially leading to further compromise and persistence within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/lateral_movement/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_service_stop_by_deletion.yml b/detections/endpoint/windows_service_stop_by_deletion.yml index cfb19f012b..e2d4305a69 100644 --- a/detections/endpoint/windows_service_stop_by_deletion.yml +++ b/detections/endpoint/windows_service_stop_by_deletion.yml @@ -1,15 +1,18 @@ name: Windows Service Stop By Deletion id: 196ff536-58d9-4d1b-9686-b176b04e430b -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies Windows Service Control, `sc.exe`, - attempting to delete a service. This is typically identified in parallel with other - instances of service enumeration of attempts to stop a service and then delete it. - Adversaries utilize this technique to terminate security services or other related - services to continue there objective and evade detections. +description: The following analytic detects the use of `sc.exe` to delete a Windows + service. It leverages Endpoint Detection and Response (EDR) data, focusing on process + execution logs that capture command-line arguments. This activity is significant + because adversaries often delete services to disable security mechanisms or critical + system functions, aiding in evasion and persistence. If confirmed malicious, this + action could lead to the termination of essential security services, allowing attackers + to operate undetected and potentially escalate their privileges or maintain long-term + access to the compromised system. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -69,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_service_stop_via_net__and_sc_application.yml b/detections/endpoint/windows_service_stop_via_net__and_sc_application.yml index 9fe2b2484f..3043128ae5 100644 --- a/detections/endpoint/windows_service_stop_via_net__and_sc_application.yml +++ b/detections/endpoint/windows_service_stop_via_net__and_sc_application.yml @@ -1,15 +1,17 @@ name: Windows Service Stop Via Net and SC Application id: 827af04b-0d08-479b-9b84-b7d4644e4b80 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic identifies suspicious attempts to stop services on a system - using either `net.exe` or `sc.exe`. This technique is used by adversaries to terminate - security services or other related services to continue their objective and evade - detections. This technique is also commonly used by ransomware threat actors to - successfully encrypt databases or files being processed or used by Windows OS Services. +description: The following analytic identifies attempts to stop services on a system + using `net.exe` or `sc.exe`. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names, GUIDs, and command-line executions. This + activity is significant as adversaries often terminate security or critical services + to evade detection and further their objectives. If confirmed malicious, this behavior + could allow attackers to disable security defenses, facilitate ransomware encryption, + or disrupt essential services, leading to potential data loss or system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,7 +71,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/prestige_ransomware/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/prestige_ransomware/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_service_stop_win_updates.yml b/detections/endpoint/windows_service_stop_win_updates.yml index 59025b7c1d..e8ec84f55b 100644 --- a/detections/endpoint/windows_service_stop_win_updates.yml +++ b/detections/endpoint/windows_service_stop_win_updates.yml @@ -1,18 +1,20 @@ name: Windows Service Stop Win Updates id: 0dc25c24-6fcf-456f-b08b-dd55a183e4de -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log System 7040 -description: The following analytic identifies a windows update service being disabled - in Windows OS. This technique is being abused by adversaries or threat actors to - add defense mechanisms to their malware implant in the targeted host. Disabling - windows update will put the compromised host vulnerable in some zero day exploit - or even some update features against threats. RedLine Stealer kills this service - as part of its defense evasion mechanism. +description: The following analytic detects the disabling of Windows Update services, + such as "Update Orchestrator Service for Windows Update," "WaaSMedicSvc," and "Windows + Update." It leverages Windows System Event ID 7040 logs to identify changes in service + start modes to 'disabled.' This activity is significant as it can indicate an adversary's + attempt to evade defenses by preventing critical updates, leaving the system vulnerable + to exploits. If confirmed malicious, this could allow attackers to maintain persistence + and exploit unpatched vulnerabilities, compromising the integrity and security of + the affected host. search: '`wineventlog_system` EventCode=7040 (service_name IN ("Update Orchestrator Service for Windows Update", "WaaSMedicSvc", "Windows Update") OR param1 IN ("UsoSvc", "WaaSMedicSvc", "wuauserv")) AND (param3=disabled OR start_mode = disabled) | stats @@ -61,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/win_update_services_stop/system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/redline/win_update_services_stop/system.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_sip_provider_inventory.yml b/detections/endpoint/windows_sip_provider_inventory.yml index 978ea8e15a..95fd394161 100644 --- a/detections/endpoint/windows_sip_provider_inventory.yml +++ b/detections/endpoint/windows_sip_provider_inventory.yml @@ -1,15 +1,26 @@ name: Windows SIP Provider Inventory id: 21c5af91-1a4a-4511-8603-64fb41df3fad -version: 1 -date: '2023-10-10' +version: 2 +date: '2024-05-09' author: Michael Haag, Splunk status: production type: Hunting data_source: [] -description: The following inventory analytic is used with a PowerShell scripted inputs to capture all SIP providers on a Windows system. This analytic is used to identify potential malicious SIP providers that may be used to subvert trust controls. Upon review, look for new and non-standard paths for SIP providers. -search: '`subjectinterfacepackage` Dll=*\\*.dll | stats count min(_time) as firstTime max(_time) as lastTime values(Dll) by Path host| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `windows_sip_provider_inventory_filter`' -how_to_implement: To implement this analytic, one must first perform inventory using a scripted inputs. Review the following Gist - https://gist.github.com/MHaggis/75dd5db546c143ea67703d0e86cdbbd1 -known_false_positives: False positives are limited as this is a hunting query for inventory. +description: The following analytic identifies all SIP (Subject Interface Package) + providers on a Windows system using PowerShell scripted inputs. It detects SIP providers + by capturing DLL paths from relevant events. This activity is significant because + malicious SIP providers can be used to bypass trust controls, potentially allowing + unauthorized code execution. If confirmed malicious, this activity could enable + attackers to subvert system integrity, leading to unauthorized access or persistent + threats within the environment. Analysts should review for new and non-standard + paths to identify potential threats. +search: '`subjectinterfacepackage` Dll=*\\*.dll | stats count min(_time) as firstTime + max(_time) as lastTime values(Dll) by Path host| `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)`| `windows_sip_provider_inventory_filter`' +how_to_implement: To implement this analytic, one must first perform inventory using + a scripted inputs. Review the following Gist - https://gist.github.com/MHaggis/75dd5db546c143ea67703d0e86cdbbd1 +known_false_positives: False positives are limited as this is a hunting query for + inventory. references: - https://gist.github.com/MHaggis/75dd5db546c143ea67703d0e86cdbbd1 tags: @@ -19,7 +30,8 @@ tags: atomic_guid: [] confidence: 50 impact: 50 - message: A list of SIP providers on the system is available. Review for new and non-standard paths for SIP providers on $host$. + message: A list of SIP providers on the system is available. Review for new and + non-standard paths for SIP providers on $host$. mitre_attack_id: - T1553.003 observable: @@ -40,6 +52,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/sip_inventory.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/sip_inventory.log source: powershell://SubjectInterfacePackage sourcetype: PwSh:SubjectInterfacePackage diff --git a/detections/endpoint/windows_sip_winverifytrust_failed_trust_validation.yml b/detections/endpoint/windows_sip_winverifytrust_failed_trust_validation.yml index 12eb793380..274d7a84c2 100644 --- a/detections/endpoint/windows_sip_winverifytrust_failed_trust_validation.yml +++ b/detections/endpoint/windows_sip_winverifytrust_failed_trust_validation.yml @@ -1,25 +1,35 @@ name: Windows SIP WinVerifyTrust Failed Trust Validation id: 6ffc7f88-415b-4278-a80d-b957d6539e1a -version: 1 -date: '2023-10-10' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: Anomaly data_source: - Windows Event Log CAPI2 81 -description: The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI 2, to identify failed trust validation. Typically, this event log is meant for diagnosing PKI issues, however is a great source to identify failed trust validation. Note that this event log is noisy as it captures common PKI requests from many different processes. EventID 81 is generated anytime a trust validation fails. The description for EventID 81 is "The digital signature of the object did not verify." STRT tested this analytic using Mimikatz binary. -search: '`capi2_operational` EventID=81 "The digital signature of the object did not verify." | xmlkv UserData_Xml | stats count min(_time) as firstTime max(_time) as lastTime by Computer, UserData_Xml | rename Computer as dest | `windows_sip_winverifytrust_failed_trust_validation_filter`' +description: The following analytic detects failed trust validation attempts using + Windows Event Log - CAPI2 (CryptoAPI 2). It specifically triggers on EventID 81, + which indicates that "The digital signature of the object did not verify." This + detection leverages the CAPI2 Operational log to identify instances where digital + signatures fail to validate. Monitoring this activity is crucial as it can indicate + attempts to execute untrusted or potentially malicious binaries. If confirmed malicious, + this activity could allow attackers to bypass security controls and execute unauthorized + code, leading to potential system compromise. +search: '`capi2_operational` EventID=81 "The digital signature of the object did not + verify." | xmlkv UserData_Xml | stats count min(_time) as firstTime max(_time) as + lastTime by Computer, UserData_Xml | rename Computer as dest | `windows_sip_winverifytrust_failed_trust_validation_filter`' how_to_implement: To implement this analytic, one will need to enable the Microsoft-Windows-CAPI2/Operational log within the Windows Event Log. Note this is a debug log for many purposes, and the analytic only focuses in on EventID 81. Review the following gist for additional enabling information. -known_false_positives: False positives may be present in some instances of legitimate binaries with invalid signatures. Filter as needed. +known_false_positives: False positives may be present in some instances of legitimate + binaries with invalid signatures. Filter as needed. references: - - https://attack.mitre.org/techniques/T1553/003/ - - https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf - - https://github.com/gtworek/PSBits/tree/master/SIP - - https://github.com/mattifestation/PoCSubjectInterfacePackage - - https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/ +- https://attack.mitre.org/techniques/T1553/003/ +- https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf +- https://github.com/gtworek/PSBits/tree/master/SIP +- https://github.com/mattifestation/PoCSubjectInterfacePackage +- https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/ tags: analytic_story: - Subvert Trust Controls SIP and Trust Provider Hijacking @@ -48,6 +58,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/capi2-operational.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.003/sip/capi2-operational.log source: XmlWinEventLog:Microsoft-Windows-CAPI2/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_snake_malware_kernel_driver_comadmin.yml b/detections/endpoint/windows_snake_malware_kernel_driver_comadmin.yml index 954b187ee7..346e20826c 100644 --- a/detections/endpoint/windows_snake_malware_kernel_driver_comadmin.yml +++ b/detections/endpoint/windows_snake_malware_kernel_driver_comadmin.yml @@ -1,19 +1,30 @@ name: Windows Snake Malware Kernel Driver Comadmin id: 628d9c7c-3242-43b5-9620-7234c080a726 -version: 1 -date: '2023-05-11' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 11 -description: 'The following analytic identifies the comadmin.dat file written to disk, which is related to Snake Malware. From the report, Snakes installer drops the kernel driver and a custom DLL which is used to load the driver into a - single AES encrypted file on disk. Typically, this file is named comadmin.dat and is stored in the %windows%\system32\Com directory.' +description: 'The following analytic detects the creation of the comadmin.dat file + in the %windows%\system32\Com directory, which is associated with Snake Malware. + This detection leverages the Endpoint.Filesystem data model to identify file creation + events matching the specified path and filename. This activity is significant because + the comadmin.dat file is part of Snake Malware''s installation process, which includes + dropping a kernel driver and a custom DLL. If confirmed malicious, this activity + could allow an attacker to load a malicious driver, potentially leading to privilege + escalation and persistent access to the compromised system.' search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) - as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_path="*\\windows\\system32\\com\\*" AND Filesystem.file_name="comadmin.dat" by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name + as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_path="*\\windows\\system32\\com\\*" + AND Filesystem.file_name="comadmin.dat" by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name Filesystem.file_path Filesystem.dest | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_snake_malware_kernel_driver_comadmin_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. known_false_positives: False positives may be present, filter as needed. references: - https://media.defense.gov/2023/May/09/2003218554/-1/-1/0/JOINT_CSA_HUNTING_RU_INTEL_SNAKE_MALWARE_20230509.PDF @@ -25,7 +36,8 @@ tags: - e5cb5564-cc7b-4050-86e8-f2d9eec1941f confidence: 80 impact: 70 - message: A kernel driver comadmin.dat related to Snake Malware was written to disk on $dest$. + message: A kernel driver comadmin.dat related to Snake Malware was written to disk + on $dest$. mitre_attack_id: - T1547.006 observable: @@ -40,15 +52,16 @@ tags: risk_score: 56 required_fields: - _time - - Filesystem.file_create_time - - Filesystem.process_id + - Filesystem.file_create_time + - Filesystem.process_id - Filesystem.file_name - - Filesystem.file_path + - Filesystem.file_path - Filesystem.dest security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/comadmin_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/comadmin_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_snake_malware_registry_modification_wav_openwithprogids.yml b/detections/endpoint/windows_snake_malware_registry_modification_wav_openwithprogids.yml index f267585fee..02ac75ad3a 100644 --- a/detections/endpoint/windows_snake_malware_registry_modification_wav_openwithprogids.yml +++ b/detections/endpoint/windows_snake_malware_registry_modification_wav_openwithprogids.yml @@ -1,22 +1,34 @@ name: Windows Snake Malware Registry Modification wav OpenWithProgIds id: 13cf8b79-805d-443c-bf52-f55bd7610dfd -version: 1 -date: '2023-05-10' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 12 - Sysmon EventID 13 -description: The follow analytic identifies the registry being modified at .wav\\OpenWithProgIds\, which is related to the Snake Malware campaign. Upon execution, Snake's WerFault.exe will attempt to decrypt an encrypted blob within the Windows - registry that is typically found at HKLM:\SOFTWARE\Classes\.wav\OpenWithProgIds. The encrypted data includes the AES key, IV, and path that is used to find and decrypt the file containing Snake's kernel driver and kernel driver loader. +description: The following analytic identifies modifications to the registry path + .wav\\OpenWithProgIds, associated with the Snake Malware campaign. It leverages + data from the Endpoint.Registry datamodel to detect changes in this specific registry + location. This activity is significant because Snake's WerFault.exe uses this registry + path to decrypt an encrypted blob containing critical components like the AES key, + IV, and paths for its kernel driver and loader. If confirmed malicious, this could + allow the attacker to load and execute Snake's kernel driver, leading to potential + system compromise and persistent access. search: '| tstats `security_content_summariesonly` count values(Registry.registry_key_name) as registry_key_name values(Registry.registry_path) as registry_path min(_time) - as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\.wav\\OpenWithProgIds\\*" by Registry.dest Registry.user - Registry.registry_path Registry.registry_key_name Registry.registry_value_name | - `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` | `windows_snake_malware_registry_modification_wav_openwithprogids_filter`' -how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. -known_false_positives: False positives may be present and will require tuning based on program Ids in large organizations. + as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path="*\\.wav\\OpenWithProgIds\\*" by + Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name + | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` + | `windows_snake_malware_registry_modification_wav_openwithprogids_filter`' +how_to_implement: To successfully implement this search you need to be ingesting information + on process that include the name of the process responsible for the changes from + your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, + confirm the latest CIM App 4.20 or higher is installed and the latest TA for the + endpoint product. +known_false_positives: False positives may be present and will require tuning based + on program Ids in large organizations. references: - https://media.defense.gov/2023/May/09/2003218554/-1/-1/0/JOINT_CSA_HUNTING_RU_INTEL_SNAKE_MALWARE_20230509.PDF tags: @@ -27,7 +39,8 @@ tags: - 8318ad20-0488-4a64-98f4-72525a012f6b confidence: 50 impact: 50 - message: A registry modification related to Snake Malware has been identified on $dest$. + message: A registry modification related to Snake Malware has been identified on + $dest$. mitre_attack_id: - T1112 observable: @@ -44,13 +57,14 @@ tags: - _time - Registry.dest - Registry.user - - Registry.registry_path - - Registry.registry_key_name + - Registry.registry_path + - Registry.registry_key_name - Registry.registry_value_name security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/snake_malware_regblob-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/snake_malware_regblob-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_snake_malware_service_create.yml b/detections/endpoint/windows_snake_malware_service_create.yml index ec8fd2787b..a256f60b75 100644 --- a/detections/endpoint/windows_snake_malware_service_create.yml +++ b/detections/endpoint/windows_snake_malware_service_create.yml @@ -1,22 +1,29 @@ name: Windows Snake Malware Service Create id: 64eb091f-8cab-4b41-9b09-8fb4942377df -version: 1 -date: '2023-05-11' +version: 2 +date: '2024-05-13' author: Michael Haag, Splunk status: production type: TTP data_source: - Windows Event Log System 7045 -description: 'The following analytic identifies a new service WerFaultSvc being created with a binary path located in the windows winsxs path. Per the report, the Snake version primarily discussed in this advisory registers a service to maintain persistence on a system. Typically this service is named WerFaultSvc which we assess was used to blend in with the legitimate Windows service WerSvc. On boot, this service will execute Snakes WerFault.exe, - which Snake developers chose to hide among the numerous valid Windows WerFault.exe files in the windows WinSxS directory. Executing WerFault.exe will start the process of decrypting Snakes components and loading them into memory.' +description: 'The following analytic detects the creation of a new service named WerFaultSvc + with a binary path in the Windows WinSxS directory. It leverages Windows System + logs, specifically EventCode 7045, to identify this activity. This behavior is significant + because it indicates the presence of Snake malware, which uses this service to maintain + persistence by blending in with legitimate Windows services. If confirmed malicious, + this activity could allow an attacker to execute Snake malware components, leading + to potential data exfiltration, system compromise, and long-term persistence within + the environment.' search: '`wineventlog_system` EventCode=7045 ImagePath="*\\windows\\winSxS\\*" ImagePath="*\Werfault.exe" - | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ImagePath ServiceName ServiceType | rename Computer as dest - | `security_content_ctime(firstTime)` + | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode + ImagePath ServiceName ServiceType | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_snake_malware_service_create_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows System logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. -known_false_positives: False positives should be limited as this is a strict primary indicator used by Snake Malware. +known_false_positives: False positives should be limited as this is a strict primary + indicator used by Snake Malware. references: - https://media.defense.gov/2023/May/09/2003218554/-1/-1/0/JOINT_CSA_HUNTING_RU_INTEL_SNAKE_MALWARE_20230509.PDF tags: @@ -54,7 +61,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/snake-service-windows-system.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/snakemalware/snake-service-windows-system.log source: XmlWinEventLog:System sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_soaphound_binary_execution.yml b/detections/endpoint/windows_soaphound_binary_execution.yml index c092021897..072c606580 100644 --- a/detections/endpoint/windows_soaphound_binary_execution.yml +++ b/detections/endpoint/windows_soaphound_binary_execution.yml @@ -1,21 +1,30 @@ name: Windows SOAPHound Binary Execution id: 8e53f839-e127-4d6d-a54d-a2f67044a57f -version: 2 -date: '2024-03-14' +version: 3 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies the common command-line argument used - by SOAPHound `soaphound.exe`. Being the script is publicly available, function names may be modified, - but these changes are dependent upon the operator. In most instances the defaults - are used. - It does not cover the entirety of every argument in order to avoid false positives. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name="soaphound.exe" OR Processes.original_file_name="soaphound.exe" AND Processes.process IN ("*--buildcache *", "*--bhdump *", "*--certdump *", "*--dnsdump *", "*-c *", "*--cachefilename *", "*-o *", "*--outputdirectory *") by Processes.process Processes.dest Processes.process_current_directory Processes.process_name Processes.process_path Processes.process_integrity_level Processes.parent_process Processes.parent_process_path Processes.parent_process_guid Processes.parent_process_id Processes.process_guid Processes.process_id Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `windows_soaphound_binary_execution_filter`' +description: The following analytic detects the execution of the SOAPHound binary + (`soaphound.exe`) with specific command-line arguments. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on process names, command-line arguments, + and other process-related metadata. This activity is significant because SOAPHound + is a known tool used for credential dumping and other malicious activities. If confirmed + malicious, this behavior could allow an attacker to extract sensitive information, + escalate privileges, or persist within the environment, posing a severe threat to + organizational security. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name="soaphound.exe" + OR Processes.original_file_name="soaphound.exe" AND Processes.process IN ("*--buildcache + *", "*--bhdump *", "*--certdump *", "*--dnsdump *", "*-c *", "*--cachefilename *", + "*-o *", "*--outputdirectory *") by Processes.process Processes.dest Processes.process_current_directory + Processes.process_name Processes.process_path Processes.process_integrity_level + Processes.parent_process Processes.parent_process_path Processes.parent_process_guid + Processes.parent_process_id Processes.process_guid Processes.process_id Processes.user + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `windows_soaphound_binary_execution_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -77,6 +86,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/soaphound/sysmon_soaphound.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/soaphound/sysmon_soaphound.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_spearphishing_attachment_connect_to_none_ms_office_domain.yml b/detections/endpoint/windows_spearphishing_attachment_connect_to_none_ms_office_domain.yml index 5eff1eeef3..ce4cd751bd 100644 --- a/detections/endpoint/windows_spearphishing_attachment_connect_to_none_ms_office_domain.yml +++ b/detections/endpoint/windows_spearphishing_attachment_connect_to_none_ms_office_domain.yml @@ -1,16 +1,17 @@ name: Windows Spearphishing Attachment Connect To None MS Office Domain id: 1cb40e15-cffa-45cc-abbd-e35884a49766 -version: 2 -date: '2023-02-15' +version: 3 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Hunting -description: this detection was designed to identifies suspicious office documents - that connect to a website aside from Microsoft Office Domain. This technique was - seen in several malicious documents that abuses .rels xml properties of MS office - to connect or download malicious files. This hunting query can be a good pivot or - guide to check what URL link it tries to connect, what domain, where the documents - came from and how the connection happens. +description: The following analytic identifies suspicious Office documents that connect + to non-Microsoft Office domains. It leverages Sysmon EventCode 22 to detect processes + like winword.exe or excel.exe making DNS queries to domains outside of *.office.com + or *.office.net. This activity is significant as it may indicate a spearphishing + attempt using malicious documents to download or connect to harmful content. If + confirmed malicious, this could lead to unauthorized data access, malware infection, + or further network compromise. data_source: - Sysmon EventID 22 search: '`sysmon` EventCode=22 Image IN ("*\\winword.exe","*\\excel.exe","*\\powerpnt.exe","*\\mspub.exe","*\\visio.exe","*\\wordpad.exe","*\\wordview.exe","*\\onenote.exe", @@ -61,7 +62,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/office_doc_abuses_rels/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/office_doc_abuses_rels/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_spearphishing_attachment_onenote_spawn_mshta.yml b/detections/endpoint/windows_spearphishing_attachment_onenote_spawn_mshta.yml index 44a398b023..9c851dbfd0 100644 --- a/detections/endpoint/windows_spearphishing_attachment_onenote_spawn_mshta.yml +++ b/detections/endpoint/windows_spearphishing_attachment_onenote_spawn_mshta.yml @@ -1,27 +1,25 @@ name: Windows Spearphishing Attachment Onenote Spawn Mshta id: 35aeb0e7-7de5-444a-ac45-24d6788796ec -version: 1 -date: '2023-01-24' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following detection identifies the latest behavior utilized by different - malware families (including TA551, AsyncRat, Redline and DCRAT). This detection - identifies onenote Office Product spawning `mshta.exe`. In malicious instances, - the command-line of `mshta.exe` will contain the `hta` file locally, or a URL to - the remote destination. In addition, Threat Research has released a detections identifying - suspicious use of `mshta.exe`. In this instance, we narrow our detection down to - the Office suite as a parent process. During triage, review all file modifications. - Capture and analyze any artifacts on disk. The Office Product, or `mshta.exe` will - have reached out to a remote destination, capture and block the IPs or domain. Review - additional parallel processes for further activity. +description: The following analytic detects OneNote spawning `mshta.exe`, a behavior + often associated with spearphishing attacks. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process creation events where OneNote is + the parent process. This activity is significant as it is commonly used by malware + families like TA551, AsyncRat, Redline, and DCRAT to execute malicious scripts. + If confirmed malicious, this could allow attackers to execute arbitrary code, potentially + leading to data exfiltration, system compromise, or further malware deployment. + Immediate investigation and containment are recommended. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name - IN ("onenote.exe", "onenotem.exe") `process_mshta` by Processes.dest Processes.user Processes.parent_process_name - Processes.parent_process Processes.process_name Processes.original_file_name Processes.process - Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + IN ("onenote.exe", "onenotem.exe") `process_mshta` by Processes.dest Processes.user + Processes.parent_process_name Processes.parent_process Processes.process_name Processes.original_file_name + Processes.process Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_spearphishing_attachment_onenote_spawn_mshta_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -79,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/onenote_spear_phishing/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/onenote_spear_phishing/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_special_privileged_logon_on_multiple_hosts.yml b/detections/endpoint/windows_special_privileged_logon_on_multiple_hosts.yml index d4432b6f0c..ebdfcb4170 100644 --- a/detections/endpoint/windows_special_privileged_logon_on_multiple_hosts.yml +++ b/detections/endpoint/windows_special_privileged_logon_on_multiple_hosts.yml @@ -1,25 +1,25 @@ name: Windows Special Privileged Logon On Multiple Hosts id: 4c461f5a-c2cc-4e86-b132-c262fc9edca7 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-24' author: Mauricio Velazco, Splunk type: TTP status: production data_source: - Windows Event Log Security 4672 -description: The following analytic leverages Event ID 4672 to identify a source user - authenticating with special privileges across a large number remote endpoints. Specifically, - the logic will trigger when a source user obtains special privileges across 30 or - more target computers within a 5 minute timespan. Special privileges are assigned - to a new logon session when sensitive privileges like SeDebugPrivilege and SeImpersonatePrivilege - are assigned. This behavior could represent an adversary who is moving laterally - and executing remote code across the network. It can also be triggered by other - behavior like an adversary enumerating network shares. As environments differ across - organizations, security teams should customize the thresholds of this detection - as needed. -search: ' `wineventlog_security` EventCode=4672 AND NOT(Caller_User_Name IN ("DWM-1","DWM-2","DWM-3","LOCAL SERVICE","NETWORK SERVICE","SYSTEM","*$")) | bucket span=5m _time | stats dc(Computer) - AS unique_targets values(Computer) as dest values(PrivilegeList) as privileges - by _time, Caller_User_Name | rename Caller_User_Name as user| where unique_targets > 30 | `windows_special_privileged_logon_on_multiple_hosts_filter`' +description: The following analytic detects a user authenticating with special privileges + on 30 or more remote endpoints within a 5-minute window. It leverages Event ID 4672 + from Windows Security logs to identify this behavior. This activity is significant + as it may indicate lateral movement or remote code execution by an adversary. If + confirmed malicious, the attacker could gain extensive control over the network, + potentially leading to privilege escalation, data exfiltration, or further compromise + of the environment. Security teams should adjust detection thresholds based on their + specific environment. +search: ' `wineventlog_security` EventCode=4672 AND NOT(Caller_User_Name IN ("DWM-1","DWM-2","DWM-3","LOCAL + SERVICE","NETWORK SERVICE","SYSTEM","*$")) | bucket span=5m _time | stats dc(Computer) + AS unique_targets values(Computer) as dest values(PrivilegeList) as privileges by + _time, Caller_User_Name | rename Caller_User_Name as user| where unique_targets + > 30 | `windows_special_privileged_logon_on_multiple_hosts_filter`' how_to_implement: To successfully implement this search, you need to be ingesting special logon events. The Advanced Security Audit policy setting `Audit Special Logon` within `Logon/Logoff` need to be enabled. @@ -37,7 +37,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 80 - message: 'A user $user$ obtained special privileges on a large number of endpoints (Count: $unique_targets$) within 5 minutes.' + message: 'A user $user$ obtained special privileges on a large number of endpoints + (Count: $unique_targets$) within 5 minutes.' mitre_attack_id: - T1087 - T1021.002 @@ -62,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/special_logon_on_mulitple_hosts/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/special_logon_on_mulitple_hosts/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_sql_spawning_certutil.yml b/detections/endpoint/windows_sql_spawning_certutil.yml index cc7c3d5e72..1dba7e5dab 100644 --- a/detections/endpoint/windows_sql_spawning_certutil.yml +++ b/detections/endpoint/windows_sql_spawning_certutil.yml @@ -1,29 +1,20 @@ name: Windows SQL Spawning CertUtil id: dfc18a5a-946e-44ee-a373-c0f60d06e676 -version: 1 -date: '2023-08-25' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: experimental type: TTP data_source: - Sysmon EventID 1 description: The following analytic detects the use of certutil to download software, - a behavior exhibited by the threat actor Flax Typhoon. This actor deploys a VPN - connection by downloading an executable file for SoftEther VPN from their network - infrastructure using one of several LOLBins, including certutil. The actor then - uses the Service Control Manager (SCM) to create a Windows service that launches - the VPN connection automatically when the system starts. This behavior allows the - actor to monitor the availability of the compromised system and establish an RDP - connection. This analytic identifies this behavior by monitoring for the use of - certutil in conjunction with the downloading of software. This behavior is worth - identifying for a SOC as it indicates a potential compromise of the system and the - establishment of a persistent threat. If a true positive is found, it suggests an - attacker has gained access to the environment and is attempting to maintain that - access, potentially leading to further malicious activities such as data theft or - ransomware attacks. Be aware of potential false positives - legitimate uses of certutil - in your environment may cause benign activities to be flagged. Upon triage, review - the command executed and look for concurrent processes to identify the attack source. - This approach helps analysts detect potential threats earlier and mitigate the risks. + specifically when spawned by SQL-related processes. This detection leverages Endpoint + Detection and Response (EDR) data, focusing on command-line executions involving + certutil with parameters like *urlcache* and *split*. This activity is significant + as it may indicate a compromise by threat actors, such as Flax Typhoon, who use + certutil to establish persistent VPN connections. If confirmed malicious, this behavior + could allow attackers to maintain access, monitor system availability, and potentially + escalate to data theft or ransomware deployment. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("sqlservr.exe", "sqlagent.exe", "sqlps.exe", "launchpad.exe", "sqldumper.exe") diff --git a/detections/endpoint/windows_sqlwriter_sqldumper_dll_sideload.yml b/detections/endpoint/windows_sqlwriter_sqldumper_dll_sideload.yml index 46da188c95..e2e505f872 100644 --- a/detections/endpoint/windows_sqlwriter_sqldumper_dll_sideload.yml +++ b/detections/endpoint/windows_sqlwriter_sqldumper_dll_sideload.yml @@ -1,30 +1,36 @@ name: Windows SqlWriter SQLDumper DLL Sideload id: 2ed89ba9-c6c7-46aa-9f08-a2a1c2955aa3 -version: 1 -date: '2024-03-25' +version: 2 +date: '2024-05-17' author: Michael Haag, Teoderick Contreras, Splunk data_source: - Sysmon EventID 7 type: TTP status: production -description: The following analytic identifies the abuse of SqlWriter and SQLDumper executables - to sideload the vcruntime140.dll library. This technique is commonly used by adversaries - to load malicious code into a legitimate process. The analytic searches for EventCode - 7 from Sysmon logs where the Image is either SQLDumper.exe or SQLWriter.exe and the - ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading - of vcruntime140.dll from the System32 directory to reduce false positives. -search: '`sysmon` EventCode=7 (Image="*\\SQLDumper.exe" OR Image="*\\SQLWriter.exe") ImageLoaded="*\\vcruntime140.dll" NOT ImageLoaded="C:\\Windows\\System32\\*" | stats values(ImageLoaded) count min(_time) as firstTime max(_time) as lastTime by Image,ImageLoaded, user, Computer, EventCode | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `windows_sqlwriter_sqldumper_dll_sideload_filter`' +description: The following analytic detects the abuse of SqlWriter and SQLDumper executables + to sideload the vcruntime140.dll library. It leverages Sysmon EventCode 7 logs, + focusing on instances where SQLDumper.exe or SQLWriter.exe load vcruntime140.dll, + excluding legitimate loads from the System32 directory. This activity is significant + as it indicates potential DLL sideloading, a technique used by adversaries to execute + malicious code within trusted processes. If confirmed malicious, this could allow + attackers to execute arbitrary code, maintain persistence, and evade detection by + blending with legitimate processes. +search: '`sysmon` EventCode=7 (Image="*\\SQLDumper.exe" OR Image="*\\SQLWriter.exe") + ImageLoaded="*\\vcruntime140.dll" NOT ImageLoaded="C:\\Windows\\System32\\*" | stats + values(ImageLoaded) count min(_time) as firstTime max(_time) as lastTime by Image,ImageLoaded, + user, Computer, EventCode | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)`| `windows_sqlwriter_sqldumper_dll_sideload_filter`' how_to_implement: The analytic is designed to be run against Sysmon event logs collected - from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. - The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe - and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate - loading of vcruntime140.dll from the System32 directory to reduce false positives. - The analytic can be modified to include additional known good paths for vcruntime140.dll - to further reduce false positives. + from endpoints. The analytic requires the Sysmon event logs to be ingested into + Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe + or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters + out the legitimate loading of vcruntime140.dll from the System32 directory to reduce + false positives. The analytic can be modified to include additional known good paths + for vcruntime140.dll to further reduce false positives. known_false_positives: False positives are possible if legitimate processes are loading - vcruntime140.dll from non-standard directories. It is recommended to investigate the - context of the process loading vcruntime140.dll to determine if it is malicious or - not. Modify the search to include additional known good paths for vcruntime140.dll + vcruntime140.dll from non-standard directories. It is recommended to investigate + the context of the process loading vcruntime140.dll to determine if it is malicious + or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives. references: - https://www.mandiant.com/resources/blog/apt29-wineloader-german-political-parties @@ -67,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/wineloader/sqlwriter_sqldumper_sideload_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/wineloader/sqlwriter_sqldumper_sideload_windows-sysmon.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational diff --git a/detections/endpoint/windows_steal_authentication_certificates___esc1_abuse.yml b/detections/endpoint/windows_steal_authentication_certificates___esc1_abuse.yml index 0d184542b1..be6c246e52 100644 --- a/detections/endpoint/windows_steal_authentication_certificates___esc1_abuse.yml +++ b/detections/endpoint/windows_steal_authentication_certificates___esc1_abuse.yml @@ -1,28 +1,47 @@ name: Windows Steal Authentication Certificates - ESC1 Abuse id: cbe761fc-d945-4c8c-a71d-e26d12255d32 -version: 2 -date: '2024-01-03' +version: 3 +date: '2024-05-11' author: Steven Dick status: production type: TTP -description: The following analytic identifies when a new certificate is requested and/or granted against the Active Directory Certificate Services (AD CS) using a Subject Alternative Name (SAN). This action by its self is not malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1) +description: The following analytic detects when a new certificate is requested or + granted against Active Directory Certificate Services (AD CS) using a Subject Alternative + Name (SAN). It leverages Windows Security Event Codes 4886 and 4887 to identify + these actions. This activity is significant because improperly configured certificate + templates can be exploited for privilege escalation and environment compromise. + If confirmed malicious, an attacker could gain elevated privileges or persist within + the environment, potentially leading to unauthorized access to sensitive information + and further exploitation. data_source: - Windows Event Log Security 4886 - Windows Event Log Security 4887 search: >- `wineventlog_security` EventCode IN (4886,4887) Attributes="*SAN:*upn*" Attributes="*CertificateTemplate:*" - | stats count min(_time) as firstTime max(_time) as lastTime values(name) as name values(status) as status values(Subject) as ssl_subject - values(SubjectKeyIdentifier) as ssl_hash by Computer, EventCode, Requester, Attributes, RequestId - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| fillnull + | stats count min(_time) as firstTime max(_time) as lastTime values(name) as name + values(status) as status values(Subject) as ssl_subject + values(SubjectKeyIdentifier) as ssl_hash by Computer, EventCode, Requester, Attributes, + RequestId + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| fillnull | rex field=Attributes "(?i)CertificateTemplate:(?[^\r\n]+)" | rex field=Attributes "(?i)ccm:(?[^\r\n]+)" | rex max_match=10 field=Attributes "(?i)(upn=(?[^\r\n&]+))" | rex max_match=10 field=Attributes "(?i)(dns=(?[^\r\n&]+))" | rex field=Requester "(.+\\\\)?(?[^\r\n]+)" - | eval flavor_text = case(EventCode=="4886","A suspicious certificate was requested using request ID: ".'RequestId',EventCode=="4887", "A suspicious certificate was issued using request ID: ".'RequestId'.". To revoke this certifacte use this request ID or the SSL fingerprint [".'ssl_hash'."]"), dest = upper(coalesce(req_dest_1,req_dest_2)), src = upper(coalesce(req_src,Computer)) | fields - req_* | rename Attributes as object_attrs, EventCode as signature_id, name as signature, RequestId as ssl_serial, Requester as ssl_subject_common_name| `windows_steal_authentication_certificates___esc1_abuse_filter` -how_to_implement: To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. -known_false_positives: False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names. Sources or templates used in these processes may need to be tuned out for accurate function. + | eval flavor_text = case(EventCode=="4886","A suspicious certificate was requested + using request ID: ".'RequestId',EventCode=="4887", "A suspicious certificate was + issued using request ID: ".'RequestId'.". To revoke this certifacte use this request + ID or the SSL fingerprint [".'ssl_hash'."]"), dest = upper(coalesce(req_dest_1,req_dest_2)), + src = upper(coalesce(req_src,Computer)) | fields - req_* | rename Attributes as + object_attrs, EventCode as signature_id, name as signature, RequestId as ssl_serial, + Requester as ssl_subject_common_name| `windows_steal_authentication_certificates___esc1_abuse_filter` +how_to_implement: To implement this analytic, enhanced Audit Logging must be enabled + on AD CS and within Group Policy Management for CS server. See Page 115 of first + reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. +known_false_positives: False positives may be generated in environments where administrative + users or processes are allowed to generate certificates with Subject Alternative + Names. Sources or templates used in these processes may need to be tuned out for + accurate function. references: - https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf - https://github.com/ly4k/Certipy#esc1 @@ -35,27 +54,27 @@ tags: impact: 100 message: Possible AD CS ESC1 activity by $src_user$ - $flavor_text$ mitre_attack_id: - - T1649 + - T1649 observable: - - name: src - type: Hostname - role: - - Victim - - name: dest - type: Hostname - role: - - Victim - - name: src_user - type: User - role: - - Attacker + - name: src + type: Hostname + role: + - Victim + - name: dest + type: Hostname + role: + - Victim + - name: src_user + type: User + role: + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security - Splunk Cloud required_fields: - _time - - Attributes + - Attributes - Computer - EventCode - Requester @@ -65,7 +84,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_winsecurity.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_winsecurity.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog - update_timestamp: true \ No newline at end of file + update_timestamp: true diff --git a/detections/endpoint/windows_steal_authentication_certificates___esc1_authentication.yml b/detections/endpoint/windows_steal_authentication_certificates___esc1_authentication.yml index 36ae60f96f..dd46987277 100644 --- a/detections/endpoint/windows_steal_authentication_certificates___esc1_authentication.yml +++ b/detections/endpoint/windows_steal_authentication_certificates___esc1_authentication.yml @@ -1,97 +1,115 @@ name: Windows Steal Authentication Certificates - ESC1 Authentication id: f0306acf-a6ab-437a-bbc6-8628f8d5c97e -version: 1 -date: '2023-05-25' +version: 2 +date: '2024-05-24' author: Steven Dick status: production type: TTP -description: The following analytic identifies when a suspicious certificate is granted using Active Directory Certificate Services (AD CS) with a Subject Alternative Name (SAN) and then immediately used for authentication. This action alone may not be malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1). +description: The following analytic detects when a suspicious certificate with a Subject + Alternative Name (SAN) is issued using Active Directory Certificate Services (AD + CS) and then immediately used for authentication. This detection leverages Windows + Security Event Logs, specifically EventCode 4887, to identify the issuance and subsequent + use of the certificate. This activity is significant because improperly configured + certificate templates can be exploited for privilege escalation and environment + compromise. If confirmed malicious, an attacker could gain unauthorized access, + escalate privileges, and potentially compromise the entire environment. data_source: - - Windows Event Log Security 4887 - - Windows Event Log Security 4768 +- Windows Event Log Security 4887 +- Windows Event Log Security 4768 search: >- `wineventlog_security` EventCode IN (4887) Attributes="*SAN:*upn*" Attributes="*CertificateTemplate:*" - | stats count min(_time) as firstTime max(_time) as lastTime values(name) as name values(status) as status values(Subject) as ssl_subject values(SubjectKeyIdentifier) as ssl_hash by Computer, EventCode, Requester, Attributes, RequestId + | stats count min(_time) as firstTime max(_time) as lastTime values(name) as name + values(status) as status values(Subject) as ssl_subject values(SubjectKeyIdentifier) + as ssl_hash by Computer, EventCode, Requester, Attributes, RequestId | rex field=Attributes "(?i)CertificateTemplate:(?[^\r\n]+)" | rex field=Attributes "(?i)ccm:(?[^\r\n]+)" | rex max_match=10 field=Attributes "(?i)(upn=(?[^\r\n&]+))" | rex max_match=10 field=Attributes "(?i)(dns=(?[^\r\n&]+))" | rex field=Requester "(.+\\\\)?(?[^\r\n]+)" - | rename Attributes as object_attrs, EventCode as signature_id, name as signature, RequestId as ssl_serial, Requester as ssl_subject_common_name - | eval user = lower(coalesce(req_user_1,req_user_2)) - | join user + | rename Attributes as object_attrs, EventCode as signature_id, name as signature, + RequestId as ssl_serial, Requester as ssl_subject_common_name + | eval user = lower(coalesce(req_user_1,req_user_2)) | join user [ | search `wineventlog_security` EventCode=4768 CertThumbprint=* | rename TargetUserName as user, Computer as auth_dest, IpAddress as auth_src | fields auth_src,auth_dest,user ] - | eval src = upper(coalesce(auth_src,req_src)), dest = upper(coalesce(auth_dest,req_dest_1,req_dest_2)), risk_score = 90 - | eval flavor_text = case(signature_id=="4887", "User account [".'user'."] authenticated after a suspicious certificate was issued for it by [".'src_user'."] using certificate request ID: ".'ssl_serial') + | eval src = upper(coalesce(auth_src,req_src)), dest = upper(coalesce(auth_dest,req_dest_1,req_dest_2)), + risk_score = 90 + | eval flavor_text = case(signature_id=="4887", "User account [".'user'."] authenticated + after a suspicious certificate was issued for it by [".'src_user'."] using certificate + request ID: ".'ssl_serial') | fields - req_* auth_* | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_steal_authentication_certificates___esc1_authentication_filter` -how_to_implement: To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. -known_false_positives: False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names for authentication. Sources or templates used in these processes may need to be tuned out for accurate function. +how_to_implement: To implement this analytic, enhanced Audit Logging must be enabled + on AD CS and within Group Policy Management for CS server. See Page 115 of first + reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. +known_false_positives: False positives may be generated in environments where administrative + users or processes are allowed to generate certificates with Subject Alternative + Names for authentication. Sources or templates used in these processes may need + to be tuned out for accurate function. references: - - https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf - - https://github.com/ly4k/Certipy#esc1 - - https://pentestlaboratories.com/2021/11/08/threat-hunting-certificate-account-persistence/ +- https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf +- https://github.com/ly4k/Certipy#esc1 +- https://pentestlaboratories.com/2021/11/08/threat-hunting-certificate-account-persistence/ tags: analytic_story: - - Windows Certificate Services + - Windows Certificate Services asset_type: Endpoint confidence: 90 impact: 100 message: Possible AD CS ESC1 authentication on $dest$ mitre_attack_id: - - T1649 - - T1550 + - T1649 + - T1550 observable: - - name: src - type: Hostname - role: - - Victim - - name: dest - type: Hostname - role: - - Victim - - name: src_user - type: User - role: - - Victim - - name: user - type: User - role: - - Victim - - name: ssl_hash - type: Other - role: - - Attacker - - name: ssl_serial - type: Other - role: - - Attacker + - name: src + type: Hostname + role: + - Victim + - name: dest + type: Hostname + role: + - Victim + - name: src_user + type: User + role: + - Victim + - name: user + type: User + role: + - Victim + - name: ssl_hash + type: Other + role: + - Attacker + - name: ssl_serial + type: Other + role: + - Attacker product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - Attributes - - Computer - - EventCode - - Requester - - RequestId - - TargetUserName - - Computer - - IpAddress + - _time + - Attributes + - Computer + - EventCode + - Requester + - RequestId + - TargetUserName + - Computer + - IpAddress risk_score: 90 security_domain: endpoint tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_winsecurity.log - source: XmlWinEventLog:Security - sourcetype: XmlWinEventLog - update_timestamp: true +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_winsecurity.log + source: XmlWinEventLog:Security + sourcetype: XmlWinEventLog + update_timestamp: true diff --git a/detections/endpoint/windows_steal_authentication_certificates_certificate_issued.yml b/detections/endpoint/windows_steal_authentication_certificates_certificate_issued.yml index 461d2e4a08..73de2f92b3 100644 --- a/detections/endpoint/windows_steal_authentication_certificates_certificate_issued.yml +++ b/detections/endpoint/windows_steal_authentication_certificates_certificate_issued.yml @@ -1,19 +1,18 @@ name: Windows Steal Authentication Certificates Certificate Issued id: 9b1a5385-0c31-4c39-9753-dc26b8ce64c2 -version: 1 -date: '2023-02-06' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies when a new certificate is issued against - the Certificate Services - AD CS. By its very nature this is not malicious, but - should be tracked and correlated with other events related to certificates being - issued. When the CA issues the certificate, it creates EID 4887 'Certificate Services - approved a certificate request and issued a certificate". The event supplies the - requester user context, the DNS hostname of the machine they requested the certificate - from, and the time they requested the certificate. The attributes fields in these - event commonly has values for CDC, RMD, and CCM which correspond to Client DC, Request - Machine DNS name, and Cert Client Machine, respectively. +description: The following analytic identifies the issuance of a new certificate by + Certificate Services - AD CS, detected via Event ID 4887. This event logs the requester + user context, DNS hostname of the requesting machine, and the request time. Monitoring + this activity is crucial as it can indicate potential misuse of authentication certificates. + If confirmed malicious, an attacker could use the issued certificate to impersonate + users, escalate privileges, or maintain persistence within the environment. This + detection helps in identifying and correlating suspicious certificate-related activities + for further investigation. data_source: - Windows Event Log Security 4887 search: '`wineventlog_security` EventCode=4887 | stats count min(_time) as firstTime @@ -56,7 +55,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/4887_windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/4887_windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_steal_authentication_certificates_certificate_request.yml b/detections/endpoint/windows_steal_authentication_certificates_certificate_request.yml index b24e29fbe6..5b5fac3a21 100644 --- a/detections/endpoint/windows_steal_authentication_certificates_certificate_request.yml +++ b/detections/endpoint/windows_steal_authentication_certificates_certificate_request.yml @@ -1,15 +1,18 @@ name: Windows Steal Authentication Certificates Certificate Request id: 747d7800-2eaa-422d-b994-04d8bb9e06d0 -version: 1 -date: '2023-02-06' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies when a new certificate is requested - against the Certificate Services - AD CS. By its very nature this is not malicious, - but should be tracked and correlated with other events related to certificate requests. - When an account requests a certificate, the CA generates event ID (EID) 4886 "Certificate - Services received a certificate request". +description: The following analytic detects when a new certificate is requested from + Certificate Services - AD CS. It leverages Event ID 4886, which indicates that a + certificate request has been received. This activity is significant because unauthorized + certificate requests can be part of credential theft or lateral movement tactics. + If confirmed malicious, an attacker could use the certificate to impersonate users, + gain unauthorized access to resources, or establish persistent access within the + environment. Monitoring and correlating this event with other suspicious activities + is crucial for identifying potential security incidents. data_source: - Windows Event Log Security 4886 search: '`wineventlog_security` EventCode=4886 | stats count min(_time) as firstTime @@ -52,7 +55,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/4886_windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/4886_windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_steal_authentication_certificates_cryptoapi.yml b/detections/endpoint/windows_steal_authentication_certificates_cryptoapi.yml index 688f489b94..ebeefc9216 100644 --- a/detections/endpoint/windows_steal_authentication_certificates_cryptoapi.yml +++ b/detections/endpoint/windows_steal_authentication_certificates_cryptoapi.yml @@ -1,17 +1,17 @@ name: Windows Steal Authentication Certificates CryptoAPI id: 905d5692-6d7c-432f-bc7e-a6b4f464d40e -version: 1 -date: '2023-02-08' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI - 2, to identify suspicious certificate extraction. Typically, this event log is meant - for diagnosing PKI issues, however is a great source to identify certificate exports. - Note that this event log is noisy as it captures common PKI requests from many different - processes. EventID 70 is generated anytime a certificate is exported. The description - for EventID 70 is "Acquire Certificate Private Key". STRT tested this analytic using - Mimikatz binary and the implementation of Mimikatz in Cobalt Strike. +description: The following analytic detects the extraction of authentication certificates + using Windows Event Log - CAPI2 (CryptoAPI 2). It leverages EventID 70, which is + generated when a certificate's private key is acquired. This detection is significant + because it can identify potential misuse of certificates, such as those extracted + by tools like Mimikatz or Cobalt Strike. If confirmed malicious, this activity could + allow attackers to impersonate users, escalate privileges, or access sensitive information, + posing a severe risk to the organization's security. data_source: - Windows Event Log CAPI2 70 search: '`capi2_operational` EventCode=70 | xmlkv UserData_Xml | stats count min(_time) @@ -53,7 +53,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/capi2-operational.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/atomic_red_team/capi2-operational.log source: XmlWinEventLog:Microsoft-Windows-CAPI2/Operational sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_steal_or_forge_kerberos_tickets_klist.yml b/detections/endpoint/windows_steal_or_forge_kerberos_tickets_klist.yml index 7f712868df..7603dbc2ad 100644 --- a/detections/endpoint/windows_steal_or_forge_kerberos_tickets_klist.yml +++ b/detections/endpoint/windows_steal_or_forge_kerberos_tickets_klist.yml @@ -1,16 +1,18 @@ name: Windows Steal or Forge Kerberos Tickets Klist id: 09d88404-1e29-46cb-806c-1eedbc85ad5d -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process execution of Windows OS klist.exe - tool. This tool is being abused or used by several post exploitation tool such as - winpeas that being used by ransomware prestige to display or gather list of currently - cached kerberos ticket. This cahced data can be used for lateral movement or even - privilege escalation on the targeted host. This hunting query can be a good pivot - in possible kerberos attack or pass the hash technique. +description: The following analytic identifies the execution of the Windows OS tool + klist.exe, often used by post-exploitation tools like winpeas. This detection leverages + data from Endpoint Detection and Response (EDR) agents, focusing on process and + parent process details. Monitoring klist.exe is significant as it can indicate attempts + to list or gather cached Kerberos tickets, which are crucial for lateral movement + or privilege escalation. If confirmed malicious, this activity could enable attackers + to move laterally within the network or escalate privileges, posing a severe security + risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_suspect_process_with_authentication_traffic.yml b/detections/endpoint/windows_suspect_process_with_authentication_traffic.yml index 5c80bfb48b..3529b53f4f 100644 --- a/detections/endpoint/windows_suspect_process_with_authentication_traffic.yml +++ b/detections/endpoint/windows_suspect_process_with_authentication_traffic.yml @@ -1,85 +1,91 @@ name: Windows Suspect Process With Authentication Traffic id: 953322db-128a-4ce9-8e89-56e039e33d98 -version: 1 -date: '2023-06-13' +version: 2 +date: '2024-05-15' author: Steven Dick status: production type: Anomaly description: >- - This analytic identifies executables running from public or temporary locations that are communicating over windows domain - authentication ports/protocol. The ports/protocols include LDAP(389), LDAPS(636), and Kerberos(88). Authentications from applications - running from user controlled locations may not be malicious, however actors often attempt to access domain resources after initial - compromise from executables in these locations. Most attacker toolkits offer some degree of interaction with AD/LDAP. + The following analytic detects executables running from public or temporary locations + that are communicating over Windows domain authentication ports/protocols such as + LDAP (389), LDAPS (636), and Kerberos (88). It leverages network traffic data to + identify processes originating from user-controlled directories. This activity is + significant because legitimate applications rarely run from these locations and + attempt domain authentication, making it a potential indicator of compromise. If + confirmed malicious, attackers could leverage this to access domain resources, potentially + leading to further exploitation and lateral movement within the network. data_source: - - Sysmon EventID 3 +- Sysmon EventID 3 search: >- - | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(All_Traffic.process_id) as process_id - from datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port IN ("88","389","636") - AND All_Traffic.app IN ("*\\users\\*", "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") - by All_Traffic.app,All_Traffic.src,All_Traffic.src_ip,All_Traffic.user,All_Traffic.dest,All_Traffic.dest_ip,All_Traffic.dest_port - | `drop_dm_object_name(All_Traffic)` - | rex field=app ".*\\\(?.*)$" + | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(All_Traffic.process_id) as process_id from datamodel=Network_Traffic.All_Traffic + where All_Traffic.dest_port IN ("88","389","636") AND All_Traffic.app IN ("*\\users\\*", + "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") by + All_Traffic.app,All_Traffic.src,All_Traffic.src_ip,All_Traffic.user,All_Traffic.dest,All_Traffic.dest_ip,All_Traffic.dest_port + | `drop_dm_object_name(All_Traffic)` | rex field=app ".*\\\(?.*)$" | rename app as process - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_suspect_process_with_authentication_traffic_filter` how_to_implement: >- - To implement this analytic, Sysmon should be installed in the environment and generating network events for - userland and/or known public writable locations. + To implement this analytic, Sysmon should be installed in the environment and generating + network events for userland and/or known public writable locations. known_false_positives: >- - Known applications running from these locations for legitimate purposes. Targeting only kerberos (port 88) + Known applications running from these locations for legitimate purposes. Targeting + only kerberos (port 88) may significantly reduce noise. references: - - https://attack.mitre.org/techniques/T1069/002/ - - https://book.hacktricks.xyz/network-services-pentesting/pentesting-kerberos-88 +- https://attack.mitre.org/techniques/T1069/002/ +- https://book.hacktricks.xyz/network-services-pentesting/pentesting-kerberos-88 tags: analytic_story: - - Active Directory Discovery + - Active Directory Discovery asset_type: Endpoint confidence: 50 impact: 50 - message: The process $process_name$ on $src$ has been communicating with $dest$ on $dest_port$. + message: The process $process_name$ on $src$ has been communicating with $dest$ + on $dest_port$. mitre_attack_id: - - T1087 - - T1087.002 - - T1204 - - T1204.002 + - T1087 + - T1087.002 + - T1204 + - T1204.002 observable: - - name: src - type: Hostname - role: - - Victim - - name: dest - type: Hostname - role: - - Victim - - name: user - type: User - role: - - Victim - - name: process_name - type: Process - role: - - Attacker + - name: src + type: Hostname + role: + - Victim + - name: dest + type: Hostname + role: + - Victim + - name: user + type: User + role: + - Victim + - name: process_name + type: Process + role: + - Attacker product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - All_Traffic.app - - All_Traffic.src - - All_Traffic.src_ip - - All_Traffic.user - - All_Traffic.dest - - All_Traffic.dest_ip - - All_Traffic.dest_port + - _time + - All_Traffic.app + - All_Traffic.src + - All_Traffic.src_ip + - All_Traffic.user + - All_Traffic.dest + - All_Traffic.dest_ip + - All_Traffic.dest_port risk_score: 25 security_domain: endpoint tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog - update_timestamp: true \ No newline at end of file +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1649/certify_abuse/certify_esc1_abuse_sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog + update_timestamp: true diff --git a/detections/endpoint/windows_system_binary_proxy_execution_compiled_html_file_decompile.yml b/detections/endpoint/windows_system_binary_proxy_execution_compiled_html_file_decompile.yml index 850a26bf92..87d2c4fbed 100644 --- a/detections/endpoint/windows_system_binary_proxy_execution_compiled_html_file_decompile.yml +++ b/detections/endpoint/windows_system_binary_proxy_execution_compiled_html_file_decompile.yml @@ -1,16 +1,18 @@ name: Windows System Binary Proxy Execution Compiled HTML File Decompile id: 2acf0e19-4149-451c-a3f3-39cd3c77e37d -version: 1 -date: '2022-08-31' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the decompile parameter with the HTML - Help application, HH.exe. This is a uncommon command to see ran and behavior. Most - recently this was seen in a APT41 campaign where a CHM file was delivered and a - script inside used a technique for running an arbitrary command in a CHM file via - an ActiveX object. This unpacks an HTML help file to a specified path for launching - the next stage. +description: The following analytic detects the use of the decompile parameter with + the HTML Help application (HH.exe). This behavior is identified through Endpoint + Detection and Response (EDR) telemetry, focusing on command-line executions involving + the decompile parameter. This activity is significant because it is an uncommon + command and has been associated with APT41 campaigns, where it was used to unpack + HTML help files for further malicious actions. If confirmed malicious, this technique + could allow attackers to execute arbitrary commands, potentially leading to further + compromise and persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,7 +82,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/hh_decom_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.001/atomic_red_team/hh_decom_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_discovery_using_ldap_nslookup.yml b/detections/endpoint/windows_system_discovery_using_ldap_nslookup.yml index 5223d60b80..d947e3ab84 100644 --- a/detections/endpoint/windows_system_discovery_using_ldap_nslookup.yml +++ b/detections/endpoint/windows_system_discovery_using_ldap_nslookup.yml @@ -1,15 +1,18 @@ name: Windows System Discovery Using ldap Nslookup id: 2418780f-7c3e-4c45-b8b4-996ea850cd49 -version: 1 -date: '2022-10-21' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies the execution of nslookup.exe tool - to get domain information. Nslookup.exe is a command-line tool that can display - information to diagnose domain name systems. This Nslookup feature is being abused - by Qakbot malware to gather domain information such as SRV service location records, - server name and many more. +description: The following analytic detects the execution of nslookup.exe to query + domain information using LDAP. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process names and command-line arguments. This activity + is significant as nslookup.exe can be abused by malware like Qakbot to gather critical + domain details, such as SRV records and server names. If confirmed malicious, this + behavior could allow attackers to map the network, identify key servers, and plan + further attacks, potentially leading to data exfiltration or lateral movement within + the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -69,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/qakbot_discovery_cmdline/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/qakbot_discovery_cmdline/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_discovery_using_qwinsta.yml b/detections/endpoint/windows_system_discovery_using_qwinsta.yml index b105eca029..384ab9d953 100644 --- a/detections/endpoint/windows_system_discovery_using_qwinsta.yml +++ b/detections/endpoint/windows_system_discovery_using_qwinsta.yml @@ -1,16 +1,18 @@ name: Windows System Discovery Using Qwinsta id: 2e765c1b-144a-49f0-93d0-1df4287cca04 -version: 1 -date: '2022-10-21' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies the execution of qwinsta.exe executable - in Windows Operating System. This Windows executable file can display information - about sessions on a remote desktop session host server. The information includes - servername, sessionname, username and many more. This tool is being abused of Qakbot - malware to gather information to the targeted or compromised host that will be send - back to its Command And Control server. +description: The following analytic detects the execution of "qwinsta.exe" on a Windows + operating system. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs. The "qwinsta.exe" tool is significant + because it can display detailed session information on a remote desktop session + host server. This behavior is noteworthy as it is commonly abused by Qakbot malware + to gather system information and send it back to its Command and Control (C2) server. + If confirmed malicious, this activity could lead to unauthorized data exfiltration + and further compromise of the host. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -70,7 +72,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/qakbot_discovery_cmdline/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/qakbot_discovery_cmdline/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_file_on_disk.yml b/detections/endpoint/windows_system_file_on_disk.yml index af84726b29..0b7236e303 100644 --- a/detections/endpoint/windows_system_file_on_disk.yml +++ b/detections/endpoint/windows_system_file_on_disk.yml @@ -1,15 +1,17 @@ name: Windows System File on Disk id: 993ce99d-9cdd-42c7-a2cf-733d5954e5a6 -version: 2 -date: '2022-05-16' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic will assist with identifying new .sys - files introduced in the environment. This query is meant to identify sys file creates - on disk. There will be noise, but reducing common process names or applications - should help to limit any volume. The idea is to identify new sys files written to - disk and identify them before they're added as a new kernel mode driver. +description: The following analytic detects the creation of new .sys files on disk. + It leverages the Endpoint.Filesystem data model to identify and log instances where + .sys files are written to the filesystem. This activity is significant because .sys + files are often used as kernel mode drivers, and their unauthorized creation can + indicate malicious activity such as rootkit installation. If confirmed malicious, + this could allow an attacker to gain kernel-level access, leading to full system + compromise, persistent control, and the ability to bypass security mechanisms. data_source: - Sysmon EventID 11 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -61,7 +63,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/sysmon_sys_filemod.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/drivers/sysmon_sys_filemod.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_logoff_commandline.yml b/detections/endpoint/windows_system_logoff_commandline.yml index bb9fb20937..feb74b6866 100644 --- a/detections/endpoint/windows_system_logoff_commandline.yml +++ b/detections/endpoint/windows_system_logoff_commandline.yml @@ -1,26 +1,28 @@ name: Windows System LogOff Commandline id: 74a8133f-93e7-4b71-9bd3-13a66124fd57 -version: 1 -date: '2022-07-27' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies Windows commandline to logoff a windows - host machine. This technique was seen in several APT, RAT like dcrat and other commodity - malware to shutdown the machine to add more impact, interrupt access, aid destruction - of the system like wiping disk or inhibit system recovery. This TTP is a good pivot - to check why application trigger this commandline which is not so common way to - logoff a machine. +description: The following analytic detects the execution of the Windows command line + to log off a host machine. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on processes involving `shutdown.exe` with specific parameters. + This activity is significant as it is often associated with Advanced Persistent + Threats (APTs) and Remote Access Trojans (RATs) like dcrat, which use this technique + to disrupt operations, aid in system destruction, or inhibit recovery. If confirmed + malicious, this could lead to system downtime, data loss, or hindered incident response + efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_name = shutdown.exe OR Processes.original_file_name = shutdown.exe) - Processes.process="*shutdown*" Processes.process IN ("* /l*", "* -l*") Processes.process IN ("* /t*","* -t*","* /f*","* -f*") - by Processes.dest Processes.user Processes.parent_process Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_system_logoff_commandline_filter`' + Processes.process="*shutdown*" Processes.process IN ("* /l*", "* -l*") Processes.process + IN ("* /t*","* -t*","* /f*","* -f*") by Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.original_file_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_system_logoff_commandline_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -72,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/reboot_logoff_commandline/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/reboot_logoff_commandline/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_network_config_discovery_display_dns.yml b/detections/endpoint/windows_system_network_config_discovery_display_dns.yml index 2dbcff4187..9a66d7d083 100644 --- a/detections/endpoint/windows_system_network_config_discovery_display_dns.yml +++ b/detections/endpoint/windows_system_network_config_discovery_display_dns.yml @@ -1,18 +1,18 @@ name: Windows System Network Config Discovery Display DNS id: e24f0a0e-41a9-419f-9999-eacab15efc36 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process command line that retrieves - dns reply information using Windows OS built-in tool IPConfig. This technique is - being abused by threat actors, adversaries and post exploitation tools like WINPEAS - to retrieve DNS information for the targeted host. This IPConfig parameter (/displaydns) - can show dns server resource record, record name, record type, time to live data - length and dns reply. This hunting detection can be a good pivot to check which - process is executing this command line in specific host system that may lead to - malware or adversaries gathering network information. +description: The following analytic identifies the execution of the "ipconfig /displaydns" + command, which retrieves DNS reply information using the built-in Windows tool IPConfig. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on process command-line executions. Monitoring this activity is significant + as threat actors and post-exploitation tools like WINPEAS often abuse this command + to gather network information. If confirmed malicious, this activity could allow + attackers to map the network, identify DNS servers, and potentially facilitate further + network-based attacks or lateral movement. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -75,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_network_connections_discovery_netsh.yml b/detections/endpoint/windows_system_network_connections_discovery_netsh.yml index 71758b47cc..83a2f34969 100644 --- a/detections/endpoint/windows_system_network_connections_discovery_netsh.yml +++ b/detections/endpoint/windows_system_network_connections_discovery_netsh.yml @@ -1,18 +1,18 @@ name: Windows System Network Connections Discovery Netsh id: abfb7cc5-c275-4a97-9029-62cd8d4ffeca -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-17' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a process execution of Windows OS built-in - tool netsh.exe to show state, configuration and profile of host firewall. This tool - is being used or abused by several adversaries or even post exploitation tool to - bypass firewall rules or to discover firewall settings. This hunting detection can - help to detect a possible suspicious usage of netsh.exe to retrieve firewall settings - or even firewall wlan profile. We recommend checking which parent process and process - name execute this command. Also check the process file path for verification that - may lead to further TTP's threat behavior. +description: The following analytic detects the execution of the Windows built-in + tool netsh.exe to display the state, configuration, and profile of the host firewall. + This detection leverages data from Endpoint Detection and Response (EDR) agents, + focusing on command-line executions and process metadata. Monitoring this activity + is crucial as netsh.exe can be used by adversaries to bypass firewall rules or discover + firewall settings. If confirmed malicious, this activity could allow attackers to + manipulate firewall configurations, potentially leading to unauthorized network + access or data exfiltration. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -76,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_reboot_commandline.yml b/detections/endpoint/windows_system_reboot_commandline.yml index a3f111dcdf..7960407df0 100644 --- a/detections/endpoint/windows_system_reboot_commandline.yml +++ b/detections/endpoint/windows_system_reboot_commandline.yml @@ -1,27 +1,28 @@ name: Windows System Reboot CommandLine id: 97fc2b60-c8eb-4711-93f7-d26fade3686f -version: 1 -date: '2022-07-27' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies Windows commandline to reboot a windows - host machine. This technique was seen in several APT, RAT like dcrat and other commodity - malware to shutdown the machine to add more impact, interrupt access, aid destruction - of the system like wiping disk or inhibit system recovery. This TTP is a good pivot - to check why application trigger this commandline which is not so common way to - reboot a machine. Compare to shutdown and logoff shutdown.exe feature, reboot seen - in some automation script like ansible to reboot the machine. +description: The following analytic identifies the execution of the Windows command + line to reboot a host machine using "shutdown.exe" with specific parameters. This + detection leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process names and command-line arguments. This activity is significant as it + is often associated with advanced persistent threats (APTs) and remote access trojans + (RATs) like dcrat, which may use system reboots to disrupt operations, aid in system + destruction, or inhibit recovery. If confirmed malicious, this could lead to system + downtime, data loss, or hindered incident response efforts. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_name = shutdown.exe OR Processes.original_file_name = shutdown.exe) - Processes.process="*shutdown*" Processes.process IN ("* /r*", "* -r*") Processes.process IN ("* /t*","* -t*","* /f*","* -f*") - by Processes.dest Processes.user Processes.parent_process Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_system_reboot_commandline_filter`' + Processes.process="*shutdown*" Processes.process IN ("* /r*", "* -r*") Processes.process + IN ("* /t*","* -t*","* /f*","* -f*") by Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.original_file_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_system_reboot_commandline_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -74,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/reboot_logoff_commandline/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/reboot_logoff_commandline/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_shutdown_commandline.yml b/detections/endpoint/windows_system_shutdown_commandline.yml index 22f6750b5c..2aa6d6ec78 100644 --- a/detections/endpoint/windows_system_shutdown_commandline.yml +++ b/detections/endpoint/windows_system_shutdown_commandline.yml @@ -1,33 +1,27 @@ name: Windows System Shutdown CommandLine id: 4fee57b8-d825-4bf3-9ea8-bf405cdb614c -version: 2 -date: '2023-06-20' +version: 3 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This detection rule is designed to identify the execution of the Windows - shutdown command via command line interface. The shutdown command can be utilized - by system administrators to properly halt, power off, or reboot a computer. However, - in a security context, attackers who have gained unauthorized access to a system - may also use this command in an effort to erase tracks, or to cause disruption and - denial of service. In some instances, they might execute the shutdown command after - installing a backdoor, to force the system to restart, ensuring that changes take - effect or evading detection by security tools. Monitoring for the use of the Windows - shutdown command, especially in conjunction with other unusual or unauthorized activities, - can be an important part of identifying malicious behavior within a network. It - is advised that security professionals analyze the context in which the shutdown - command is being executed to differentiate between legitimate administrative functions - and potentially malicious activity. +description: The following analytic identifies the execution of the Windows shutdown + command via the command line interface. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process names and command-line arguments. + This activity is significant because attackers may use the shutdown command to erase + tracks, cause disruption, or ensure changes take effect after installing backdoors. + If confirmed malicious, this activity could lead to system downtime, denial of service, + or evasion of security tools, impacting the overall security posture of the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process_name = shutdown.exe OR Processes.original_file_name = shutdown.exe) - Processes.process="*shutdown*" AND Processes.process IN("* /s*", "* -s*") AND Processes.process IN ("* /t*","* -t*","* /f*","* -f*") - by Processes.dest Processes.user Processes.parent_process Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_system_shutdown_commandline_filter`' + Processes.process="*shutdown*" AND Processes.process IN("* /s*", "* -s*") AND Processes.process + IN ("* /t*","* -t*","* /f*","* -f*") by Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.original_file_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_system_shutdown_commandline_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -81,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/shutdown_commandline/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/shutdown_commandline/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_time_discovery_w32tm_delay.yml b/detections/endpoint/windows_system_time_discovery_w32tm_delay.yml index 7e7a154eeb..c013297983 100644 --- a/detections/endpoint/windows_system_time_discovery_w32tm_delay.yml +++ b/detections/endpoint/windows_system_time_discovery_w32tm_delay.yml @@ -1,15 +1,18 @@ name: Windows System Time Discovery W32tm Delay id: b2cc69e7-11ba-42dc-a269-59c069a48870 -version: 1 -date: '2022-07-28' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies DCRat delay time tactics using w32tm. - This technique was seen in DCRAT malware where it uses stripchart function of w32tm.exe - application to delay the execution of its payload like c2 communication , beaconing - and execution. This anomaly detection may help the analyst to check other possible - event like the process who execute this command that may lead to DCRat attack. +description: The following analytic identifies the use of the w32tm.exe utility with + the /stripchart function, which is indicative of DCRat malware delaying its payload + execution. This detection leverages data from Endpoint Detection and Response (EDR) + agents, focusing on specific command-line arguments used by w32tm.exe. This activity + is significant as it may indicate an attempt to evade detection by delaying malicious + actions such as C2 communication and beaconing. If confirmed malicious, this behavior + could allow an attacker to maintain persistence and execute further malicious activities + undetected. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process @@ -71,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_delay_execution/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/dcrat/dcrat_delay_execution/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_user_discovery_via_quser.yml b/detections/endpoint/windows_system_user_discovery_via_quser.yml index 0dfccf1a75..6d2a13035e 100644 --- a/detections/endpoint/windows_system_user_discovery_via_quser.yml +++ b/detections/endpoint/windows_system_user_discovery_via_quser.yml @@ -1,20 +1,18 @@ name: Windows System User Discovery Via Quser id: 0c3f3e09-e47a-410e-856f-a02a5c5fafb0 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-20' author: Teoderick Contreras, Splunk status: production type: Hunting -description: The following analytic identifies a process execution of Windows OS quser.exe - tool. This tool is being abused or used by several post exploitation tool such as - winpeas that being used by ransomware prestige to display or gather information - about user sessions on a Remote Desktop Session Host server. This command can find - out if a specific user is logged on to a specific Remote Desktop Session Host server. - This tool can retrieve some RDP information that can be use by attacker for further - attack like Name of the user , Name of the session on the Remote Desktop Session - Host server, Session ID, State of the session (active or disconnected), Idle time - (the number of minutes since the last keystroke or mouse movement at the session) - and Date and time the user logged on. +description: The following analytic detects the execution of the Windows OS tool quser.exe, + commonly used to gather information about user sessions on a Remote Desktop Session + Host server. This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process execution logs. Monitoring this activity is crucial + as quser.exe is often abused by post-exploitation tools like winpeas, used in ransomware + attacks to enumerate user sessions. If confirmed malicious, attackers could leverage + this information to further compromise the system, maintain persistence, or escalate + privileges. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -78,7 +76,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_system_user_privilege_discovery.yml b/detections/endpoint/windows_system_user_privilege_discovery.yml index cf745ccdda..99dd2dfba5 100644 --- a/detections/endpoint/windows_system_user_privilege_discovery.yml +++ b/detections/endpoint/windows_system_user_privilege_discovery.yml @@ -1,20 +1,24 @@ name: Windows System User Privilege Discovery id: 8c9a06bc-9939-4425-9bb9-be2371f7fb7e -version: 1 -date: '2023-12-15' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Hunting data_source: - Sysmon EventID 1 -description: This analytic looks for the execution of `whoami.exe` with /priv parameter. - This whoami command is used to display or shows the privileges assigned to the current user account. - This hunting query can be a good pivot start to look for suspicious usage of whoami application that might related to a malware or adversaries. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name="whoami.exe" Processes.process= "*/priv*" by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects the execution of `whoami.exe` with the + `/priv` parameter, which displays the privileges assigned to the current user account. + It leverages data from Endpoint Detection and Response (EDR) agents, focusing on + process names and command-line executions. This activity is significant as it may + indicate an adversary attempting to enumerate user privileges, a common step in + the reconnaissance phase of an attack. If confirmed malicious, this could lead to + privilege escalation or further exploitation within the environment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name="whoami.exe" + Processes.process= "*/priv*" by Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_system_user_privilege_discovery_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related @@ -25,7 +29,8 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: Administrators or power users may use this command for troubleshooting. Filter as needed. +known_false_positives: Administrators or power users may use this command for troubleshooting. + Filter as needed. references: - https://attack.mitre.org/techniques/T1033/ - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a @@ -35,7 +40,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 30 - message: Activity related to system user privilege discovery detected on $dest$ using whoami.exe. + message: Activity related to system user privilege discovery detected on $dest$ + using whoami.exe. mitre_attack_id: - T1033 observable: @@ -65,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/whoami_priv/whoami-priv-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/whoami_priv/whoami-priv-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_terminating_lsass_process.yml b/detections/endpoint/windows_terminating_lsass_process.yml index 1a1246ccc7..fe239ff752 100644 --- a/detections/endpoint/windows_terminating_lsass_process.yml +++ b/detections/endpoint/windows_terminating_lsass_process.yml @@ -1,26 +1,24 @@ name: Windows Terminating Lsass Process id: 7ab3c319-a4e7-4211-9e8c-40a049d0dba6 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-23' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: This analytic is to detect a suspicious process terminating Lsass process. - Lsass process is known to be a critical process that is responsible for enforcing - security policy system. This process was commonly targetted by threat actor or red - teamer to gain privilege escalation or persistence in the targeted machine because - it handles credentials of the logon users. In this analytic we tried to detect a - suspicious process having a granted access PROCESS_TERMINATE to lsass process to - modify or delete protected registrys. This technique was seen in doublezero malware - that tries to wipe files and registry in compromised hosts. This anomaly detection - can be a good pivot of incident response for possible credential dumping or evading - security policy in a host or network environment. +description: The following analytic detects a suspicious process attempting to terminate + the Lsass.exe process. It leverages Sysmon EventCode 10 logs to identify processes + granted PROCESS_TERMINATE access to Lsass.exe. This activity is significant because + Lsass.exe is a critical process responsible for enforcing security policies and + handling user credentials. If confirmed malicious, this behavior could indicate + an attempt to perform credential dumping, privilege escalation, or evasion of security + policies, potentially leading to unauthorized access and persistence within the + environment. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe GrantedAccess = 0x1 | stats count min(_time) as firstTime max(_time) as lastTime by SourceImage, TargetImage, - TargetProcessId, SourceProcessId, GrantedAccess CallTrace, dest | rename dest - as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + TargetProcessId, SourceProcessId, GrantedAccess CallTrace, dest | rename dest as + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_terminating_lsass_process_filter`' how_to_implement: This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. @@ -70,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/doublezero_wiper/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/doublezero_wiper/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_time_based_evasion.yml b/detections/endpoint/windows_time_based_evasion.yml index 7e4c22e9cd..66c6773554 100644 --- a/detections/endpoint/windows_time_based_evasion.yml +++ b/detections/endpoint/windows_time_based_evasion.yml @@ -1,23 +1,26 @@ name: Windows Time Based Evasion id: 34502357-deb1-499a-8261-ffe144abf561 -version: 1 -date: '2023-09-08' +version: 2 +date: '2024-05-24' author: Teoderick Contreras, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: This analytic is designed to detect potentially malicious processes that initiate a ping delay using an invalid IP address. - This evasion technique was observed in NJRAT, where the malware employed ping commands as a means to introduce a time delay before self-deletion on the compromised host. - Identifying this (TTP) behavior can serve as a valuable indicator for detecting NJRAT infections or other malware that employ time delays as - evasion tactics. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name = "ping.exe" Processes.parent_process = "* ping 0 -n *" OR Processes.process = "* ping 0 -n *" - by Processes.parent_process Processes.process_name Processes.process_id Processes.process_guid Processes.process Processes.user Processes.dest - | `drop_dm_object_name("Processes")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_time_based_evasion_filter`' +description: The following analytic detects potentially malicious processes that initiate + a ping delay using an invalid IP address. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions involving "ping 0 + -n". This behavior is significant as it is commonly used by malware like NJRAT to + introduce time delays for evasion tactics, such as delaying self-deletion. If confirmed + malicious, this activity could indicate an active infection attempting to evade + detection, potentially leading to further compromise and persistence within the + environment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name = "ping.exe" + Processes.parent_process = "* ping 0 -n *" OR Processes.process = "* ping 0 -n *" + by Processes.parent_process Processes.process_name Processes.process_id Processes.process_guid + Processes.process Processes.user Processes.dest | `drop_dm_object_name("Processes")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_time_based_evasion_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -64,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/njrat_ping_delay_before_delete/ping_0.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/njrat_ping_delay_before_delete/ping_0.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_time_based_evasion_via_choice_exec.yml b/detections/endpoint/windows_time_based_evasion_via_choice_exec.yml index 205de10bc1..4b780c85e4 100644 --- a/detections/endpoint/windows_time_based_evasion_via_choice_exec.yml +++ b/detections/endpoint/windows_time_based_evasion_via_choice_exec.yml @@ -1,23 +1,26 @@ name: Windows Time Based Evasion via Choice Exec id: d5f54b38-10bf-4b3a-b6fc-85949862ed50 -version: 1 -date: '2024-02-14' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 1 -description: This analytic is designed to detect potentially suspicious batch files that leverage choice.exe as a delay tactic. - This technique, observed in the SnakeKeylogger malware, is utilized for time delays or 'Sleep' commands in its code execution - or before the deletion of its copies on compromised hosts. Detecting this anomaly serves as a valuable pivot to uncover - suspicious processes attempting to evade detection through time-based evasion techniques. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes - where Processes.process_name =choice.exe Processes.process = "*/T*" Processes.process = "*/N*" - by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid Processes.dest Processes.user - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_time_based_evasion_via_choice_exec_filter`' +description: The following analytic detects the use of choice.exe in batch files as + a delay tactic, a technique observed in SnakeKeylogger malware. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process names and + command-line executions. This activity is significant as it indicates potential + time-based evasion techniques used by malware to avoid detection. If confirmed malicious, + this behavior could allow attackers to execute code stealthily, delete malicious + files, and persist on compromised hosts, making it crucial for SOC analysts to investigate + promptly. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name =choice.exe Processes.process + = "*/T*" Processes.process = "*/N*" by Processes.parent_process_name Processes.process_name + Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid + Processes.dest Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_time_based_evasion_via_choice_exec_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -27,8 +30,8 @@ how_to_implement: The detection is based on data that originates from Endpoint D the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: administrator may use choice.exe to allow user to choose from and indexes of choices from a batch - script. +known_false_positives: administrator may use choice.exe to allow user to choose from + and indexes of choices from a batch script. references: - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/choice - https://malpedia.caad.fkie.fraunhofer.de/details/win.404keylogger @@ -66,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/time_delay_using_choice_exe/snakekeylogger_choice.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1497.003/time_delay_using_choice_exe/snakekeylogger_choice.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml b/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml index 08b19ede05..bdc5625734 100644 --- a/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml +++ b/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml @@ -1,21 +1,34 @@ name: Windows UAC Bypass Suspicious Child Process id: 453a6b0f-b0ea-48fa-9cf4-20537ffdd22c -version: 1 -date: '2023-11-20' +version: 2 +date: '2024-05-22' author: Steven Dick status: production type: TTP -description: The following analytic detects when an executable known for User Account Control bypass exploitation, spawns a child process in user controlled location or a command shell executable (cmd, powershell, etc). This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges. +description: The following analytic detects when an executable known for User Account + Control (UAC) bypass exploitation spawns a child process in a user-controlled location + or a command shell executable (e.g., cmd.exe, powershell.exe). This detection leverages + Sysmon Event ID 1 data, focusing on high or system integrity level processes with + specific parent-child process relationships. This activity is significant as it + may indicate an attacker has successfully used a UAC bypass exploit to escalate + privileges. If confirmed malicious, this could allow the attacker to execute arbitrary + commands with elevated privileges, potentially compromising the entire system. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("high","system") AND Processes.parent_process_name IN (`uacbypass_process_name`) AND (Processes.process_name IN ("cmd.exe","powershell.exe","pwsh.exe","wscript","cscript.exe","bash.exe","werfault.exe") OR Processes.process IN ("*\\\\*","*\\Users\\*","*\\ProgramData\\*","*\\Temp\\*")) by Processes.dest, Processes.user, Processes.parent_process_guid, Processes.parent_process, Processes.parent_process_name Processes.process_name Processes.process, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory - | `drop_dm_object_name(Processes)` - | where parent_process_name != process_name - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_uac_bypass_suspicious_child_process_filter`' -how_to_implement: Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data. -known_false_positives: Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_integrity_level + IN ("high","system") AND Processes.parent_process_name IN (`uacbypass_process_name`) + AND (Processes.process_name IN ("cmd.exe","powershell.exe","pwsh.exe","wscript","cscript.exe","bash.exe","werfault.exe") + OR Processes.process IN ("*\\\\*","*\\Users\\*","*\\ProgramData\\*","*\\Temp\\*")) + by Processes.dest, Processes.user, Processes.parent_process_guid, Processes.parent_process, + Processes.parent_process_name Processes.process_name Processes.process, Processes.process_path, + Processes.process_integrity_level, Processes.process_current_directory | `drop_dm_object_name(Processes)` + | where parent_process_name != process_name | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_uac_bypass_suspicious_child_process_filter`' +how_to_implement: Target environment must ingest sysmon data, specifically Event ID + 1 with process integrity level data. +known_false_positives: Including Werfault.exe may cause some unintended false positives + related to normal application faulting, but is used in a number of UAC bypass techniques. references: - https://attack.mitre.org/techniques/T1548/002/ - https://atomicredteam.io/defense-evasion/T1548.002/ @@ -28,7 +41,8 @@ tags: asset_type: Endpoint confidence: 75 impact: 60 - message: A UAC bypass parent process- $parent_process_name$ on host- $dest$ launched a suspicious child process - $process_name$. + message: A UAC bypass parent process- $parent_process_name$ on host- $dest$ launched + a suspicious child process - $process_name$. mitre_attack_id: - T1548 - T1548.002 @@ -64,7 +78,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/uac_behavior/uac_behavior_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/uac_behavior/uac_behavior_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml b/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml index b77e64ea20..7f18816f7f 100644 --- a/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml +++ b/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml @@ -1,33 +1,46 @@ name: Windows UAC Bypass Suspicious Escalation Behavior id: 00d050d3-a5b4-4565-a6a5-a31f69681dc3 -version: 1 -date: '2023-11-20' +version: 2 +date: '2024-05-27' author: Steven Dick status: production type: TTP -description: The following analytic detects when a process spawns an executable known for User Account Control bypass exploitation, and then monitors for any subsequent child processes that are above the integrity level of the original spawning process. This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges. +description: The following analytic detects when a process spawns an executable known + for User Account Control (UAC) bypass exploitation and subsequently monitors for + any child processes with a higher integrity level than the original process. This + detection leverages Sysmon Event ID 1 data, focusing on process integrity levels + and known UAC bypass executables. This activity is significant as it may indicate + an attacker has successfully used a UAC bypass exploit to escalate privileges. If + confirmed malicious, the attacker could gain elevated privileges, potentially leading + to further system compromise and persistent access. data_source: - Sysmon EventID 1 -search: '| tstats `security_content_summariesonly` count max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("low","medium") by Processes.dest, Processes.user, Processes.process_name, Processes.process, Processes.process_guid, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory - | `drop_dm_object_name(Processes)` - | eval original_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) - | rename process_guid as join_guid_1, process* as parent_process* - | join max=0 dest join_guid_1 - [| tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("high","system") AND Processes.process_name IN (`uacbypass_process_name`) by Processes.dest, Processes.parent_process_guid, Processes.process_name, Processes.process_guid - | `drop_dm_object_name(Processes)` - | rename parent_process_guid as join_guid_1, process_guid as join_guid_2, process_name as uac_process_name ] - | join max=0 dest join_guid_2 - [| tstats `security_content_summariesonly` count min(_time) as firstTime from datamodel=Endpoint.Processes where Processes.parent_process_name IN (`uacbypass_process_name`) AND Processes.process_integrity_level IN ("high","system") by Processes.dest, Processes.parent_process_guid, Processes.process_name, Processes.process, Processes.process_guid, Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory - | `drop_dm_object_name(Processes)` - | rename parent_process_guid as join_guid_2 - | eval elevated_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0)] - | where elevated_integrity_level > original_integrity_level - | table dest user parent_process parent_process_name parent_process_integrity_level process_integrity_level process process_name uac_process_name count firstTime lastTime - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_uac_bypass_suspicious_escalation_behavior_filter`' -how_to_implement: Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data. -known_false_positives: Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques. +search: '| tstats `security_content_summariesonly` count max(_time) as lastTime from + datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("low","medium") + by Processes.dest, Processes.user, Processes.process_name, Processes.process, Processes.process_guid, + Processes.process_path, Processes.process_integrity_level, Processes.process_current_directory + | `drop_dm_object_name(Processes)` | eval original_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0) + | rename process_guid as join_guid_1, process* as parent_process* | join max=0 dest + join_guid_1 [| tstats `security_content_summariesonly` count min(_time) as firstTime + from datamodel=Endpoint.Processes where Processes.process_integrity_level IN ("high","system") + AND Processes.process_name IN (`uacbypass_process_name`) by Processes.dest, Processes.parent_process_guid, + Processes.process_name, Processes.process_guid | `drop_dm_object_name(Processes)` + | rename parent_process_guid as join_guid_1, process_guid as join_guid_2, process_name + as uac_process_name ] | join max=0 dest join_guid_2 [| tstats `security_content_summariesonly` + count min(_time) as firstTime from datamodel=Endpoint.Processes where Processes.parent_process_name + IN (`uacbypass_process_name`) AND Processes.process_integrity_level IN ("high","system") + by Processes.dest, Processes.parent_process_guid, Processes.process_name, Processes.process, + Processes.process_guid, Processes.process_path, Processes.process_integrity_level, + Processes.process_current_directory | `drop_dm_object_name(Processes)` | rename + parent_process_guid as join_guid_2 | eval elevated_integrity_level = CASE(match(process_integrity_level,"low"),1,match(process_integrity_level,"medium"),2,match(process_integrity_level,"high"),3,match(process_integrity_level,"system"),4,true(),0)] + | where elevated_integrity_level > original_integrity_level | table dest user parent_process + parent_process_name parent_process_integrity_level process_integrity_level process + process_name uac_process_name count firstTime lastTime | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_uac_bypass_suspicious_escalation_behavior_filter`' +how_to_implement: Target environment must ingest sysmon data, specifically Event ID + 1 with process integrity level data. +known_false_positives: Including Werfault.exe may cause some unintended false positives + related to normal application faulting, but is used in a number of UAC bypass techniques. references: - https://attack.mitre.org/techniques/T1548/002/ - https://atomicredteam.io/defense-evasion/T1548.002/ @@ -40,7 +53,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 80 - message: A UAC bypass behavior was detected by parent process name- $parent_process_name$ on host $dest$ by $user$. + message: A UAC bypass behavior was detected by parent process name- $parent_process_name$ + on host $dest$ by $user$. mitre_attack_id: - T1548 - T1548.002 @@ -84,7 +98,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/uac_behavior/uac_behavior_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/uac_behavior/uac_behavior_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: XmlWinEventLog update_timestamp: true diff --git a/detections/endpoint/windows_unsecured_outlook_credentials_access_in_registry.yml b/detections/endpoint/windows_unsecured_outlook_credentials_access_in_registry.yml index 4b60c78516..c482f4cee1 100644 --- a/detections/endpoint/windows_unsecured_outlook_credentials_access_in_registry.yml +++ b/detections/endpoint/windows_unsecured_outlook_credentials_access_in_registry.yml @@ -1,23 +1,25 @@ name: Windows Unsecured Outlook Credentials Access In Registry id: 36334123-077d-47a2-b70c-6c7b3cc85049 -version: 1 -date: '2024-02-14' +version: 2 +date: '2024-05-22' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Windows Event Log Security 4663 -description: The following analytic identifies a suspicious query on outlook credentials registry in Windows OS registry. - typically refers to user profiles associated with Microsoft Outlook. Within this key, Outlook stores configuration settings, - including account information such as email addresses, server details, and authentication credentials. Accessing or modifying - this registry key can potentially compromise users' email security, making it a target for attackers seeking to steal sensitive - information or execute unauthorized actions within Outlook. This anomaly detection is a good pivot to catch possible Trojan Stealer or RAT - that tries to steal sensitive information to its targeted host. -search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\Profiles\\Outlook\\9375CFF0413111d3B88A00104B2A6676*", "*\\Windows Messaging Subsystem\\Profiles\\9375CFF0413111d3B88A00104B2A6676*") - AND process_name != *\\outlook.exe - | stats count min(_time) as firstTime max(_time) as lastTime by object_file_name object_file_path process_name process_path process_id EventCode dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects unauthorized access to Outlook credentials + stored in the Windows registry. It leverages Windows Security Event logs, specifically + EventCode 4663, to identify access attempts to registry paths associated with Outlook + profiles. This activity is significant as it may indicate attempts to steal sensitive + email credentials, which could lead to unauthorized access to email accounts. If + confirmed malicious, this could allow attackers to exfiltrate sensitive information, + impersonate users, or execute further unauthorized actions within Outlook, posing + a significant security risk. +search: '`wineventlog_security` EventCode=4663 object_file_path IN ("*\\Profiles\\Outlook\\9375CFF0413111d3B88A00104B2A6676*", + "*\\Windows Messaging Subsystem\\Profiles\\9375CFF0413111d3B88A00104B2A6676*") AND + process_name != *\\outlook.exe | stats count min(_time) as firstTime max(_time) + as lastTime by object_file_name object_file_path process_name process_path process_id + EventCode dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_unsecured_outlook_credentials_access_in_registry_filter`' how_to_implement: To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in @@ -32,7 +34,8 @@ tags: asset_type: Endpoint confidence: 70 impact: 70 - message: A suspicious process $process_name$ accessing outlook credentials registry on $dest$ + message: A suspicious process $process_name$ accessing outlook credentials registry + on $dest$ mitre_attack_id: - T1552 observable: @@ -58,6 +61,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552/snakey_keylogger_outlook_reg_access/snakekeylogger_4663.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/windows_unsigned_dll_side_loading.yml b/detections/endpoint/windows_unsigned_dll_side_loading.yml index e864d90ae8..0217eacff5 100644 --- a/detections/endpoint/windows_unsigned_dll_side_loading.yml +++ b/detections/endpoint/windows_unsigned_dll_side_loading.yml @@ -1,29 +1,30 @@ name: Windows Unsigned DLL Side-Loading id: 5a83ce44-8e0f-4786-a775-8249a525c879 -version: 1 -date: '2023-07-26' +version: 2 +date: '2024-05-31' author: Teoderick Contreras, Splunk status: production type: Anomaly data_source: - Sysmon EventID 7 -description: This analytic focuses on detecting potentially malicious unsigned DLLs created in either the c:\windows\system32 or c:\windows\syswow64 folders. - This particular technique was observed in the context of the Warzone (Ave Maria) RAT, where it employed a method known as DLL hijacking (dll-side-loading) - by dropping the "dismcore.dll" to achieve privilege escalation. - DLL hijacking is a stealthy attack technique used by cybercriminals to exploit the way Windows searches and loads DLLs. By placing a malicious DLL with the - same name as one that a legitimate application is expected to load, the attacker can gain unauthorized access and execute malicious code. - In the case of Warzone RAT (Ave Maria), the dropped "dismcore.dll" was intended to deceive the system into loading the rogue DLL instead of the legitimate version, - thereby granting the malware elevated privileges and enabling further compromise of the target system. - Detecting such suspicious DLLs is crucial in preventing privilege escalation attacks and other potential security breaches. Regular security assessments, thorough monitoring, - and implementing security best practices are essential in safeguarding systems from such threats. -search: '`sysmon` EventCode=7 Signed=false OriginalFileName = "-" SignatureStatus="unavailable" ImageLoaded IN ("*:\\windows\\system32\\*", "*:\\windows\\syswow64\\*") - | stats count min(_time) as firstTime max(_time) as lastTime by Image ImageLoaded Signed SignatureStatus OriginalFileName process_name dest EventCode ProcessId Hashes IMPHASH - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_unsigned_dll_side_loading_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. - If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: It is possible some Administrative utilities will load dismcore.dll outside of normal system paths, filter as needed. +description: The following analytic detects the creation of potentially malicious + unsigned DLLs in the c:\windows\system32 or c:\windows\syswow64 folders. It leverages + Sysmon EventCode 7 logs to identify unsigned DLLs with unavailable signatures loaded + in these critical directories. This activity is significant as it may indicate a + DLL hijacking attempt, a technique used by attackers to gain unauthorized access + and execute malicious code. If confirmed malicious, this could lead to privilege + escalation, allowing the attacker to gain elevated privileges and further compromise + the target system. +search: '`sysmon` EventCode=7 Signed=false OriginalFileName = "-" SignatureStatus="unavailable" + ImageLoaded IN ("*:\\windows\\system32\\*", "*:\\windows\\syswow64\\*") | stats + count min(_time) as firstTime max(_time) as lastTime by Image ImageLoaded Signed + SignatureStatus OriginalFileName process_name dest EventCode ProcessId Hashes IMPHASH + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_unsigned_dll_side_loading_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + logs with the process name and imageloaded executions from your endpoints. If you + are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. +known_false_positives: It is possible some Administrative utilities will load dismcore.dll + outside of normal system paths, filter as needed. references: - https://asec.ahnlab.com/en/17692/ - https://www.blackberry.com/us/en/solutions/endpoint-security/ransomware-protection/warzone#:~:text=Warzone%20RAT%20(AKA%20Ave%20Maria)%20is%20a%20remote%20access%20trojan,is%20as%20an%20information%20stealer. @@ -49,21 +50,22 @@ tags: risk_score: 49 required_fields: - _time - - Image - - ImageLoaded - - Signed - - SignatureStatus - - OriginalFileName - - process_name - - dest - - EventCode - - ProcessId - - Hashes - - IMPHASH + - Image + - ImageLoaded + - Signed + - SignatureStatus + - OriginalFileName + - process_name + - dest + - EventCode + - ProcessId + - Hashes + - IMPHASH security_domain: endpoint tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/unsigned_dll_loaded/loaded_unsigned_dll.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/warzone_rat/unsigned_dll_loaded/loaded_unsigned_dll.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_unsigned_dll_side_loading_in_same_process_path.yml b/detections/endpoint/windows_unsigned_dll_side_loading_in_same_process_path.yml new file mode 100644 index 0000000000..67361645f1 --- /dev/null +++ b/detections/endpoint/windows_unsigned_dll_side_loading_in_same_process_path.yml @@ -0,0 +1,69 @@ +name: Windows Unsigned DLL Side-Loading In Same Process Path +id: 3cf85c02-f9d6-4186-bf3c-e70ee99fbc7f +version: 1 +date: '2024-06-07' +author: Teoderick Contreras, Splunk +data_source: +- Sysmon Event ID 7 +type: TTP +status: production +description: This detection identifies unsigned DLLs loaded through DLL side-loading with same file path with the process loaded the DLL, a technique observed in DarkGate malware. + This detection monitors DLL loading, verifies signatures, and flags unsigned DLLs. Suspicious file paths and known executable + associations are checked. Detecting such suspicious DLLs is crucial in preventing privilege escalation attacks and other potential security breaches. Regular security assessments, thorough monitoring, + and implementing security best practices are essential in safeguarding systems from such threats. +search: '`sysmon` EventCode=7 Signed=false SignatureStatus != Valid NOT (Image IN ("*:\\windows\\system32\\*", "*:\\windows\\syswow64\\*", "c:\\Program Files*")) NOT (ImageLoaded IN ("*:\\windows\\system32\\*", "*:\\windows\\syswow64\\*", "c:\\Program Files*")) + | rex field=Image "(?.+\\\)" + | rex field=ImageLoaded "(?.+\\\)" + | where ImageFolderPath = ImageLoadedFolderPath + | stats count min(_time) as firstTime max(_time) as lastTime by Image ProcessGuid ImageLoaded user Computer EventCode ImageFolderPath ImageLoadedFolderPath Company Description Product Signed SignatureStatus + | rename Computer as dest + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `windows_unsigned_dll_side_loading_in_same_process_path_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. + If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. +known_false_positives: unknown +references: +- https://www.splunk.com/en_us/blog/security/enter-the-gates-an-analysis-of-the-darkgate-autoit-loader.html +- https://www.trendmicro.com/en_us/research/23/b/investigating-the-plugx-trojan-disguised-as-a-legitimate-windows.html +tags: + analytic_story: + - DarkGate Malware + - PlugX + asset_type: Endpoint + confidence: 70 + impact: 70 + message: An unsigned dll module was loaded on $dest$ + mitre_attack_id: + - T1574.002 + - T1574 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 49 + required_fields: + - _time + - Image + - ImageLoaded + - Signed + - SignatureStatus + - OriginalFileName + - process_name + - dest + - EventCode + - ProcessId + - Hashes + - IMPHASH + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/unsigned_dll_loaded_same_process_path/unsigned_dll_process_path.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_unsigned_ms_dll_side_loading.yml b/detections/endpoint/windows_unsigned_ms_dll_side_loading.yml index 44a7ee83e7..5ac3b46ab7 100644 --- a/detections/endpoint/windows_unsigned_ms_dll_side_loading.yml +++ b/detections/endpoint/windows_unsigned_ms_dll_side_loading.yml @@ -1,40 +1,40 @@ name: Windows Unsigned MS DLL Side-Loading id: 8d9e0e06-ba71-4dc5-be16-c1a46d58728c -version: 1 -date: '2024-04-05' +version: 2 +date: '2024-05-27' author: Teoderick Contreras, Splunk data_source: - Sysmon Event ID 7 type: Anomaly status: production -description: The following analysis identifies potential DLL side-loading instances involving unsigned DLLs with - a company detail signature mimicking Microsoft. This technique is frequently exploited by adversaries to execute - malicious code automatically by running a legitimate process. The analytics involves searching Sysmon logs for Event Code 7, - where both the `Image` and `ImageLoaded` paths do not match system directories (`system32`, `syswow64`, and `programfiles`). - Additionally, it verifies whether the loaded DLL is signed and checks if the folder paths of the `Image` and `ImageLoaded` are identical. - This anomaly detection mechanism serves as a valuable indicator for identifying suspicious processes that load unsigned DLLs. Add other paths based on org hunting. -search: '`sysmon` EventCode=7 Company="Microsoft Corporation" Signed=false SignatureStatus != Valid - NOT (Image IN("C:\\Windows\\System32\\*", "C:\\Windows\\SysWow64\\*", "C:\\Program Files*")) - NOT (ImageLoaded IN("C:\\Windows\\System32\\*", "C:\\Windows\\SysWow64\\*", "C:\\Program Files*")) - | rex field=Image "(?.+\\\)" - | rex field=ImageLoaded "(?.+\\\)" - | where ImageFolderPath = ImageLoadedFolderPath - | stats count min(_time) as firstTime max(_time) as lastTime by Image ProcessGuid ImageLoaded user Computer EventCode ImageFolderPath ImageLoadedFolderPath Company Description Product Signed SignatureStatus - | rename Computer as dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `windows_unsigned_ms_dll_side_loading_filter`' +description: The following analytic identifies potential DLL side-loading instances + involving unsigned DLLs mimicking Microsoft signatures. It detects this activity + by analyzing Sysmon logs for Event Code 7, where both the `Image` and `ImageLoaded` + paths do not match system directories like `system32`, `syswow64`, and `programfiles`. + This behavior is significant as adversaries often exploit DLL side-loading to execute + malicious code via legitimate processes. If confirmed malicious, this activity could + allow attackers to execute arbitrary code, potentially leading to privilege escalation, + persistence, and unauthorized access to sensitive information. +search: '`sysmon` EventCode=7 Company="Microsoft Corporation" Signed=false SignatureStatus + != Valid NOT (Image IN("C:\\Windows\\System32\\*", "C:\\Windows\\SysWow64\\*", "C:\\Program + Files*")) NOT (ImageLoaded IN("C:\\Windows\\System32\\*", "C:\\Windows\\SysWow64\\*", + "C:\\Program Files*")) | rex field=Image "(?.+\\\)" | rex field=ImageLoaded + "(?.+\\\)" | where ImageFolderPath = ImageLoadedFolderPath + | stats count min(_time) as firstTime max(_time) as lastTime by Image ProcessGuid + ImageLoaded user Computer EventCode ImageFolderPath ImageLoadedFolderPath Company + Description Product Signed SignatureStatus | rename Computer as dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_unsigned_ms_dll_side_loading_filter`' how_to_implement: The analytic is designed to be run against Sysmon event logs collected - from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. - The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe - and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate - loading of vcruntime140.dll from the System32 directory to reduce false positives. - The analytic can be modified to include additional known good paths for vcruntime140.dll - to further reduce false positives. + from endpoints. The analytic requires the Sysmon event logs to be ingested into + Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe + or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters + out the legitimate loading of vcruntime140.dll from the System32 directory to reduce + false positives. The analytic can be modified to include additional known good paths + for vcruntime140.dll to further reduce false positives. known_false_positives: False positives are possible if legitimate processes are loading - vcruntime140.dll from non-standard directories. It is recommended to investigate the - context of the process loading vcruntime140.dll to determine if it is malicious or - not. Modify the search to include additional known good paths for vcruntime140.dll + vcruntime140.dll from non-standard directories. It is recommended to investigate + the context of the process loading vcruntime140.dll to determine if it is malicious + or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives. references: - https://www.mandiant.com/resources/blog/apt29-wineloader-german-political-parties @@ -78,6 +78,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/unsigned_dll_load//wineloader_dll_sideload.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.002/unsigned_dll_load//wineloader_dll_sideload.log sourcetype: xmlwineventlog source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational diff --git a/detections/endpoint/windows_unusual_count_of_disabled_users_failed_auth_using_kerberos.yml b/detections/endpoint/windows_unusual_count_of_disabled_users_failed_auth_using_kerberos.yml index fc17d42212..c35ac5aff3 100644 --- a/detections/endpoint/windows_unusual_count_of_disabled_users_failed_auth_using_kerberos.yml +++ b/detections/endpoint/windows_unusual_count_of_disabled_users_failed_auth_using_kerberos.yml @@ -1,28 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4768 -date: '2022-09-22' -description: 'The following analytic identifies one source endpoint failing to authenticate - with multiple disabled domain users using the Kerberos protocol. This behavior could - represent an adversary performing a Password Spraying attack against an Active Directory - environment using Kerberos to obtain initial access or elevate privileges. As attackers - progress in a breach, mistakes will be made. In certain scenarios, adversaries may - execute a password spraying attack against disabled users. Event 4768 is generated - every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket - (TGT). Failure code `0x12` stands for `clients credentials have been revoked` (account - disabled, expired or locked out). - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on domain controllers, not on member servers or - workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' +date: '2024-05-25' +description: 'The following analytic identifies a source endpoint failing to authenticate + with multiple disabled domain users using the Kerberos protocol. It leverages EventCode + 4768, which is generated when the Key Distribution Center issues a Kerberos Ticket + Granting Ticket (TGT) and detects failure code `0x12` (credentials revoked). This + behavior is significant as it may indicate a Password Spraying attack targeting + disabled accounts, potentially leading to initial access or privilege escalation. + If confirmed malicious, attackers could gain unauthorized access or elevate privileges + within the Active Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -39,7 +26,7 @@ search: '`wineventlog_security` EventCode=4768 TargetUserName!=*$ Status=0x12 | as user by _time, IpAddress | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by IpAddress | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 | `windows_unusual_count_of_disabled_users_failed_auth_using_kerberos_filter` ' + | search isOutlier=1 | `windows_unusual_count_of_disabled_users_failed_auth_using_kerberos_filter`' status: production tags: analytic_story: @@ -76,9 +63,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_disabled_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_disabled_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos.yml b/detections/endpoint/windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos.yml index ebc5ba53b2..73c8ec95b0 100644 --- a/detections/endpoint/windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos.yml +++ b/detections/endpoint/windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos.yml @@ -1,28 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4768 -date: '2022-09-22' -description: 'The following analytic identifies one source endpoint failing to authenticate - with multiple invalid domain users using the Kerberos protocol. This behavior could - represent an adversary performing a Password Spraying attack against an Active Directory - environment using Kerberos to obtain initial access or elevate privileges. As attackers - progress in a breach, mistakes will be made. In certain scenarios, adversaries may - execute a password spraying attack using an invalid list of users. Event 4768 is - generated every time the Key Distribution Center issues a Kerberos Ticket Granting - Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` - (the attempted user is not a valid domain user). - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on domain controllers, not on member servers or - workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' +date: '2024-05-31' +description: 'The following analytic identifies a source endpoint failing to authenticate + with multiple invalid domain users using the Kerberos protocol. It leverages Event + ID 4768, which is generated when the Key Distribution Center issues a Kerberos Ticket + Granting Ticket (TGT) and detects failure code 0x6, indicating the user is not found + in the Kerberos database. This behavior is significant as it may indicate a Password + Spraying attack, where an adversary attempts to gain initial access or elevate privileges. + If confirmed malicious, this activity could lead to unauthorized access and potential + privilege escalation within the Active Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -39,7 +26,7 @@ search: '`wineventlog_security` EventCode=4768 TargetUserName!=*$ Status=0x6 | b as user by _time, IpAddress | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by IpAddress | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 | `windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos_filter` ' + | search isOutlier=1 | `windows_unusual_count_of_invalid_users_fail_to_auth_using_kerberos_filter`' status: production tags: analytic_story: @@ -76,9 +63,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm.yml b/detections/endpoint/windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm.yml index 8294f2b9aa..7a5203e123 100644 --- a/detections/endpoint/windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm.yml +++ b/detections/endpoint/windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm.yml @@ -1,29 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4776 -date: '2022-09-22' -description: 'The following analytic identifies one source endpoint failing to authenticate - with multiple invalid users using the NTLM protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using NTLM to obtain initial access or elevate privileges. As attackers progress - in a breach, mistakes will be made. In certain scenarios, adversaries may execute - a password spraying attack using an invalid list of users. Event 4776 is generated - on the computer that is authoritative for the provided credentials. For domain accounts, - the domain controller is authoritative. For local accounts, the local computer is - authoritative. Error code 0xC0000064 stands for `The username you typed does not - exist` (the attempted user is a legitimate domain user). - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on domain controllers, not on member servers or - workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source workstation name and attempted user accounts.' +date: '2024-05-19' +description: 'The following analytic identifies a source endpoint failing to authenticate + with multiple invalid users using the NTLM protocol. It leverages EventCode 4776 + and calculates the standard deviation for each host, using the 3-sigma rule to detect + anomalies. This behavior is significant as it may indicate a Password Spraying attack, + where an adversary attempts to gain initial access or elevate privileges. If confirmed + malicious, this activity could lead to unauthorized access or privilege escalation, + posing a significant threat to the Active Directory environment. This detection + is focused on domain controllers.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled. @@ -40,12 +26,10 @@ references: - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4776 search: ' `wineventlog_security` EventCode=4776 TargetUserName!=*$ Status=0xc0000064 | bucket span=2m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) - as user by _time, Workstation | eventstats avg(unique_accounts) as comp_avg - , stdev(unique_accounts) as comp_std by Workstation | eval upperBound=(comp_avg+comp_std*3) - | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 - | rename Workstation as src - |`windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm_filter`' + as user by _time, Workstation | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) + as comp_std by Workstation | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts + > 10 and unique_accounts >= upperBound, 1, 0) | search isOutlier=1 | rename Workstation + as src |`windows_unusual_count_of_invalid_users_failed_to_auth_using_ntlm_filter`' status: production tags: analytic_story: @@ -81,9 +65,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_ntlm_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_invalid_users_ntlm_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials.yml b/detections/endpoint/windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials.yml index 657070e18e..458d7d8f5f 100644 --- a/detections/endpoint/windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials.yml +++ b/detections/endpoint/windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials.yml @@ -1,27 +1,14 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4648 -date: '2022-09-22' +date: '2024-05-14' description: 'The following analytic identifies a source user failing to authenticate - with multiple users using explicit credentials on a host. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - to obtain initial access or elevate privileges. Event 4648 is generated when a process - attempts an account logon by explicitly specifying that accounts credentials. This - event generates on domain controllers, member servers, and workstations. - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will trigger on the potenfially malicious host, perhaps controlled - via a trojan or operated by an insider threat, from where a password spraying attack - is being executed. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source account, attempted user accounts and the endpoint were - the behavior was identified.' + with multiple users using explicit credentials on a host. It leverages Windows Event + Code 4648 and calculates the standard deviation for each host, using the 3-sigma + rule to detect anomalies. This behavior is significant as it may indicate a Password + Spraying attack, where an adversary attempts to gain initial access or elevate privileges. + If confirmed malicious, this activity could lead to unauthorized access, privilege + escalation, or further compromise of the Active Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -42,7 +29,7 @@ search: ' `wineventlog_security` EventCode=4648 Caller_User_Name!=*$ Target_User as user by _time, Computer, Caller_User_Name | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by Computer | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 | `windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials_filter` ' + | search isOutlier=1 | `windows_unusual_count_of_users_fail_to_auth_wth_explicitcredentials_filter`' status: production tags: analytic_story: @@ -79,9 +66,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_explicit_credential_spray_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_explicit_credential_spray_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_users_failed_to_auth_using_kerberos.yml b/detections/endpoint/windows_unusual_count_of_users_failed_to_auth_using_kerberos.yml index f5cbd8d917..32184389f6 100644 --- a/detections/endpoint/windows_unusual_count_of_users_failed_to_auth_using_kerberos.yml +++ b/detections/endpoint/windows_unusual_count_of_users_failed_to_auth_using_kerberos.yml @@ -1,26 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4771 -date: '2022-09-22' -description: 'The following analytic identifies one source endpoint failing to authenticate - with multiple valid users using the Kerberos protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using Kerberos to obtain initial access or elevate privileges. Event 4771 is generated - when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket - (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted user - is a legitimate domain user). - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on domain controllers, not on member servers or - workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source ip and attempted user accounts.' +date: '2024-05-28' +description: 'The following analytic identifies a source endpoint failing to authenticate + multiple valid users using the Kerberos protocol, potentially indicating a Password + Spraying attack. It leverages Event 4771, which is generated when the Key Distribution + Center fails to issue a Kerberos Ticket Granting Ticket (TGT) due to a wrong password + (failure code 0x18). This detection uses statistical analysis, specifically the + 3-sigma rule, to identify unusual authentication failures. If confirmed malicious, + this activity could allow an attacker to gain initial access or elevate privileges + within an Active Directory environment.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. @@ -36,10 +25,9 @@ references: - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4771 search: '`wineventlog_security` EventCode=4771 TargetUserName!="*$" Status=0x18 | bucket span=5m _time | stats dc(TargetUserName) AS unique_accounts values(TargetUserName) - as user by _time, IpAddress | eventstats avg(unique_accounts) as comp_avg - , stdev(unique_accounts) as comp_std by IpAddress | eval upperBound=(comp_avg+comp_std*3) - | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 | `windows_unusual_count_of_users_failed_to_auth_using_kerberos_filter`' + as user by _time, IpAddress | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) + as comp_std by IpAddress | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts + > 10 and unique_accounts >= upperBound, 1, 0) | search isOutlier=1 | `windows_unusual_count_of_users_failed_to_auth_using_kerberos_filter`' status: production tags: analytic_story: @@ -76,9 +64,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_kerberos_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_kerberos_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_from_process.yml b/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_from_process.yml index c5df59c633..b9a9ff7198 100644 --- a/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_from_process.yml +++ b/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_from_process.yml @@ -1,27 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4625 -date: '2022-09-22' -description: 'The following analytic identifies a source process name failing to authenticate - with multiple users. This behavior could represent an adversary performing a Password - Spraying attack against an Active Directory environment to obtain initial access - or elevate privileges. Event 4625 generates on domain controllers, member servers, - and workstations when an account fails to logon. Logon Type 2 describes an iteractive - logon attempt. - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will trigger on the potenfially malicious host, perhaps controlled - via a trojan or operated by an insider threat, from where a password spraying attack - is being executed. This could be a domain controller as well as a member server - or workstation. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source process name, source account and attempted user accounts.' +date: '2024-05-21' +description: 'The following analytic identifies a source process failing to authenticate + multiple users, potentially indicating a Password Spraying attack. It leverages + Windows Event 4625, which logs failed logon attempts, and uses statistical analysis + to detect anomalies. This activity is significant as it may represent an adversary + attempting to gain initial access or elevate privileges within an Active Directory + environment. If confirmed malicious, the attacker could compromise multiple accounts, + leading to unauthorized access, data exfiltration, or further lateral movement within + the network.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -41,7 +29,7 @@ search: ' `wineventlog_security` EventCode=4625 Logon_Type=2 ProcessName!="-" | as user by _time, ProcessName, SubjectUserName, Computer | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by ProcessName, SubjectUserName, Computer | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts - > 10 and unique_accounts >= upperBound, 1, 0) | search isOutlier=1 | `windows_unusual_count_of_users_failed_to_authenticate_from_process_filter` ' + > 10 and unique_accounts >= upperBound, 1, 0) | search isOutlier=1 | `windows_unusual_count_of_users_failed_to_authenticate_from_process_filter`' status: production tags: analytic_story: @@ -80,9 +68,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_multiple_users_from_process_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_multiple_users_from_process_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_using_ntlm.yml b/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_using_ntlm.yml index 3cacce8ca3..48afd2bdfe 100644 --- a/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_using_ntlm.yml +++ b/detections/endpoint/windows_unusual_count_of_users_failed_to_authenticate_using_ntlm.yml @@ -1,27 +1,15 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4776 -date: '2022-09-22' -description: 'The following analytic identifies one source endpoint failing to authenticate - with multiple valid users using the NTLM protocol. This behavior could represent - an adversary performing a Password Spraying attack against an Active Directory environment - using NTLM to obtain initial access or elevate privileges. Event 4776 is generated - on the computer that is authoritative for the provided credentials. For domain accounts, - the domain controller is authoritative. For local accounts, the local computer is - authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted - user is a legitimate domain user). - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will only trigger on domain controllers, not on member servers or - workstations. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source workstation name and attempted user accounts.' +date: '2024-05-12' +description: 'The following analytic identifies a source endpoint failing to authenticate + multiple valid users using the NTLM protocol, potentially indicating a Password + Spraying attack. It leverages Event 4776 from Domain Controllers, calculating the + standard deviation for each host and applying the 3-sigma rule to detect anomalies. + This activity is significant as it may represent an adversary attempting to gain + initial access or elevate privileges. If confirmed malicious, the attacker could + compromise multiple accounts, leading to unauthorized access and potential lateral + movement within the network.' how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled. @@ -73,9 +61,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_ntlm_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_valid_users_ntlm_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_unusual_count_of_users_remotely_failed_to_auth_from_host.yml b/detections/endpoint/windows_unusual_count_of_users_remotely_failed_to_auth_from_host.yml index 7e6420cea9..8c07be7abd 100644 --- a/detections/endpoint/windows_unusual_count_of_users_remotely_failed_to_auth_from_host.yml +++ b/detections/endpoint/windows_unusual_count_of_users_remotely_failed_to_auth_from_host.yml @@ -1,26 +1,14 @@ author: Mauricio Velazco, Splunk data_source: - Windows Event Log Security 4625 -date: '2022-09-22' +date: '2024-05-18' description: 'The following analytic identifies a source host failing to authenticate - against a remote host with multiple users. This behavior could represent an adversary - performing a Password Spraying attack against an Active Directory environment to - obtain initial access or elevate privileges. Event 4625 documents each and every - failed attempt to logon to the local computer. This event generates on domain controllers, - member servers, and workstations. Logon Type 3 describes an remote authentication - attempt. - - The detection calculates the standard deviation for each host and leverages the - 3-sigma statistical rule to identify an unusual number of users. To customize this - analytic, users can try different combinations of the `bucket` span time and the - calculation of the `upperBound` field. This logic can be used for real time security - monitoring as well as threat hunting exercises. - - This detection will trigger on the host that is the target of the password spraying - attack. This could be a domain controller as well as a member server or workstation. - - The analytics returned fields allow analysts to investigate the event further by - providing fields like source process name, source account and attempted user accounts.' + against a remote host with multiple users, potentially indicating a Password Spraying + attack. It leverages Windows Event 4625 (failed logon attempts) and Logon Type 3 + (remote authentication) to detect this behavior. This activity is significant as + it may represent an adversary attempting to gain initial access or elevate privileges + within an Active Directory environment. If confirmed malicious, this could lead + to unauthorized access, privilege escalation, and further compromise of the network.' how_to_implement: To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs @@ -41,7 +29,7 @@ search: ' `wineventlog_security` EventCode=4625 Logon_Type=3 IpAddress!="-" | b as tried_accounts by _time, IpAddress, Computer | eventstats avg(unique_accounts) as comp_avg , stdev(unique_accounts) as comp_std by IpAddress, Computer | eval upperBound=(comp_avg+comp_std*3) | eval isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0) - | search isOutlier=1 | `windows_unusual_count_of_users_remotely_failed_to_auth_from_host_filter` ' + | search isOutlier=1 | `windows_unusual_count_of_users_remotely_failed_to_auth_from_host_filter`' status: production tags: analytic_story: @@ -74,9 +62,10 @@ tags: security_domain: endpoint tests: - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_remote_spray_xml/windows-security.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/purplesharp_remote_spray_xml/windows-security.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog name: True Positive Test type: Anomaly -version: 1 +version: 2 diff --git a/detections/endpoint/windows_user_execution_malicious_url_shortcut_file.yml b/detections/endpoint/windows_user_execution_malicious_url_shortcut_file.yml index 74d1239d7f..819ed666d4 100644 --- a/detections/endpoint/windows_user_execution_malicious_url_shortcut_file.yml +++ b/detections/endpoint/windows_user_execution_malicious_url_shortcut_file.yml @@ -1,17 +1,17 @@ name: Windows User Execution Malicious URL Shortcut File id: 5c7ee6ad-baf4-44fb-b2f0-0cfeddf82dbc -version: 1 -date: '2023-01-12' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic will identify suspicious creation of URL shortcut link - files. This technique was seen in CHAOS ransomware where it will drop this .url - link file in %startup% folder that contains the path of its malicious dropped file - to execute upon the reboot of the targeted host. The creation of this file can be - created by a normal application or software but it is a good practice to verify - this type of file specially the resource it tries to execute which is commonly a - website. +description: The following analytic detects the creation of suspicious URL shortcut + link files, often used by malware like CHAOS ransomware. It leverages the Endpoint.Filesystem + datamodel to identify .url files created outside standard directories, such as Program + Files. This activity is significant as it may indicate an attempt to execute malicious + code upon system reboot. If confirmed malicious, this could allow an attacker to + achieve persistence and execute harmful payloads, potentially leading to further + system compromise and data loss. data_source: - Sysmon EventID 11 search: '|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -67,7 +67,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/chaos_ransomware/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_valid_account_with_never_expires_password.yml b/detections/endpoint/windows_valid_account_with_never_expires_password.yml index bb90665866..8e84d9e45c 100644 --- a/detections/endpoint/windows_valid_account_with_never_expires_password.yml +++ b/detections/endpoint/windows_valid_account_with_never_expires_password.yml @@ -1,25 +1,27 @@ name: Windows Valid Account With Never Expires Password id: 73a931db-1830-48b3-8296-cd9cfa09c3c8 -version: 1 -date: '2022-06-23' +version: 2 +date: '2024-05-28' author: Teoderick Contreras, Splunk status: production type: TTP -description: The following analytic identifies net.exe updating user account policies - for password requirement with non-expiring password. This technique was seen in - several adversaries and malware like Azorult to maintain the foothold (persistence), - gaining privilege escalation, defense evasion and possible for lateral movement - for specific users or created user account on the targeted host. This TTP detections - is a good pivot to see further what other events that users executes on the machines. +description: The following analytic detects the use of net.exe to update user account + policies to set passwords as non-expiring. It leverages data from Endpoint Detection + and Response (EDR) agents, focusing on command-line executions involving "/maxpwage:unlimited". + This activity is significant as it can indicate an attempt to maintain persistence, + escalate privileges, evade defenses, or facilitate lateral movement. If confirmed + malicious, this behavior could allow an attacker to maintain long-term access to + compromised accounts, potentially leading to further exploitation and unauthorized + access to sensitive information. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_net` AND Processes.process="* accounts *" AND Processes.process="* - /maxpwage:unlimited" by Processes.dest Processes.user Processes.parent_process_name Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `windows_valid_account_with_never_expires_password_filter`' + /maxpwage:unlimited" by Processes.dest Processes.user Processes.parent_process_name + Processes.process_name Processes.original_file_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_valid_account_with_never_expires_password_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -71,7 +73,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/azorult/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_vulnerable_3cx_software.yml b/detections/endpoint/windows_vulnerable_3cx_software.yml index 8f19bb4cb2..7dccbaa56b 100644 --- a/detections/endpoint/windows_vulnerable_3cx_software.yml +++ b/detections/endpoint/windows_vulnerable_3cx_software.yml @@ -1,27 +1,35 @@ name: Windows Vulnerable 3CX Software id: f2cc1584-46ee-485b-b905-977c067f36de -version: 1 -date: '2023-03-30' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk type: TTP status: production data_source: - Sysmon EventID 1 -description: The following analytic leverages Sysmon, a powerful system monitoring and logging tool, to pinpoint instances of the 3CXDesktopApp.exe with a FileVersion of 18.12.x.Recently, 3CX has discovered a vulnerability specifically in versions 18.12.407 and 18.12.416 of the desktop app. -search: '`sysmon` (process_name=3CXDesktopApp.exe OR OriginalFileName=3CXDesktopApp.exe) FileVersion=18.12.* | stats count min(_time) as firstTime max(_time) as lastTime by dest, parent_process_name,process_name, OriginalFileName, CommandLine - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `windows_vulnerable_3cx_software_filter`' +description: The following analytic detects instances of the 3CXDesktopApp.exe with + a FileVersion of 18.12.x, leveraging Sysmon logs. This detection focuses on identifying + vulnerable versions 18.12.407 and 18.12.416 of the 3CX desktop app. Monitoring this + activity is crucial as these specific versions have known vulnerabilities that could + be exploited by attackers. If confirmed malicious, exploitation of this vulnerability + could lead to unauthorized access, code execution, or further compromise of the + affected system, posing significant security risks. +search: '`sysmon` (process_name=3CXDesktopApp.exe OR OriginalFileName=3CXDesktopApp.exe) FileVersion=18.12.* + | stats count min(_time) as firstTime max(_time) as lastTime by dest, parent_process_name,process_name, + OriginalFileName, CommandLine | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `windows_vulnerable_3cx_software_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: False positives may be present based on file version, modify the analytic to only look for version between 18.12.407 and 18.12.416 as needed. +known_false_positives: False positives may be present based on file version, modify + the analytic to only look for version between 18.12.407 and 18.12.416 as needed. references: - - https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/ - - https://www.cisa.gov/news-events/alerts/2023/03/30/supply-chain-attack-against-3cxdesktopapp - - https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/ - - https://www.3cx.com/community/threads/crowdstrike-endpoint-security-detection-re-3cx-desktop-app.119934/page-2#post-558898 - - https://www.3cx.com/community/threads/3cx-desktopapp-security-alert.119951/ +- https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/ +- https://www.cisa.gov/news-events/alerts/2023/03/30/supply-chain-attack-against-3cxdesktopapp +- https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/ +- https://www.3cx.com/community/threads/crowdstrike-endpoint-security-detection-re-3cx-desktop-app.119934/page-2#post-558898 +- https://www.3cx.com/community/threads/3cx-desktopapp-security-alert.119951/ tags: analytic_story: - 3CX Supply Chain Attack @@ -30,7 +38,8 @@ tags: cve: - CVE-2023-29059 impact: 100 - message: A known vulnerable instance of 3CX Software $process_name$ ran on $dest$, related to a supply chain attack. + message: A known vulnerable instance of 3CX Software $process_name$ ran on $dest$, + related to a supply chain attack. mitre_attack_id: - T1195.002 observable: @@ -59,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.002/3CX/3cx_windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.002/3CX/3cx_windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_vulnerable_driver_loaded.yml b/detections/endpoint/windows_vulnerable_driver_loaded.yml index 5ac379d1e3..c85fdcc548 100644 --- a/detections/endpoint/windows_vulnerable_driver_loaded.yml +++ b/detections/endpoint/windows_vulnerable_driver_loaded.yml @@ -1,17 +1,18 @@ name: Windows Vulnerable Driver Loaded id: a2b1f1ef-221f-4187-b2a4-d4b08ec745f4 version: 2 -date: "2022-12-12" +date: "2024-05-18" author: Michael Haag, Splunk status: experimental type: Hunting -description: - The following analytic utilizes a known list of vulnerable Windows drivers - to help defenders find potential persistence or privelege escalation via a vulnerable - driver. This analytic uses Sysmon EventCode 6, driver loading. A known gap with - this lookup is that it does not use the hash or known signer of the vulnerable driver - therefore it is up to the defender to identify version and signing info and confirm - it is a vulnerable driver. +description: The following analytic detects the loading of known vulnerable Windows + drivers, which may indicate potential persistence or privilege escalation attempts. + It leverages Sysmon EventCode 6 to identify driver loading events and cross-references + them with a list of vulnerable drivers. This activity is significant as attackers + often exploit vulnerable drivers to gain elevated privileges or maintain persistence + on a system. If confirmed malicious, this could allow attackers to execute arbitrary + code with high privileges, leading to further system compromise and potential data + exfiltration. data_source: - Sysmon EventID 6 search: @@ -19,60 +20,58 @@ search: max(_time) as lastTime count by dest ImageLoaded | lookup loldrivers driver_name AS ImageLoaded OUTPUT is_driver driver_description | search is_driver = TRUE | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_vulnerable_driver_loaded_filter`" -how_to_implement: - Sysmon collects driver loads via EventID 6, however you may modify +how_to_implement: Sysmon collects driver loads via EventID 6, however you may modify the query to utilize this lookup to identify potentially persistent drivers that are known to be vulnerable. -known_false_positives: - False positives will be present. Drill down into the driver +known_false_positives: False positives will be present. Drill down into the driver further by version number and cross reference by signer. Review the reference material in the lookup. In addition, modify the query to look within specific paths, which will remove a lot of "normal" drivers. references: - - https://github.com/SigmaHQ/sigma/blob/master/rules/windows/driver_load/driver_load_vuln_drivers_names.yml - - https://github.com/eclypsium/Screwed-Drivers/blob/master/DRIVERS.md - - https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules - - https://www.rapid7.com/blog/post/2021/12/13/driver-based-attacks-past-and-present/ - - https://github.com/jbaines-r7/dellicious - - https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md - - https://github.com/namazso/physmem_drivers - - https://github.com/stong/CVE-2020-15368 - - https://github.com/CaledoniaProject/drivers-binaries - - https://github.com/Chigusa0w0/AsusDriversPrivEscala - - https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/ - - https://eclypsium.com/2019/11/12/mother-of-all-drivers/ - - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37969 +- https://github.com/SigmaHQ/sigma/blob/master/rules/windows/driver_load/driver_load_vuln_drivers_names.yml +- https://github.com/eclypsium/Screwed-Drivers/blob/master/DRIVERS.md +- https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules +- https://www.rapid7.com/blog/post/2021/12/13/driver-based-attacks-past-and-present/ +- https://github.com/jbaines-r7/dellicious +- https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md +- https://github.com/namazso/physmem_drivers +- https://github.com/stong/CVE-2020-15368 +- https://github.com/CaledoniaProject/drivers-binaries +- https://github.com/Chigusa0w0/AsusDriversPrivEscala +- https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/ +- https://eclypsium.com/2019/11/12/mother-of-all-drivers/ +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37969 tags: analytic_story: - - Windows Drivers - - BlackByte Ransomware + - Windows Drivers + - BlackByte Ransomware asset_type: Endpoint confidence: 50 impact: 50 - message: - An process has loaded a possible vulnerable driver on $dest$. Review and + message: An process has loaded a possible vulnerable driver on $dest$. Review and escalate as needed. mitre_attack_id: - - T1543.003 + - T1543.003 observable: - - name: dest - type: Hostname - role: - - Victim + - name: dest + type: Hostname + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - dest - - ImageLoaded + - _time + - dest + - ImageLoaded risk_score: 25 security_domain: endpoint tests: - - name: True Positive Test - attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1014/windows-sysmon.log - source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: xmlwineventlog - update_timestamp: true +- name: True Positive Test + attack_data: + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1014/windows-sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog + update_timestamp: true diff --git a/detections/endpoint/windows_windbg_spawning_autoit3.yml b/detections/endpoint/windows_windbg_spawning_autoit3.yml index 4338649148..d9fca3e811 100644 --- a/detections/endpoint/windows_windbg_spawning_autoit3.yml +++ b/detections/endpoint/windows_windbg_spawning_autoit3.yml @@ -1,21 +1,39 @@ name: Windows WinDBG Spawning AutoIt3 id: 7aec015b-cd69-46c3-85ed-dac152056aa4 -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 -description: The following analytic identifies instances of the WinDBG process spawning AutoIt3. This behavior may indicate malicious activity as AutoIt3 is often used by threat actors for scripting malicious automation. The search specifically looks for instances where the parent process name is 'windbg.exe' and the process name is 'autoit3.exe' or 'autoit*.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=windbg.exe AND (Processes.process_name IN ("autoit3.exe", "autoit*.exe") OR Processes.original_file_name IN ("autoit3.exe", "autoit*.exe")) by Processes.dest, Processes.user, Processes.parent_process_name, Processes.process_name, Processes.original_file_name, Processes.process, Processes.process_id, Processes.parent_process_id - | `drop_dm_object_name(Processes)` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | eval matches_extension=if(match(process, "\\.(au3|a3x|exe|aut|aup)$"), "Yes", "No") - | search matches_extension="Yes" | `windows_windbg_spawning_autoit3_filter`' -how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: False positives will only be present if the WinDBG process legitimately spawns AutoIt3. Filter as needed. +description: The following analytic identifies instances of the WinDBG process spawning + AutoIt3. This behavior is detected by monitoring endpoint telemetry for processes + where 'windbg.exe' is the parent process and 'autoit3.exe' or similar is the child + process. This activity is significant because AutoIt3 is frequently used by threat + actors for scripting malicious automation, potentially indicating an ongoing attack. + If confirmed malicious, this could allow attackers to automate tasks, execute arbitrary + code, and further compromise the system, leading to data exfiltration or additional + malware deployment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=windbg.exe AND + (Processes.process_name IN ("autoit3.exe", "autoit*.exe") OR Processes.original_file_name + IN ("autoit3.exe", "autoit*.exe")) by Processes.dest, Processes.user, Processes.parent_process_name, + Processes.process_name, Processes.original_file_name, Processes.process, Processes.process_id, + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | eval matches_extension=if(match(process, + "\\.(au3|a3x|exe|aut|aup)$"), "Yes", "No") | search matches_extension="Yes" | `windows_windbg_spawning_autoit3_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: False positives will only be present if the WinDBG process + legitimately spawns AutoIt3. Filter as needed. references: - https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2023-10-25-IOCs-from-DarkGate-activity.txt tags: @@ -64,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/windbg_autoit.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059/autoit/windbg_autoit.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_winlogon_with_public_network_connection.yml b/detections/endpoint/windows_winlogon_with_public_network_connection.yml index b31dcd18d6..4917a62735 100644 --- a/detections/endpoint/windows_winlogon_with_public_network_connection.yml +++ b/detections/endpoint/windows_winlogon_with_public_network_connection.yml @@ -1,33 +1,21 @@ name: Windows WinLogon with Public Network Connection id: 65615b3a-62ea-4d65-bb9f-6f07c17df4ea -version: 2 -date: '2024-01-30' +version: 3 +date: '2024-05-23' author: Michael Haag, Splunk status: experimental type: Hunting data_source: - Sysmon EventID 1 - Sysmon EventID 3 -description: 'The following analytic is designed to detect anomalous behavior associated - with the BlackLotus Campaign, a sophisticated bootkit attack reported by ESET and - further investigated in a blog by Microsoft, which provided hunting queries for - security analysts. The primary focus of this analytic is to identify instances of - Winlogon.exe, a critical Windows process, connecting to public IP space, which is - indicative of potential malicious activity.\ The BlackLotus Campaign is a bootkit-based - attack that compromises system integrity by infecting the Master Boot Record (MBR) - and Volume Boot Record (VBR). This malware variant can bypass traditional security - measures, load before the operating system, and maintain persistence on the target - system. - - Winlogon.exe is a critical Windows process responsible for managing user logon and - logoff processes. Under normal circumstances, Winlogon.exe should not be connecting - to public IP addresses. However, if it does, it may indicate that the process has - been compromised as part of the BlackLotus Campaign or another malicious operation. - - This analytic monitors network connections made by Winlogon.exe and triggers an - alert if it detects connections to public IP space. By identifying such anomalous - behavior, security analysts can investigate further and respond swiftly to potential - threats.' +description: 'The following analytic detects instances of Winlogon.exe, a critical + Windows process, connecting to public IP addresses. This behavior is identified + using Endpoint Detection and Response (EDR) telemetry, focusing on network connections + made by Winlogon.exe. Under normal circumstances, Winlogon.exe should not connect + to public IPs, and such activity may indicate a compromise, such as the BlackLotus + bootkit attack. This detection is significant as it highlights potential system + integrity breaches. If confirmed malicious, attackers could maintain persistence, + bypass security measures, and compromise the system at a fundamental level.' search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name IN (winlogon.exe) Processes.process!=unknown by Processes.dest Processes.user Processes.parent_process_name Processes.process_name @@ -85,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1542.003/bootkits/network-winlogon-windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1542.003/bootkits/network-winlogon-windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/windows_wmi_impersonate_token.yml b/detections/endpoint/windows_wmi_impersonate_token.yml index 07def3c05b..f6cb1a1bf1 100644 --- a/detections/endpoint/windows_wmi_impersonate_token.yml +++ b/detections/endpoint/windows_wmi_impersonate_token.yml @@ -1,15 +1,17 @@ name: Windows WMI Impersonate Token id: cf192860-2d94-40db-9a51-c04a2e8a8f8b -version: 1 -date: '2022-10-24' +version: 2 +date: '2024-05-29' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies a possible wmi token impersonation - activities in a process or command. This technique was seen in Qakbot malware where - it will execute a vbscript code contains wmi impersonation object to gain privilege - escalation or as defense evasion. This Anomaly detection looks for wmiprvse.exe - SourceImage having a duplicate handle or full granted access in a target process. +description: The following analytic detects potential WMI token impersonation activities + in a process or command. It leverages Sysmon EventCode 10 to identify instances + where `wmiprvse.exe` has a duplicate handle or full granted access in a target process. + This behavior is significant as it is commonly used by malware like Qakbot for privilege + escalation or defense evasion. If confirmed malicious, this activity could allow + an attacker to gain elevated privileges, evade defenses, and maintain persistence + within the environment. data_source: - Sysmon EventID 10 search: '`sysmon` EventCode=10 SourceImage = "*\\wmiprvse.exe" GrantedAccess IN ("0x1478", @@ -63,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/wmi_impersonate/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/wmi_impersonate/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_wmi_process_and_service_list.yml b/detections/endpoint/windows_wmi_process_and_service_list.yml index e8cc9fbb21..c9499e2dfb 100644 --- a/detections/endpoint/windows_wmi_process_and_service_list.yml +++ b/detections/endpoint/windows_wmi_process_and_service_list.yml @@ -1,16 +1,18 @@ name: Windows WMI Process And Service List id: ef3c5ef2-3f6d-4087-aa75-49bf746dc907 -version: 1 -date: '2022-11-30' +version: 2 +date: '2024-05-21' author: Teoderick Contreras, Splunk status: production type: Anomaly -description: The following analytic identifies suspicious process command line, where - WMI is performing an event query looking for running processes or running services. - This technique is commonly found where the adversary will identify services and - system information on the compromised machine. During triage, review parallel processes - within the same timeframe. Review the full script block to identify other related - artifacts. +description: The following analytic identifies suspicious WMI command lines querying + for running processes or services. It leverages data from Endpoint Detection and + Response (EDR) agents, focusing on specific process and command-line events. This + activity is significant as adversaries often use WMI to gather system information + and identify services on compromised machines. If confirmed malicious, this behavior + could allow attackers to map out the system, identify critical services, and plan + further attacks, potentially leading to privilege escalation or persistence within + the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -73,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/winpeas/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/endpoint/windows_wmi_process_call_create.yml b/detections/endpoint/windows_wmi_process_call_create.yml index 2a4401706e..efc4d39129 100644 --- a/detections/endpoint/windows_wmi_process_call_create.yml +++ b/detections/endpoint/windows_wmi_process_call_create.yml @@ -1,15 +1,18 @@ name: Windows WMI Process Call Create id: 0661c2de-93de-11ec-9833-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic is to look for wmi commandlines to execute or create process. - This technique was used by adversaries or threat actor to execute their malicious - payload in local or remote host. This hunting query is a good pivot to start to - look further which process trigger the wmi or what process it execute locally or - remotely. +description: The following analytic detects the execution of WMI command lines used + to create or execute processes. It leverages data from Endpoint Detection and Response + (EDR) agents, focusing on command-line events that include specific keywords like + "process," "call," and "create." This activity is significant because adversaries + often use WMI to execute malicious payloads on local or remote hosts, potentially + bypassing traditional security controls. If confirmed malicious, this behavior could + allow attackers to execute arbitrary code, escalate privileges, or maintain persistence + within the environment, posing a severe threat to organizational security. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/winevent_scheduled_task_created_to_spawn_shell.yml b/detections/endpoint/winevent_scheduled_task_created_to_spawn_shell.yml index b56295b658..cf1a395650 100644 --- a/detections/endpoint/winevent_scheduled_task_created_to_spawn_shell.yml +++ b/detections/endpoint/winevent_scheduled_task_created_to_spawn_shell.yml @@ -1,25 +1,25 @@ name: WinEvent Scheduled Task Created to Spawn Shell id: 203ef0ea-9bd8-11eb-8201-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP datamodel: [] -description: The following query utilizes Windows Security EventCode 4698, indicating 'a scheduled task was created', to identify potentially suspicious tasks. These tasks may be registered on Windows through either schtasks.exe or TaskService, and are set up to execute a command with a native Windows shell such as PowerShell, Cmd, Wscript, or Cscript. - - The search will return the initial and final times the task was registered, along with details like the 'Command' set to be executed, 'Task Name', 'Author', whether it's 'Enabled', and if it is 'Hidden'. - - Schtasks.exe is typically found in C:\Windows\system32 and C:\Windows\syswow64. The DLL 'taskschd.dll' is loaded when either schtasks.exe or TaskService is launched. If this DLL is found loaded by another process, it's possible that a scheduled task is being registered within the context of that process in memory. - - During triage, it's essential to identify the source of the scheduled task. Was it registered via schtasks.exe or TaskService? Review the job that was created and the command set to be executed. It's also recommended to capture and review any artifacts on disk, and identify any parallel processes within the same timeframe to locate the source. +description: The following analytic detects the creation of scheduled tasks designed + to execute commands using native Windows shells like PowerShell, Cmd, Wscript, or + Cscript. It leverages Windows Security EventCode 4698 to identify when such tasks + are registered. This activity is significant as it may indicate an attempt to establish + persistence or execute malicious commands on a system. If confirmed malicious, this + could allow an attacker to maintain access, execute arbitrary code, or escalate + privileges, posing a severe threat to the environment. data_source: - Windows Event Log Security 4698 -search: '`wineventlog_security` EventCode=4698 TaskContent IN - ("*powershell.exe*", "*wscript.exe*", "*cscript.exe*", "*cmd.exe*", "*sh.exe*", - "*ksh.exe*", "*zsh.exe*", "*bash.exe*", "*scrcons.exe*", "*pwsh.exe*") | stats count - min(_time) as firstTime max(_time) as lastTime by Computer, TaskName, TaskContent | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `winevent_scheduled_task_created_to_spawn_shell_filter`' +search: '`wineventlog_security` EventCode=4698 TaskContent IN ("*powershell.exe*", + "*wscript.exe*", "*cscript.exe*", "*cmd.exe*", "*sh.exe*", "*ksh.exe*", "*zsh.exe*", + "*bash.exe*", "*scrcons.exe*", "*pwsh.exe*") | stats count min(_time) as firstTime + max(_time) as lastTime by Computer, TaskName, TaskContent | rename Computer as dest + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `winevent_scheduled_task_created_to_spawn_shell_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. @@ -68,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_scheduled_task_created_to_spawn_shell/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_scheduled_task_created_to_spawn_shell/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/winevent_scheduled_task_created_within_public_path.yml b/detections/endpoint/winevent_scheduled_task_created_within_public_path.yml index c3a2f80f79..c53101d242 100644 --- a/detections/endpoint/winevent_scheduled_task_created_within_public_path.yml +++ b/detections/endpoint/winevent_scheduled_task_created_within_public_path.yml @@ -1,33 +1,25 @@ name: WinEvent Scheduled Task Created Within Public Path id: 5d9c6eee-988c-11eb-8253-acde48001122 -version: 3 -date: '2024-04-26' +version: 4 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP datamodel: [] -description: 'The following analytic utilizes Windows Security EventCode 4698, which - indicates the creation of a scheduled task on a Windows system. The purpose of this - query is to identify suspicious tasks that have been registered using either schtasks.exe or TaskService and involve executing a command from a user-writable file path. - - When this analytic is triggered, it provides information such as the first and last - registration time of the task, the command to be executed, the task name, author, - and whether it is set as hidden or not. It is worth noting that schtasks.exe is - commonly located in C:\Windows\system32 and C:\Windows\syswow64, and it loads the - taskschd.dll DLL when launched. If this DLL is loaded by another process, it suggests - that a scheduled task may be registered within that process''s context in memory. - - During the triage process, it is essential to identify the source of the scheduled - task creation, whether it was initiated through schtasks.exe or TaskService. The - analyst should review the task that was created, including the command to be executed. - Additionally, any artifacts on disk related to the task should be captured and analyzed. It is also recommended to identify any parallel processes that occurred within the same timeframe to determine the source of the task creation. - - By conducting this triage process, security analysts can gain insights into potentiallymalicious or suspicious scheduled tasks, helping them identify the source and assess the impact of the task. This analytic is valuable for a Security Operations Center (SOC) as it can detect unauthorized or suspicious activity that could indicate an attacker''s attempt to establish persistence or execute unauthorized commands on the system.' +description: 'The following analytic detects the creation of scheduled tasks within + user-writable paths using Windows Security EventCode 4698. It identifies tasks registered + via schtasks.exe or TaskService that execute commands from directories like Public, + ProgramData, Temp, and AppData. This behavior is significant as it may indicate + an attempt to establish persistence or execute unauthorized commands. If confirmed + malicious, an attacker could maintain long-term access, escalate privileges, or + execute arbitrary code, posing a severe threat to system integrity and security.' data_source: - Windows Event Log Security 4698 -search: '`wineventlog_security` EventCode=4698 TaskContent IN ("*\\users\\public\\*", "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") -| stats count min(_time) as firstTime max(_time) as lastTime by Computer, TaskName, TaskContent -| rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `winevent_scheduled_task_created_within_public_path_filter`' +search: '`wineventlog_security` EventCode=4698 TaskContent IN ("*\\users\\public\\*", + "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") + | stats count min(_time) as firstTime max(_time) as lastTime by Computer, TaskName, + TaskContent | rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `winevent_scheduled_task_created_within_public_path_filter`' how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. @@ -82,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_scheduled_task_created_to_spawn_shell/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_scheduled_task_created_to_spawn_shell/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml b/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml index d75d0a48d0..a30da724a5 100644 --- a/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml +++ b/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml @@ -1,25 +1,24 @@ name: WinEvent Windows Task Scheduler Event Action Started id: b3632472-310b-11ec-9aab-acde48001122 -version: 2 -date: '2024-04-26' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Hunting -description: The following hunting analytic aims to identify suspicious tasks that have been registered and executed in Windows using EventID 200 (action run) and 201 (action completed) from the Windows Task Scheduler logs. This analytic helps detect evasive techniques used to register tasks on Windows systems. It is recommended to filter the results based on the ActionName field by specifying specific paths that are not commonly used in your environment. - - After implementing this analytic, it is important to review parallel events related to the scheduled tasks. EventID 106 will be generated when a new task is created, but it does not necessarily mean that the task has been executed. Analysts should capture any files on disk associated with the task and perform further analysis. - - To implement this analytic, Task Scheduler logs must be collected. This can be done by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] in the inputs.conf file and setting renderXml=false. It is worth noting that not translating the logs into XML may require specific extraction of items from the Message field. - - False positives are expected with this analytic, so it is important to filter the results based on the paths or specific keywords of interest in the ActionName field to reduce noise. - - Identifying and analyzing scheduled tasks that have been executed is crucial for a Security Operations Center (SOC) as it helps detect potentially malicious or unauthorized activities on Windows systems. By capturing and investigating the associated events, analysts can uncover signs of persistence mechanisms, unauthorized code execution, or suspicious behaviors. The impact of a true positive could range from unauthorized access to data exfiltration or the execution of malicious payloads. -data_source: +description: The following analytic detects the execution of tasks registered in Windows + Task Scheduler by monitoring EventID 200 (action run) and 201 (action completed) + from the Task Scheduler logs. This detection leverages Task Scheduler logs to identify + potentially suspicious or unauthorized task executions. Monitoring these events + is significant for a SOC as it helps uncover evasive techniques used for persistence, + unauthorized code execution, or other malicious activities. If confirmed malicious, + this activity could lead to unauthorized access, data exfiltration, or the execution + of harmful payloads, posing a significant threat to the environment. +data_source: - Windows Event Log TaskScheduler 200 - Windows Event Log TaskScheduler 201 -search: '`wineventlog_task_scheduler` EventCode IN ("200","201") | stats count min(_time) as firstTime max(_time) as lastTime by TaskName - dest EventCode | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `winevent_windows_task_scheduler_event_action_started_filter`' +search: '`wineventlog_task_scheduler` EventCode IN ("200","201") | stats count min(_time) + as firstTime max(_time) as lastTime by TaskName dest EventCode | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `winevent_windows_task_scheduler_event_action_started_filter`' how_to_implement: Task Scheduler logs are required to be collected. Enable logging with inputs.conf by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] and renderXml=false. Note, not translating it in XML may require a proper extraction @@ -72,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_windows_task_scheduler_event_action_started/windows-xml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/winevent_windows_task_scheduler_event_action_started/windows-xml.log source: XmlWinEventLog:Security sourcetype: XmlWinEventLog diff --git a/detections/endpoint/winhlp32_spawning_a_process.yml b/detections/endpoint/winhlp32_spawning_a_process.yml index 254c835d87..1193ec77ed 100644 --- a/detections/endpoint/winhlp32_spawning_a_process.yml +++ b/detections/endpoint/winhlp32_spawning_a_process.yml @@ -1,20 +1,18 @@ name: Winhlp32 Spawning a Process id: d17dae9e-2618-11ec-b9f5-acde48001122 -version: 1 -date: '2021-10-05' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies winhlp32.exe, found natively in `c:\windows\`, - spawning a child process that loads a file out of appdata, programdata, or temp. - Winhlp32.exe has a rocky past in that multiple vulnerabilities were found and added - to MetaSploit. WinHlp32.exe is required to display 32-bit Help files that have the - ".hlp" file name extension. This particular instance is related to a Remcos sample - where dynwrapx.dll is added to the registry under inprocserver32, and later module - loaded by winhlp32.exe to spawn wscript.exe and load a vbs or file from disk. During - triage, review parallel processes to identify further suspicious behavior. Review - module loads for unsuspecting unsigned modules. Capture any file modifications and - analyze. +description: The following analytic detects winhlp32.exe spawning a child process + that loads a file from appdata, programdata, or temp directories. This detection + leverages data from Endpoint Detection and Response (EDR) agents, focusing on process + creation events. This activity is significant because winhlp32.exe has known vulnerabilities + and can be exploited to execute malicious code. If confirmed malicious, an attacker + could use this technique to execute arbitrary scripts, escalate privileges, or maintain + persistence within the environment. Analysts should review parallel processes, module + loads, and file modifications for further suspicious behavior. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -87,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/remcos/remcos/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/winrar_spawning_shell_application.yml b/detections/endpoint/winrar_spawning_shell_application.yml index 9c91751398..5f72b97010 100644 --- a/detections/endpoint/winrar_spawning_shell_application.yml +++ b/detections/endpoint/winrar_spawning_shell_application.yml @@ -1,28 +1,20 @@ name: WinRAR Spawning Shell Application id: d2f36034-37fa-4bd4-8801-26807c15540f -version: 1 -date: '2023-08-29' +version: 2 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: TTP data_source: - Sysmon EventID 1 description: The following analytic detects the execution of Windows shell processes - initiated by WinRAR, specifically looking for instances where WinRAR spawns processes - like "cmd.exe", "powershell.exe", "certutil.exe", "mshta.exe", or "bitsadmin.exe". - This behavior is worth identifying for a Security Operations Center (SOC) because - it is indicative of a spoofing attack exploit, such as the one associated with WinRAR - CVE-2023-38831. Cybercriminals exploited this vulnerability to craft ZIP archives - with spoofed extensions, hiding the launch of malicious scripts within an archive. - When a victim opened the specially crafted archive, it executed the malware, leading - to unauthorized access to their broker accounts and enabling the cybercriminals - to perform illicit financial transactions and withdraw funds. If a true positive - is found, it suggests that an attacker has successfully exploited the vulnerability - to execute malicious scripts, leading to unauthorized access, financial loss, and - potentially the delivery of additional malicious payloads. The impact of the attack - could be severe, involving financial loss, unauthorized access to sensitive accounts, - and the potential for further malicious activity such as data theft or ransomware - attacks. + initiated by WinRAR, such as "cmd.exe", "powershell.exe", "certutil.exe", "mshta.exe", + or "bitsadmin.exe". This detection leverages data from Endpoint Detection and Response + (EDR) agents, focusing on process and parent process relationships. This activity + is significant because it may indicate exploitation of the WinRAR CVE-2023-38831 + vulnerability, where malicious scripts are executed from spoofed ZIP archives. If + confirmed malicious, this could lead to unauthorized access, financial loss, and + further malicious activities like data theft or ransomware attacks. search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=winrar.exe `windows_shells` OR Processes.process_name IN ("certutil.exe","mshta.exe","bitsadmin.exe") @@ -96,6 +88,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/winrar.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/winrar.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/winrm_spawning_a_process.yml b/detections/endpoint/winrm_spawning_a_process.yml index 501e540b03..8545e5ff94 100644 --- a/detections/endpoint/winrm_spawning_a_process.yml +++ b/detections/endpoint/winrm_spawning_a_process.yml @@ -1,16 +1,17 @@ name: WinRM Spawning a Process id: a081836a-ba4d-11eb-8593-acde48001122 -version: 1 -date: '2023-12-27' +version: 2 +date: '2024-05-20' author: Drew Church, Michael Haag, Splunk status: experimental type: TTP -description: The following analytic identifies suspicious processes spawning from - WinRM (wsmprovhost.exe). This analytic is related to potential exploitation of CVE-2021-31166. - which is a kernel-mode device driver http.sys vulnerability. Current proof of concept - code will blue-screen the operating system. However, http.sys used by many different - Windows processes, including WinRM. In this case, identifying suspicious process - create (child processes) from `wsmprovhost.exe` is what this analytic is identifying. +description: The following analytic detects suspicious processes spawned by WinRM + (wsmprovhost.exe). It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on specific child processes like cmd.exe, powershell.exe, and others. + This activity is significant as it may indicate exploitation attempts of vulnerabilities + like CVE-2021-31166, which could lead to system instability or compromise. If confirmed + malicious, attackers could execute arbitrary commands, escalate privileges, or maintain + persistence, posing a severe threat to the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) diff --git a/detections/endpoint/winword_spawning_cmd.yml b/detections/endpoint/winword_spawning_cmd.yml index feef3b720e..0b0bee811b 100644 --- a/detections/endpoint/winword_spawning_cmd.yml +++ b/detections/endpoint/winword_spawning_cmd.yml @@ -1,26 +1,26 @@ name: Winword Spawning Cmd id: 6fcbaedc-a37b-11eb-956b-acde48001122 -version: 2 -date: '2021-04-22' +version: 3 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies Microsoft Word spawning `cmd.exe`. - Typically, this is not common behavior and not default with winword.exe. Winword.exe - will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` - (version will vary). Cmd.exe spawning from winword.exe is common for a spearphishing - attachment and is actively used. Albeit, the command-line will indicate what is - being executed. During triage, review parallel processes and identify any files - that may have been written. It is possible that COM is utilized to trampoline the - child process to `explorer.exe` or `wmiprvse.exe`. +description: The following analytic identifies instances where Microsoft Word (winword.exe) + spawns the command prompt (cmd.exe). This behavior is detected using Endpoint Detection + and Response (EDR) telemetry, focusing on process creation events where the parent + process is winword.exe. This activity is significant because it is uncommon and + often associated with spearphishing attacks, where malicious attachments execute + commands via cmd.exe. If confirmed malicious, this could allow an attacker to execute + arbitrary commands, potentially leading to further system compromise, data exfiltration, + or lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=winword.exe - `process_cmd` by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.original_file_name - Processes.process_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` - | `winword_spawning_cmd_filter`' + `process_cmd` by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process + Processes.original_file_name Processes.process_name Processes.process Processes.process_id + Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `winword_spawning_cmd_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -82,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/winword_spawning_powershell.yml b/detections/endpoint/winword_spawning_powershell.yml index 1cf9ea1a86..70f84db7d7 100644 --- a/detections/endpoint/winword_spawning_powershell.yml +++ b/detections/endpoint/winword_spawning_powershell.yml @@ -1,25 +1,26 @@ name: Winword Spawning PowerShell id: b2c950b8-9be2-11eb-8658-acde48001122 -version: 2 -date: '2021-04-12' +version: 3 +date: '2024-05-10' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies Microsoft Word spawning PowerShell. - Typically, this is not common behavior and not default with winword.exe. Winword.exe - will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` - (version will vary). PowerShell spawning from winword.exe is common for a spearphishing - attachment and is actively used. Albeit, the command executed will most likely be - encoded and captured via another detection. During triage, review parallel processes - and identify any files that may have been written. +description: The following analytic identifies instances where Microsoft Word (winword.exe) + spawns a PowerShell process. This behavior is detected using Endpoint Detection + and Response (EDR) telemetry, focusing on process creation events where the parent + process is winword.exe. This activity is significant because it is uncommon and + often associated with spearphishing attacks, where malicious documents execute encoded + PowerShell commands. If confirmed malicious, this could allow an attacker to execute + arbitrary code, potentially leading to data exfiltration, system compromise, or + further lateral movement within the network. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name="winword.exe" - `process_powershell` by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name - Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id - | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `winword_spawning_powershell_filter`' + `process_powershell` by Processes.dest Processes.user Processes.parent_process_name + Processes.parent_process Processes.process_name Processes.original_file_name Processes.process + Processes.process_id Processes.parent_process_id | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `winword_spawning_powershell_filter`' how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, @@ -84,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/winword_spawning_windows_script_host.yml b/detections/endpoint/winword_spawning_windows_script_host.yml index ba87028d5d..97421a66cc 100644 --- a/detections/endpoint/winword_spawning_windows_script_host.yml +++ b/detections/endpoint/winword_spawning_windows_script_host.yml @@ -1,20 +1,18 @@ name: Winword Spawning Windows Script Host id: 637e1b5c-9be1-11eb-9c32-acde48001122 -version: 1 -date: '2021-04-12' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -description: The following detection identifies Microsoft Winword.exe spawning Windows - Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior - and not default with Winword.exe. Winword.exe will generally be found in the following - path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` - or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64\`. - `cscript.exe` or `wscript.exe` spawning from Winword.exe is common for a spearphishing - attachment and is actively used. Albeit, the command-line executed will most likely - be obfuscated and captured via another detection. During triage, review parallel - processes and identify any files that may have been written. Review the reputation - of the remote destination and block accordingly. +description: The following analytic identifies instances where Microsoft Winword.exe + spawns Windows Script Host processes (cscript.exe or wscript.exe). This behavior + is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process + creation events where the parent process is Winword.exe. This activity is significant + because it is uncommon and often associated with spearphishing attacks, where malicious + scripts are executed via document macros. If confirmed malicious, this could lead + to code execution, allowing attackers to gain initial access, execute further payloads, + or establish persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -77,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_wsh.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566.001/macro/windows-sysmon_wsh.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmi_permanent_event_subscription.yml b/detections/endpoint/wmi_permanent_event_subscription.yml index f14e47a813..4c15c26cac 100644 --- a/detections/endpoint/wmi_permanent_event_subscription.yml +++ b/detections/endpoint/wmi_permanent_event_subscription.yml @@ -1,12 +1,12 @@ name: WMI Permanent Event Subscription id: 71bfdb13-f200-4c6c-b2c9-a2e07adf437d -version: 1 -date: '2018-10-23' +version: 2 +date: '2024-05-26' author: Rico Valdez, Splunk status: experimental type: TTP description: |- - The following analytic detects the creation of permanent event subscriptions using Windows Management Instrumentation (WMI), which is used by attackers to achieve persistence in a compromised system. By creating a permanent event subscription, an attacker can run malicious scripts or binaries in response to specific system events that enables them to maintain access to the system undetected. The detection is made by using Sysmon EventID 5 data to detect instances where the consumers of these events are not the expected "NTEventLogEventConsumer." The detection is important because it identifies unusual or unexpected subscription creation, which suggests that an attacker is attempting to achieve persistence within the environment and might be executing malicious scripts or binaries in response to specific system events. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other damaging outcomes. False positives might occur since False positives might occur since WMI event subscriptions can be used for legitimate purposes by system administrators. You must have a thorough understanding of WMI activity within the context of the monitored environment to effectively differentiate between legitimate and malicious activity.Next steps include investigating the associated scripts or binaries and identifying the source of the attack. + The following analytic detects the creation of permanent event subscriptions using Windows Management Instrumentation (WMI). It leverages Sysmon Event ID 5 data to identify instances where the event consumers are not the expected "NTEventLogEventConsumer." This activity is significant because it suggests an attacker is attempting to achieve persistence by running malicious scripts or binaries in response to specific system events. If confirmed malicious, this could lead to severe impacts such as data theft, ransomware deployment, or other damaging outcomes. Investigate the associated scripts or binaries to identify the source of the attack. data_source: - Windows Event Log WMI 5861 search: '`wmi` EventCode=5861 Binding | rex field=Message "Consumer =\s+(?[^;|^$]+)" diff --git a/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml b/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml index 5d55fd0c61..754d36939a 100644 --- a/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml +++ b/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml @@ -1,31 +1,18 @@ name: WMI Permanent Event Subscription - Sysmon id: ad05aae6-3b2a-4f73-af97-57bd26cee3b9 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-20' author: Rico Valdez, Michael Haag, Splunk status: production type: TTP -description: 'This analytic looks for the creation of WMI permanent event subscriptions. - The following analytic identifies the use of WMI Event Subscription to establish - persistence or perform privilege escalation. WMI can be used to install event filters, - providers, consumers, and bindings that execute code when a defined event occurs. - WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) - and thus may result in elevated SYSTEM privileges. This analytic is restricted by - commonly added process execution and a path. If the volume is low enough, remove - the values and flag on any new subscriptions. - - All event subscriptions have three components - - 1. Filter - WQL Query for the events we want. EventID = 19 - - 1. Consumer - An action to take upon triggering the filter. EventID = 20 - - 1. Binding - Registers a filter to a consumer. EventID = 21 - - Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. - It may be pertinent to review all 3 to identify the flow of execution. In addition, - EventCode 4104 may assist with any other PowerShell script usage that registered - the subscription.' +description: 'The following analytic identifies the creation of WMI permanent event + subscriptions, which can be used to establish persistence or perform privilege escalation. + It leverages Sysmon data, specifically EventCodes 19, 20, and 21, to detect the + creation of WMI EventFilters, EventConsumers, and FilterToConsumerBindings. This + activity is significant as it may indicate an attacker setting up mechanisms to + execute code with elevated SYSTEM privileges when specific events occur. If confirmed + malicious, this could allow the attacker to maintain persistence, escalate privileges, + and execute arbitrary code, posing a severe threat to the environment.' data_source: - Sysmon EventID 21 search: '`sysmon` EventCode=21 | rename host as dest | table _time, dest, user, Operation, @@ -79,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmi_recon_running_process_or_services.yml b/detections/endpoint/wmi_recon_running_process_or_services.yml index 69dffcabc4..bd3d1d259a 100644 --- a/detections/endpoint/wmi_recon_running_process_or_services.yml +++ b/detections/endpoint/wmi_recon_running_process_or_services.yml @@ -1,22 +1,25 @@ name: WMI Recon Running Process Or Services id: b5cd5526-cce7-11eb-b3bd-acde48001122 -version: 3 -date: '2023-11-07' +version: 4 +date: '2024-05-15' author: Teoderick Contreras, Splunk status: production type: Anomaly description: The following analytic identifies suspicious PowerShell script execution - via EventCode 4104, where WMI is performing an event query looking for running processes - or running services. This technique is commonly found in malware and APT events - where the adversary will map all running security applications or services on the - compromised machine. During triage, review parallel processes within the same timeframe. - Review the full script block to identify other related artifacts. + via EventCode 4104, where WMI performs an event query to list running processes + or services. This detection leverages PowerShell Script Block Logging to capture + and analyze script block text for specific WMI queries. This activity is significant + as it is commonly used by malware and APT actors to map security applications or + services on a compromised machine. If confirmed malicious, this could allow attackers + to identify and potentially disable security defenses, facilitating further compromise + and persistence within the environment. data_source: - Powershell Script Block Logging 4104 search: '`powershell` EventCode=4104 ScriptBlockText= "*SELECT*" AND (ScriptBlockText="*Win32_Process*" OR ScriptBlockText="*Win32_Service*") | stats count min(_time) as firstTime max(_time) - as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `wmi_recon_running_process_or_services_filter`' + as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest + | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `wmi_recon_running_process_or_services_filter`' how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. @@ -64,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/win32process.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/win32process.log source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmi_temporary_event_subscription.yml b/detections/endpoint/wmi_temporary_event_subscription.yml index d0b7a2d7a9..3e9a1cee3b 100644 --- a/detections/endpoint/wmi_temporary_event_subscription.yml +++ b/detections/endpoint/wmi_temporary_event_subscription.yml @@ -1,11 +1,18 @@ name: WMI Temporary Event Subscription id: 38cbd42c-1098-41bb-99cf-9d6d2b296d83 -version: 1 -date: '2018-10-23' +version: 2 +date: '2024-05-12' author: Rico Valdez, Splunk status: experimental type: TTP -description: "The following analytic detects the creation of WMI temporary event subscriptions. WMI (Windows Management Instrumentation) is a management technology that allows administrators to perform various tasks on Windows-based systems. Temporary event subscriptions are created to monitor specific events or changes on a system that help to detect potential threats early and take proactive measures to protect the organization's systems and data. The detection is made by using the Splunk query `wmi` EventCode=5860 Temporary to search for events with EventCode 5860, which indicates the creation of a temporary WMI event subscription. To further refine the search results, the query uses regular expressions (rex) to extract the query used in the event subscription. Then, it filters known benign queries related to system processes such as 'wsmprovhost.exe' and 'AntiVirusProduct', 'FirewallProduct', 'AntiSpywareProduct', which helps to focus on potentially malicious or suspicious queries. The detection is important because it indicates malicious activity since attackers use WMI to run commands, gather information, or maintain persistence within a compromised system. False positives might occur since legitimate uses of WMI event subscriptions in the environment might trigger benign activities to be flagged. Therefore, an extensive triage is necessary to review the specific query and assess its intent. Additionally, capturing and inspecting relevant on-disk artifacts and analyzing concurrent processes can help to identify the source of the attack. Detecting the creation of these event subscriptions to identify potential threats early and take appropriate actions to mitigate the risks." +description: "The following analytic detects the creation of WMI temporary event subscriptions. + It leverages Windows Event Logs, specifically EventCode 5860, to identify these + activities. This detection is significant because attackers often use WMI to execute + commands, gather information, or maintain persistence within a compromised system. + If confirmed malicious, this activity could allow an attacker to execute arbitrary + code, escalate privileges, or persist in the environment. Analysts should review + the specific WMI queries and assess their intent, considering potential false positives + from legitimate administrative tasks." data_source: - Windows Event Log WMI 5860 search: '`wmi` EventCode=5860 Temporary | rex field=Message "NotificationQuery =\s+(?[^;|^$]+)" diff --git a/detections/endpoint/wmic_group_discovery.yml b/detections/endpoint/wmic_group_discovery.yml index 7a93892934..8ec9c7c739 100644 --- a/detections/endpoint/wmic_group_discovery.yml +++ b/detections/endpoint/wmic_group_discovery.yml @@ -1,17 +1,18 @@ name: Wmic Group Discovery id: 83317b08-155b-11ec-8e00-acde48001122 -version: 1 -date: '2021-09-14' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following hunting analytic identifies the use of `wmic.exe` enumerating - local groups on the endpoint. - - Typically, by itself, is not malicious but may raise suspicion based on time of - day, endpoint and username. - - During triage, review parallel processes and identify any further suspicious behavior.' +description: 'The following analytic identifies the use of `wmic.exe` to enumerate + local groups on an endpoint. This detection leverages data from Endpoint Detection + and Response (EDR) agents, focusing on process execution logs, including command-line + details. Monitoring this activity is significant as it can indicate reconnaissance + efforts by an attacker to understand group memberships, which could be a precursor + to privilege escalation or lateral movement. If confirmed malicious, this activity + could allow an attacker to map out privileged groups, aiding in further exploitation + and persistence within the environment.' data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -74,6 +75,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1069.001/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmic_noninteractive_app_uninstallation.yml b/detections/endpoint/wmic_noninteractive_app_uninstallation.yml index 39c41f866b..4e598965b7 100644 --- a/detections/endpoint/wmic_noninteractive_app_uninstallation.yml +++ b/detections/endpoint/wmic_noninteractive_app_uninstallation.yml @@ -1,16 +1,18 @@ name: Wmic NonInteractive App Uninstallation id: bff0e7a0-317f-11ec-ab4e-acde48001122 -version: 2 -date: '2022-07-19' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: Hunting -description: This analytic indentifies WMIC command-line attempting to uninstall application - non-interactively. This technique was seen in IcedID to uninstall AV products on - the compromised host to evade detection. This Hunting query maybe a good indicator - that some process tries to uninstall application using wmic which is not a common - behavior. This approach may seen in some script or third part appication to uninstall - their application but it is a good thing to check what it uninstall and why. +description: The following analytic identifies the use of the WMIC command-line tool + attempting to uninstall applications non-interactively. It leverages data from Endpoint + Detection and Response (EDR) agents, focusing on specific command-line patterns + associated with WMIC. This activity is significant because it is uncommon and may + indicate an attempt to evade detection by uninstalling security software, as seen + in IcedID malware campaigns. If confirmed malicious, this behavior could allow an + attacker to disable security defenses, facilitating further compromise and persistence + within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -80,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon2.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/icedid/disable_av/sysmon2.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmic_xsl_execution_via_url.yml b/detections/endpoint/wmic_xsl_execution_via_url.yml index c2cbbefce0..dea2d4446b 100644 --- a/detections/endpoint/wmic_xsl_execution_via_url.yml +++ b/detections/endpoint/wmic_xsl_execution_via_url.yml @@ -1,18 +1,18 @@ name: WMIC XSL Execution via URL id: 787e9dd0-4328-11ec-a029-acde48001122 -version: 1 -date: '2021-11-11' +version: 2 +date: '2024-05-27' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies `wmic.exe` loading a remote XSL (eXtensible - Stylesheet Language) script. This originally was identified by Casey Smith, dubbed - Squiblytwo, as an application control bypass. Many adversaries will utilize this - technique to invoke JScript or VBScript within an XSL file. This technique can also - execute local/remote scripts and, similar to its Regsvr32 "Squiblydoo" counterpart, - leverages a trusted, built-in Windows tool. Adversaries may abuse any alias in Windows - Management Instrumentation provided they utilize the /FORMAT switch. Upon identifying - a suspicious execution, review for confirmed network connnection and script download. +description: The following analytic detects `wmic.exe` loading a remote XSL script + via a URL. This detection leverages Endpoint Detection and Response (EDR) data, + focusing on command-line executions that include HTTP/HTTPS URLs and the /FORMAT + switch. This activity is significant as it indicates a potential application control + bypass, allowing adversaries to execute JScript or VBScript within an XSL file. + If confirmed malicious, this technique can enable attackers to execute arbitrary + code, escalate privileges, or maintain persistence using a trusted Windows tool, + posing a severe threat to the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -85,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1220/atomic_red_team/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1220/atomic_red_team/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wmiprsve_lolbas_execution_process_spawn.yml b/detections/endpoint/wmiprsve_lolbas_execution_process_spawn.yml index 5b054faec0..320825cc45 100644 --- a/detections/endpoint/wmiprsve_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/wmiprsve_lolbas_execution_process_spawn.yml @@ -1,17 +1,18 @@ name: Wmiprsve LOLBAS Execution Process Spawn id: 95a455f0-4c04-11ec-b8ac-3e22fbd008af -version: 1 -date: '2021-11-22' +version: 2 +date: '2024-05-10' author: Mauricio Velazco, Splunk status: production type: TTP -description: The following analytic identifies `wmiprsve.exe` spawning a LOLBAS execution - process. When adversaries execute code on remote endpoints abusing Windows Management - Instrumentation (WMI), the executed command is spawned as a child process of `wmiprvse.exe`. - The LOLBAS project documents Windows native binaries that can be abused by threat - actors to perform tasks like executing malicious code. Looking for child processes - of wmiprvse.exe that are part of the LOLBAS project can help defenders identify - lateral movement activity. +description: The following analytic detects `wmiprvse.exe` spawning a LOLBAS execution + process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing + on process creation events where `wmiprvse.exe` is the parent process and the child + process is a known LOLBAS binary. This activity is significant as it may indicate + lateral movement or remote code execution by an adversary abusing Windows Management + Instrumentation (WMI). If confirmed malicious, this behavior could allow attackers + to execute arbitrary code, escalate privileges, or maintain persistence within the + environment, posing a severe security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -81,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement_lolbas/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/lateral_movement_lolbas/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wscript_or_cscript_suspicious_child_process.yml b/detections/endpoint/wscript_or_cscript_suspicious_child_process.yml index dba8b14e7b..be80f2ab03 100644 --- a/detections/endpoint/wscript_or_cscript_suspicious_child_process.yml +++ b/detections/endpoint/wscript_or_cscript_suspicious_child_process.yml @@ -1,16 +1,17 @@ name: Wscript Or Cscript Suspicious Child Process id: 1f35e1da-267b-11ec-90a9-acde48001122 -version: 1 -date: '2023-04-14' +version: 2 +date: '2024-05-18' author: Teoderick Contreras, Splunk status: production type: TTP -description: This analytic identifies a suspicious spawned process by WScript or CScript - process. This technique was a common technique used by adversaries and malware to - execute different LOLBIN, other scripts like PowerShell or spawn a suspended process - to inject its code as a defense evasion. This TTP may detect some normal script - that using several application tool that are in the list of the child process it - detects but a good pivot and indicator that a script is may execute suspicious code. +description: The following analytic identifies suspicious child processes spawned + by WScript or CScript. It leverages data from Endpoint Detection and Response (EDR) + agents, focusing on specific parent and child process names. This activity is significant + as adversaries often use WScript or CScript to execute Living Off The Land Binaries + (LOLBINs) or other scripts like PowerShell for defense evasion. If confirmed malicious, + this behavior could allow attackers to execute arbitrary code, escalate privileges, + or maintain persistence within the environment, posing a significant security risk. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml b/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml index 800b0bb31c..7d85e2a050 100644 --- a/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml @@ -1,17 +1,18 @@ name: Wsmprovhost LOLBAS Execution Process Spawn id: 2eed004c-4c0d-11ec-93e8-3e22fbd008af -version: 1 -date: '2021-11-22' +version: 2 +date: '2024-05-12' author: Mauricio Velazco, Splunk status: production type: TTP description: The following analytic identifies `Wsmprovhost.exe` spawning a LOLBAS - execution process. When adversaries execute code on remote endpoints abusing the - Windows Remote Management (WinRm) protocol, the executed command is spawned as a - child processs of `Wsmprovhost.exe`. The LOLBAS project documents Windows native - binaries that can be abused by threat actors to perform tasks like executing malicious - code. Looking for child processes of Wsmprovhost.exe that are part of the LOLBAS - project can help defenders identify lateral movement activity. + execution process. It leverages Endpoint Detection and Response (EDR) data to detect + when `Wsmprovhost.exe` spawns child processes that are known LOLBAS (Living Off + the Land Binaries and Scripts) executables. This activity is significant because + it may indicate an adversary using Windows Remote Management (WinRM) to execute + code on remote endpoints, a common technique for lateral movement. If confirmed + malicious, this could allow attackers to execute arbitrary code, escalate privileges, + or maintain persistence within the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -82,6 +83,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_lolbas/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.006/lateral_movement_lolbas/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/wsreset_uac_bypass.yml b/detections/endpoint/wsreset_uac_bypass.yml index 6a10398c61..6d27b6f43a 100644 --- a/detections/endpoint/wsreset_uac_bypass.yml +++ b/detections/endpoint/wsreset_uac_bypass.yml @@ -1,14 +1,18 @@ name: WSReset UAC Bypass id: 8b5901bc-da63-11eb-be43-acde48001122 -version: 3 -date: '2022-11-14' +version: 4 +date: '2024-05-19' author: Steven Dick, Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious modification of registry related - to UAC bypass. This technique is to modify the registry in this detection, create - a registry value with the path of the payload and run WSreset.exe to bypass User - account Control. +description: The following analytic detects a suspicious modification of the registry + aimed at bypassing User Account Control (UAC) by leveraging WSReset.exe. It identifies + the creation or modification of specific registry values under the path "*\\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\\Shell\\open\\command*". + This detection uses data from Endpoint Detection and Response (EDR) agents, focusing + on process and registry events. This activity is significant because UAC bypass + techniques can allow attackers to execute high-privilege actions without user consent. + If confirmed malicious, this could lead to unauthorized code execution and potential + system compromise. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) @@ -81,6 +85,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/uac_bypass/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/endpoint/xsl_script_execution_with_wmic.yml b/detections/endpoint/xsl_script_execution_with_wmic.yml index f1af9e49b9..87c4f9bd36 100644 --- a/detections/endpoint/xsl_script_execution_with_wmic.yml +++ b/detections/endpoint/xsl_script_execution_with_wmic.yml @@ -1,15 +1,18 @@ name: XSL Script Execution With WMIC id: 004e32e2-146d-11ec-a83f-acde48001122 -version: 1 -date: '2021-09-13' +version: 2 +date: '2024-05-13' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect a suspicious wmic.exe process or renamed wmic - process to execute malicious xsl file. This technique was seen in FIN7 to execute - its malicous jscript using the .xsl as the loader with the help of wmic.exe process. - This TTP is really a good indicator for you to hunt further for FIN7 or other attacker - that known to used this technique. +description: The following analytic detects the execution of an XSL script using the + WMIC process, which is often indicative of malicious activity. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on command-line executions + involving WMIC and XSL files. This behavior is significant as it has been associated + with the FIN7 group, known for using this technique to execute malicious scripts. + If confirmed malicious, this activity could allow attackers to execute arbitrary + code, potentially leading to system compromise and further malicious actions within + the environment. data_source: - Sysmon EventID 1 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) @@ -79,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/fin7/fin7_macro_js_1/sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/network/detect_dga_domains_using_pretrained_model_in_dsdl.yml b/detections/network/detect_dga_domains_using_pretrained_model_in_dsdl.yml index 2377cb5c08..9b33d3d609 100644 --- a/detections/network/detect_dga_domains_using_pretrained_model_in_dsdl.yml +++ b/detections/network/detect_dga_domains_using_pretrained_model_in_dsdl.yml @@ -1,23 +1,18 @@ name: Detect DGA domains using pretrained model in DSDL id: 92e24f32-9b9a-4060-bba2-2a0eb31f3493 -version: 1 -date: '2023-01-18' +version: 2 +date: '2024-05-29' author: Abhinav Mishra, Kumar Sharad and Namratha Sreekanta, Splunk status: experimental type: Anomaly -description: The following analytic uses a pre trained deep learning model to detect - Domain Generation Algorithm (DGA) generated domains. The model is trained independently - and is then made available for download. One of the prominent indicators of a domain - being DGA generated is if the domain name consists of unusual character sequences - or concatenated dictionary words. Adversaries often use clever techniques to obfuscate - machine generated domain names as human generated. Predicting DGA generated domain - names requires analysis and building a model based on carefully chosen features. - The deep learning model we have developed uses the domain name to analyze patterns - of character sequences along with carefully chosen custom features to predict if - a domain is DGA generated. The model takes a domain name consisting of second-level - and top-level domain names as input and outputs a dga_score. Higher the dga_score, - the more likely the input domain is a DGA domain. The threshold for flagging a domain - as DGA is set at 0.5. +description: The following analytic identifies Domain Generation Algorithm (DGA) generated + domains using a pre-trained deep learning model. It leverages the Network Resolution + data model to analyze domain names and detect unusual character sequences indicative + of DGA activity. This behavior is significant as adversaries often use DGAs to generate + numerous domain names for command-and-control servers, making it harder to block + malicious traffic. If confirmed malicious, this activity could enable attackers + to maintain persistent communication with compromised systems, evade detection, + and execute further malicious actions. data_source: [] search: '| tstats `security_content_summariesonly` values(DNS.answer) as IPs min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Resolution by DNS.src, @@ -38,7 +33,7 @@ how_to_implement: 'Steps to deploy DGA detection model into Splunk App DSDL.\ Th * Login to the Jupyter Lab for pretrained_dga_model_dsdl container. This container should be listed on Containers page for DSDL app. - * Below steps need to be followed inside Jupyter lab + * Below steps need to be followed inside Jupyter lab * Upload the pretrained_dga_model_dsdl.tar.gz file into `app/model/data` path using the upload option in the jupyter notebook. diff --git a/detections/network/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.yml b/detections/network/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.yml index 6861eff46d..2b626e75f4 100644 --- a/detections/network/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.yml +++ b/detections/network/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.yml @@ -1,94 +1,82 @@ name: Detect DNS Data Exfiltration using pretrained model in DSDL id: 92f65c3a-168c-11ed-71eb-0242ac120012 -version: 1 -date: '2023-04-27' +version: 2 +date: '2024-05-22' status: experimental author: Abhinav Mishra, Kumar Sharad and Namratha Sreekanta, Splunk type: Anomaly data_source: [] -description: The following analytic uses a pre trained deep learning model to - detect DNS data exfiltration. The model is trained on the data we collected - and is inferred on live data. This detection detects low throughput DNS - Tunneling (data exfiltration) using features computed from past events between - the same src and domain. The search uses macros from URL ToolBox app to - generate features used by the model. The model is a deep learning model that - accepts DNS request as input along with a few custom features to generate a - pred_is_exfiltration_proba score. The higher the pred_is_exfiltration_proba, - the more likely the DNS request is data exfiltration. The threshold for - flagging a request as DNS exfiltration is set at 0.5. -search: '| tstats `security_content_summariesonly` count from - datamodel=Network_Resolution by DNS.src _time DNS.query | - `drop_dm_object_name("DNS")` | sort - _time,src, query | streamstats count as - rank by src query | where rank < 10 | table src,query,rank,_time | apply - detect_dns_data_exfiltration_using_pretrained_model_in_dsdl | table - src,_time,query,rank,pred_is_dns_data_exfiltration_proba,pred_is_dns_data_exfiltration - | where rank == 1 | rename pred_is_dns_data_exfiltration_proba as - is_exfiltration_score | rename pred_is_dns_data_exfiltration as - is_exfiltration | where is_exfiltration_score > 0.5 | - `security_content_ctime(_time)` | - table src, _time,query,is_exfiltration_score,is_exfiltration | - `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl_filter`' -how_to_implement: - Steps to deploy detect DNS data exfiltration model into Splunk - App DSDL. This detection depends on the Splunk app for Data Science and Deep - Learning which can be found here - https://splunkbase.splunk.com/app/4607/ and - the Network Resolution datamodel which can be found here - - https://splunkbase.splunk.com/app/1621/. The detection uses a pre-trained deep - learning model that needs to be deployed in DSDL app. Follow the steps for - deployment here - - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`. - - * Download the `artifacts .tar.gz` file from the link - https://seal.splunkresearch.com/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz Download the `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from https://github.com/splunk/security_content/notebooks - - * Login to the Jupyter Lab assigned for detect_dns_data_exfiltration_using_pretrained_model_in_dsdl container. This container should be listed on Containers page for DSDL app. - - * Below steps need to be followed inside Jupyter lab - - * Upload the detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz file into `app/model/data` path using the upload option in the jupyter notebook. - - * Untar the artifact detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz -C app/model/data` - - * Upload detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.pynb into Jupyter lab notebooks folder using the upload option in Jupyter lab - - * Save the notebook using the save option in jupyter notebook. - - * Upload `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.json` into `notebooks/data` folder. -known_false_positives: False positives may be present if DNS data exfiltration - request look very similar to benign DNS requests. +description: The following analytic identifies potential DNS data exfiltration using + a pre-trained deep learning model. It leverages DNS request data from the Network + Resolution datamodel and computes features from past events between the same source + and domain. The model generates a probability score (pred_is_exfiltration_proba) + indicating the likelihood of data exfiltration. This activity is significant as + DNS tunneling can be used by attackers to covertly exfiltrate sensitive data. If + confirmed malicious, this could lead to unauthorized data access and potential data + breaches, compromising the organization's security posture. +search: '| tstats `security_content_summariesonly` count from datamodel=Network_Resolution + by DNS.src _time DNS.query | `drop_dm_object_name("DNS")` | sort - _time,src, query + | streamstats count as rank by src query | where rank < 10 | table src,query,rank,_time + | apply detect_dns_data_exfiltration_using_pretrained_model_in_dsdl | table src,_time,query,rank,pred_is_dns_data_exfiltration_proba,pred_is_dns_data_exfiltration + | where rank == 1 | rename pred_is_dns_data_exfiltration_proba as is_exfiltration_score + | rename pred_is_dns_data_exfiltration as is_exfiltration | where is_exfiltration_score + > 0.5 | `security_content_ctime(_time)` | table src, _time,query,is_exfiltration_score,is_exfiltration + | `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl_filter`' +how_to_implement: "Steps to deploy detect DNS data exfiltration model into Splunk + App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning + which can be found here - https://splunkbase.splunk.com/app/4607/ and the Network + Resolution datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. + The detection uses a pre-trained deep learning model that needs to be deployed in + DSDL app. Follow the steps for deployment here - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`.\n + * Download the `artifacts .tar.gz` file from the link - https://seal.splunkresearch.com/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz + Download the `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.ipynb` + Jupyter notebook from https://github.com/splunk/security_content/notebooks\n* Login + to the Jupyter Lab assigned for detect_dns_data_exfiltration_using_pretrained_model_in_dsdl + container. This container should be listed on Containers page for DSDL app.\n* Below + steps need to be followed inside Jupyter lab\n* Upload the detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz + file into `app/model/data` path using the upload option in the jupyter notebook.\n + * Untar the artifact detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz + using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz + -C app/model/data`\n* Upload detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.pynb + into Jupyter lab notebooks folder using the upload option in Jupyter lab\n* Save + the notebook using the save option in jupyter notebook.\n* Upload `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.json` + into `notebooks/data` folder." +known_false_positives: False positives may be present if DNS data exfiltration request + look very similar to benign DNS requests. references: - - https://attack.mitre.org/techniques/T1048/003/ - - https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ - - https://en.wikipedia.org/wiki/Data_exfiltration +- https://attack.mitre.org/techniques/T1048/003/ +- https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ +- https://en.wikipedia.org/wiki/Data_exfiltration tags: analytic_story: - - DNS Hijacking - - Suspicious DNS Traffic - - Command And Control + - DNS Hijacking + - Suspicious DNS Traffic + - Command And Control asset_type: Endpoint confidence: 90 impact: 50 message: A DNS data exfiltration request was sent by this host $src$ , kindly review. mitre_attack_id: - - T1048.003 + - T1048.003 observable: - - name: query - type: Other - role: - - Attacker - - name: src - type: Hostname - role: - - Victim + - name: query + type: Other + role: + - Attacker + - name: src + type: Hostname + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - DNS.message_type - - DNS.record_type - - DNS.src - - DNS.dest - - DNS.answer + - _time + - DNS.message_type + - DNS.record_type + - DNS.src + - DNS.dest + - DNS.answer risk_score: 45 security_domain: network diff --git a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml index 6cd5284fd1..390d41a9a6 100644 --- a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml +++ b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml @@ -1,17 +1,19 @@ name: Detect hosts connecting to dynamic domain providers id: a1e761ac-1344-4dbd-88b2-3f34c912d359 -version: 3 -date: '2021-01-14' +version: 4 +date: '2024-05-18' author: Bhavin Patel, Splunk status: production type: TTP -description: Malicious actors often abuse legitimate Dynamic DNS services to host - malicious payloads or interactive Command And Control nodes. Attackers will automate - domain resolution changes by routing dynamic domains to countless IP addresses to - circumvent firewall blocks, block lists as well as frustrate a network defenders - analytic and investigative processes. This search will look for DNS queries made - from within your infrastructure to suspicious dynamic domains. -data_source: +description: The following analytic identifies DNS queries from internal hosts to + dynamic domain providers. It leverages DNS query logs from the `Network_Resolution` + data model and cross-references them with a lookup file containing known dynamic + DNS providers. This activity is significant because attackers often use dynamic + DNS services to host malicious payloads or command-and-control servers, making it + crucial for security teams to monitor. If confirmed malicious, this activity could + allow attackers to bypass firewall blocks, evade detection, and maintain persistent + access to the network. +data_source: - Sysmon EventID 22 search: '| tstats `security_content_summariesonly` count values(DNS.answer) as answer min(_time) as firstTime from datamodel=Network_Resolution by DNS.query host | `drop_dm_object_name("DNS")` @@ -30,7 +32,7 @@ how_to_implement: 'First, you''ll need to ingest data from your DNS operations. metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry): - + * **Label:** DNS Query, **Field:** query * **Label:** DNS Answer, **Field:** answer @@ -77,6 +79,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/dyn_dns_site/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/dyn_dns_site/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/network/detect_large_outbound_icmp_packets.yml b/detections/network/detect_large_outbound_icmp_packets.yml index 8ac62d5ad3..c4dc8a9563 100644 --- a/detections/network/detect_large_outbound_icmp_packets.yml +++ b/detections/network/detect_large_outbound_icmp_packets.yml @@ -1,14 +1,18 @@ name: Detect Large Outbound ICMP Packets id: e9c102de-4d43-42a7-b1c8-8062ea297419 -version: 2 -date: '2018-06-01' +version: 3 +date: '2024-05-24' author: Rico Valdez, Splunk status: experimental type: TTP -description: This search looks for outbound ICMP packets with a packet size larger - than 1,000 bytes. Various threat actors have been known to use ICMP as a command - and control channel for their attack infrastructure. Large ICMP packets from an - endpoint to a remote host may be indicative of this activity. +description: The following analytic identifies outbound ICMP packets with a size larger + than 1,000 bytes. It leverages the Network_Traffic data model to detect unusually + large ICMP packets that are not blocked and are destined for external IP addresses. + This activity is significant because threat actors often use ICMP for command and + control communication, and large ICMP packets can indicate data exfiltration or + other malicious activities. If confirmed malicious, this could allow attackers to + maintain covert communication channels, exfiltrate sensitive data, or further compromise + the network. data_source: [] search: '| tstats `security_content_summariesonly` count earliest(_time) as firstTime latest(_time) as lastTime values(All_Traffic.action) values(All_Traffic.bytes) from diff --git a/detections/network/detect_outbound_ldap_traffic.yml b/detections/network/detect_outbound_ldap_traffic.yml index a64fc816e0..ea8dfaf973 100644 --- a/detections/network/detect_outbound_ldap_traffic.yml +++ b/detections/network/detect_outbound_ldap_traffic.yml @@ -5,12 +5,14 @@ date: '2024-05-21' author: Bhavin Patel, Johan Bjerke, Splunk status: production type: Hunting -description: Malicious actors often abuse misconfigured LDAP servers or applications - that use the LDAP servers in organizations. Outbound LDAP traffic should not be - allowed outbound through your perimeter firewall. This search will help determine - if you have any LDAP connections to IP addresses outside of private (RFC1918) address - space. -data_source: +description: The following analytic identifies outbound LDAP traffic to external IP + addresses. It leverages the Network_Traffic data model to detect connections on + ports 389 or 636 that are not directed to private IP ranges (RFC1918). This activity + is significant because outbound LDAP traffic can indicate potential data exfiltration + or unauthorized access attempts. If confirmed malicious, attackers could exploit + this to access sensitive directory information, leading to data breaches or further + network compromise. +data_source: - Bro search: '| tstats earliest(_time) as earliest_time latest(_time) as latest_time values(All_Traffic.dest_ip) as dest_ip from datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port diff --git a/detections/network/detect_outbound_smb_traffic.yml b/detections/network/detect_outbound_smb_traffic.yml index b3cbdf700a..67643b492d 100644 --- a/detections/network/detect_outbound_smb_traffic.yml +++ b/detections/network/detect_outbound_smb_traffic.yml @@ -1,33 +1,31 @@ name: Detect Outbound SMB Traffic id: 1bed7774-304a-4e8f-9d72-d80e45ff492b -version: 4 -date: '2024-02-27' -author: Bhavin Patel, Stuart Hopkins, Patrick Bareiss +version: 5 +date: '2024-05-25' +author: Bhavin Patel, Stuart Hopkins, Patrick Bareiss status: experimental type: TTP -description: The following analytic detects outbound SMB (Server Message Block) connections from internal hosts to external servers, - a method commonly exploited for Windows file-sharing activities. It identifies this behavior by monitoring network traffic for SMB requests - directed towards the Internet, which are not typical for standard operations. This detection is crucial for a Security Operations Center (SOC) - as it can indicate an attackers attempt to retrieve credential hashes through compromised servers, a key step in lateral movement and - privilege escalation. The impact of such an attack includes unauthorized access to sensitive data and potential full system compromise. +description: The following analytic detects outbound SMB (Server Message Block) connections + from internal hosts to external servers. It identifies this activity by monitoring + network traffic for SMB requests directed towards the Internet, which are unusual + for standard operations. This detection is significant for a SOC as it can indicate + an attacker's attempt to retrieve credential hashes through compromised servers, + a key step in lateral movement and privilege escalation. If confirmed malicious, + this activity could lead to unauthorized access to sensitive data and potential + full system compromise. data_source: [] -search: '| tstats `security_content_summariesonly` earliest(_time) as start_time latest(_time) as end_time values(All_Traffic.action) as action values(All_Traffic.app) as app - values(All_Traffic.dest_ip) as dest_ip values(All_Traffic.dest_port) as dest_port values(sourcetype) as sourcetype count from datamodel=Network_Traffic - where (All_Traffic.action=allowed All_Traffic.direction=outbound All_Traffic.dest_port=139 OR All_Traffic.dest_port=445 OR All_Traffic.app="smb") by All_Traffic.src_ip - | `drop_dm_object_name("All_Traffic")` - | eval match=case( - cidrmatch("10.0.0.0/8" ,dest_ip) ,"1", - cidrmatch("172.16.0.0/12" ,dest_ip) ,"1", - cidrmatch("192.168.0.0/16" ,dest_ip) ,"1", - cidrmatch("100.64.0.0/10" ,dest_ip) ,"1", - 1=1,"0") - | search match=0 - | fields - match - | `security_content_ctime(start_time)` - | `security_content_ctime(end_time)` - | `detect_outbound_smb_traffic_filter`' -how_to_implement: 'This search also requires you to be ingesting your network traffic and populating - the Network_Traffic data model' +search: '| tstats `security_content_summariesonly` earliest(_time) as start_time latest(_time) + as end_time values(All_Traffic.action) as action values(All_Traffic.app) as app + values(All_Traffic.dest_ip) as dest_ip values(All_Traffic.dest_port) as dest_port + values(sourcetype) as sourcetype count from datamodel=Network_Traffic where (All_Traffic.action=allowed + All_Traffic.direction=outbound All_Traffic.dest_port=139 OR All_Traffic.dest_port=445 + OR All_Traffic.app="smb") by All_Traffic.src_ip | `drop_dm_object_name("All_Traffic")` + | eval match=case( cidrmatch("10.0.0.0/8" ,dest_ip) ,"1", cidrmatch("172.16.0.0/12" + ,dest_ip) ,"1", cidrmatch("192.168.0.0/16" ,dest_ip) ,"1", cidrmatch("100.64.0.0/10" + ,dest_ip) ,"1", 1=1,"0") | search match=0 | fields - match | `security_content_ctime(start_time)` + | `security_content_ctime(end_time)` | `detect_outbound_smb_traffic_filter`' +how_to_implement: 'This search also requires you to be ingesting your network traffic + and populating the Network_Traffic data model' known_false_positives: It is likely that the outbound Server Message Block (SMB) traffic is legitimate, if the company's internal networks are not well-defined in the Assets and Identity Framework. Categorize the internal CIDR blocks as `internal` in the @@ -44,7 +42,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: An outbound SMB connection from $src_ip$ in your infrastructure connecting to dest ip $dest_ip$ + message: An outbound SMB connection from $src_ip$ in your infrastructure connecting + to dest ip $dest_ip$ mitre_attack_id: - T1071.002 - T1071 @@ -75,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1071.002/outbound_smb_traffic/zeek_conn.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1071.002/outbound_smb_traffic/zeek_conn.log sourcetype: bro:conn:json - source: conn.log \ No newline at end of file + source: conn.log diff --git a/detections/network/detect_port_security_violation.yml b/detections/network/detect_port_security_violation.yml index 033fe3eed6..3df84d3efe 100644 --- a/detections/network/detect_port_security_violation.yml +++ b/detections/network/detect_port_security_violation.yml @@ -1,20 +1,17 @@ name: Detect Port Security Violation id: 2de3d5b8-a4fa-45c5-8540-6d071c194d24 -version: 1 -date: '2020-10-28' +version: 2 +date: '2024-05-13' author: Mikael Bjerkeland, Splunk status: experimental type: TTP -description: By enabling Port Security on a Cisco switch you can restrict input to - an interface by limiting and identifying MAC addresses of the workstations that - are allowed to access the port. When you assign secure MAC addresses to a secure - port, the port does not forward packets with source addresses outside the group - of defined addresses. If you limit the number of secure MAC addresses to one and - assign a single secure MAC address, the workstation attached to that port is assured - the full bandwidth of the port. If a port is configured as a secure port and the - maximum number of secure MAC addresses is reached, when the MAC address of a workstation - attempting to access the port is different from any of the identified secure MAC - addresses, a security violation occurs. +description: The following analytic detects port security violations on Cisco switches. + It leverages logs from Cisco network devices, specifically looking for events with + mnemonics indicating port security violations. This activity is significant because + it indicates an unauthorized device attempting to connect to a secured port, potentially + bypassing network access controls. If confirmed malicious, this could allow an attacker + to gain unauthorized access to the network, leading to data exfiltration, network + disruption, or further lateral movement within the environment. data_source: [] search: '`cisco_networks` (facility="PM" mnemonic="ERR_DISABLE" disable_cause="psecure-violation") OR (facility="PORT_SECURITY" mnemonic="PSECURE_VIOLATION" OR mnemonic="PSECURE_VIOLATION_VLAN") @@ -24,7 +21,8 @@ search: '`cisco_networks` (facility="PM" mnemonic="ERR_DISABLE" disable_cause="p | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `detect_port_security_violation_filter`' how_to_implement: This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with Port Security and Error Disable - for this to work (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/port_sec.html) + for this to work (see + https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/port_sec.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices. diff --git a/detections/network/detect_remote_access_software_usage_dns.yml b/detections/network/detect_remote_access_software_usage_dns.yml index 600cc85921..ee831d6810 100644 --- a/detections/network/detect_remote_access_software_usage_dns.yml +++ b/detections/network/detect_remote_access_software_usage_dns.yml @@ -1,23 +1,33 @@ name: Detect Remote Access Software Usage DNS id: a16b797d-e309-41bd-8ba0-5067dae2e4be -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-27' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when a known remote access software domains are contacted from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description: The following analytic detects DNS queries to known remote access software + domains from within the environment. It leverages DNS query logs mapped to the Network_Resolution + data model and cross-references them with a lookup table of remote access software + domains, such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant + as adversaries often use remote access tools to maintain persistent access to compromised + systems. If confirmed malicious, this could allow attackers to control systems remotely, + exfiltrate data, or further infiltrate the network, posing a severe security risk. data_source: - Sysmon EventID 22 -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(DNS.answer) as answer from datamodel=Network_Resolution by DNS.src DNS.query - | `drop_dm_object_name("DNS")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | lookup remote_access_software remote_domain AS query OUTPUT isutility, description as signature, comment_reference as desc, category - | eval dest = query - | search isutility = True - | `detect_remote_access_software_usage_dns_filter`' -how_to_implement: To implement this search, you must ingest logs that contain the DNS query and the source of the query. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the DNS logs. The logs must also be mapped to the `Network_Resolution` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(DNS.answer) as answer from datamodel=Network_Resolution by DNS.src + DNS.query | `drop_dm_object_name("DNS")` | `security_content_ctime(firstTime)` | + `security_content_ctime(lastTime)` | lookup remote_access_software remote_domain + AS query OUTPUT isutility, description as signature, comment_reference as desc, + category | eval dest = query | search isutility = True | `detect_remote_access_software_usage_dns_filter`' +how_to_implement: To implement this search, you must ingest logs that contain the + DNS query and the source of the query. These logs must be processed using the appropriate + Splunk Technology Add-ons that are specific to the DNS logs. The logs must also + be mapped to the `Network_Resolution` data model. Use the Splunk Common Information + Model (CIM) to normalize the field names and speed up the data modeling process. +known_false_positives: It is possible that legitimate remote access software is used + within the environment. Ensure that the lookup is reviewed and updated with any + additional remote access software that is used within the environment. references: - https://attack.mitre.org/techniques/T1219/ - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/ @@ -56,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational - sourcetype: XmlWinEventLog \ No newline at end of file + sourcetype: XmlWinEventLog diff --git a/detections/network/detect_remote_access_software_usage_traffic.yml b/detections/network/detect_remote_access_software_usage_traffic.yml index ffa8742233..b7b9c3d063 100644 --- a/detections/network/detect_remote_access_software_usage_traffic.yml +++ b/detections/network/detect_remote_access_software_usage_traffic.yml @@ -1,22 +1,33 @@ name: Detect Remote Access Software Usage Traffic id: 885ea672-07ee-475a-879e-60d28aa5dd42 -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-29' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when a known remote access software application traffic is detected from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. -data_source: +description: The following analytic detects network traffic associated with known + remote access software applications, such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. + It leverages Palo Alto traffic logs mapped to the Network_Traffic data model in + Splunk. This activity is significant because adversaries often use remote access + tools to maintain unauthorized access to compromised environments. If confirmed + malicious, this activity could allow attackers to control systems remotely, exfiltrate + data, or deploy additional malware, posing a severe threat to the organization's + security. +data_source: - Palo Alto Network Traffic -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(All_Traffic.dest_port) as dest_port latest(user) as user from datamodel=Network_Traffic by All_Traffic.src All_Traffic.dest, All_Traffic.app - | `drop_dm_object_name("All_Traffic")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | lookup remote_access_software remote_appid AS app OUTPUT isutility, description as signature, comment_reference as desc, category - | search isutility = True - | `detect_remote_access_software_usage_traffic_filter`' -how_to_implement: The following analytic was developed with Palo Alto traffic logs. Ensure that the logs are being ingested into Splunk and mapped to the Network_Traffic data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime values(All_Traffic.dest_port) as dest_port latest(user) as user from + datamodel=Network_Traffic by All_Traffic.src All_Traffic.dest, All_Traffic.app | + `drop_dm_object_name("All_Traffic")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | lookup remote_access_software remote_appid AS app OUTPUT isutility, description + as signature, comment_reference as desc, category | search isutility = True | `detect_remote_access_software_usage_traffic_filter`' +how_to_implement: The following analytic was developed with Palo Alto traffic logs. + Ensure that the logs are being ingested into Splunk and mapped to the Network_Traffic + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: It is possible that legitimate remote access software is used + within the environment. Ensure that the lookup is reviewed and updated with any + additional remote access software that is used within the environment. references: - https://attack.mitre.org/techniques/T1219/ - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/ @@ -30,14 +41,15 @@ tags: asset_type: Network confidence: 50 impact: 50 - message: Application traffic for a known remote access software [$signature$] was detected from $src$. + message: Application traffic for a known remote access software [$signature$] was + detected from $src$. mitre_attack_id: - T1219 observable: - name: src type: Hostname role: - - Victim + - Victim product: - Splunk Enterprise - Splunk Enterprise Security @@ -54,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_palo_traffic.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_palo_traffic.log source: screenconnect_palo_traffic - sourcetype: pan:traffic \ No newline at end of file + sourcetype: pan:traffic diff --git a/detections/network/detect_rogue_dhcp_server.yml b/detections/network/detect_rogue_dhcp_server.yml index 8c4cd4840e..a9254f53b9 100644 --- a/detections/network/detect_rogue_dhcp_server.yml +++ b/detections/network/detect_rogue_dhcp_server.yml @@ -1,13 +1,17 @@ name: Detect Rogue DHCP Server id: 6e1ada88-7a0d-4ac1-92c6-03d354686079 -version: 1 -date: '2020-08-11' +version: 2 +date: '2024-05-28' author: Mikael Bjerkeland, Splunk status: experimental type: TTP -description: By enabling DHCP Snooping as a Layer 2 Security measure on the organization's - network devices, we will be able to detect unauthorized DHCP servers handing out - DHCP leases to devices on the network (Man in the Middle attack). +description: The following analytic identifies the presence of unauthorized DHCP servers + on the network. It leverages logs from Cisco network devices with DHCP Snooping + enabled, specifically looking for events where DHCP leases are issued from untrusted + ports. This activity is significant because rogue DHCP servers can facilitate Man-in-the-Middle + attacks, leading to potential data interception and network disruption. If confirmed + malicious, this could allow attackers to redirect network traffic, capture sensitive + information, and compromise the integrity of the network. data_source: [] search: '`cisco_networks` facility="DHCP_SNOOPING" mnemonic="DHCP_SNOOPING_UNTRUSTED_PORT" | stats min(_time) AS firstTime max(_time) AS lastTime count values(message_type) diff --git a/detections/network/detect_software_download_to_network_device.yml b/detections/network/detect_software_download_to_network_device.yml index 579f9b5daf..50d3f0b30c 100644 --- a/detections/network/detect_software_download_to_network_device.yml +++ b/detections/network/detect_software_download_to_network_device.yml @@ -1,15 +1,18 @@ name: Detect Software Download To Network Device id: cc590c66-f65f-48f2-986a-4797244762f8 -version: 1 -date: '2020-10-28' +version: 2 +date: '2024-05-20' author: Mikael Bjerkeland, Splunk status: experimental type: TTP -description: Adversaries may abuse netbooting to load an unauthorized network device - operating system from a Trivial File Transfer Protocol (TFTP) server. TFTP boot - (netbooting) is commonly used by network administrators to load configuration-controlled - network device images from a centralized management server. Netbooting is one option - in the boot sequence and can be used to centralize, manage, and control device images. +description: The following analytic identifies unauthorized software downloads to + network devices via TFTP, FTP, or SSH/SCP. It detects this activity by analyzing + network traffic events on specific ports (69, 21, 22) from devices categorized as + network, router, or switch. This activity is significant because adversaries may + exploit netbooting to load unauthorized operating systems, potentially compromising + network integrity. If confirmed malicious, this could lead to unauthorized control + over network devices, enabling further attacks, data exfiltration, or persistent + access within the network. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where (All_Traffic.transport=udp AND diff --git a/detections/network/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.yml b/detections/network/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.yml index 8686639f9f..093cf15ce4 100644 --- a/detections/network/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.yml +++ b/detections/network/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.yml @@ -1,20 +1,17 @@ name: Detect suspicious DNS TXT records using pretrained model in DSDL id: 92f65c3a-968c-11ed-a1eb-0242ac120002 -version: 1 -date: '2023-01-15' +version: 2 +date: '2024-05-13' author: Abhinav Mishra, Kumar Sharad and Namratha Sreekanta, Splunk status: experimental type: Anomaly -description: The following analytic uses a pre trained deep learning model to detect - suspicious DNS TXT records. The model is trained independently and is then made - available for download. The DNS TXT records are categorized into commonly identified - types like email, verification, http using regular expressions https://www.tide-project.nl/blog/wtmc2020/. - The TXT records that do not match regular expressions for well known types are labeled - as 1 for "unknown/suspicious" and otherwise 0 for "not suspicious". The deep learning - model we have developed uses DNS TXT responses to analyze patterns of character - sequences to predict if a DNS TXT is suspicious or not. The higher the pred_is_unknown_proba, - the more likely the DNS TXT record is suspicious. The threshold for flagging a domain - as suspicious is set at 0.5. +description: The following analytic identifies suspicious DNS TXT records using a + pre-trained deep learning model. It leverages DNS response data from the Network + Resolution data model, categorizing TXT records into known types via regular expressions. + Records that do not match known patterns are flagged as suspicious. This activity + is significant as DNS TXT records can be used for data exfiltration or command-and-control + communication. If confirmed malicious, attackers could use these records to covertly + transfer data or receive instructions, posing a severe threat to network security. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Resolution where DNS.message_type=response AND @@ -22,7 +19,8 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime | rename answer as text | fields firstTime, lastTime, message_type,record_type,src,dest, text | apply detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl | rename predicted_is_unknown as is_suspicious_score | where is_suspicious_score > - 0.5 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | table src,dest,text,record_type, firstTime, lastTime,is_suspicious_score | `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl_filter`' + 0.5 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | + table src,dest,text,record_type, firstTime, lastTime,is_suspicious_score | `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl_filter`' how_to_implement: 'Steps to deploy detect suspicious DNS TXT records model into Splunk App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - `https://splunkbase.splunk.com/app/4607/` and the Network diff --git a/detections/network/detect_traffic_mirroring.yml b/detections/network/detect_traffic_mirroring.yml index 4ca226c2f4..6905c3e69a 100644 --- a/detections/network/detect_traffic_mirroring.yml +++ b/detections/network/detect_traffic_mirroring.yml @@ -1,15 +1,18 @@ name: Detect Traffic Mirroring id: 42b3b753-5925-49c5-9742-36fa40a73990 -version: 1 -date: '2020-10-28' +version: 2 +date: '2024-05-09' author: Mikael Bjerkeland, Splunk status: experimental type: TTP -description: Adversaries may leverage traffic mirroring in order to automate data - exfiltration over compromised network infrastructure. Traffic mirroring is a native - feature for some network devices and used for network analysis and may be configured - to duplicate traffic and forward to one or more destinations for analysis by a network - analyzer or other monitoring device. +description: The following analytic detects the initiation of traffic mirroring sessions + on Cisco network devices. It leverages logs with specific mnemonics and facilities + related to traffic mirroring, such as "ETH_SPAN_SESSION_UP" and "PKTCAP_START." + This activity is significant because adversaries may use traffic mirroring to exfiltrate + data by duplicating and forwarding network traffic to an external destination. If + confirmed malicious, this could allow attackers to capture sensitive information, + monitor network communications, and potentially compromise the integrity and confidentiality + of the network. data_source: [] search: '`cisco_networks` (facility="MIRROR" mnemonic="ETH_SPAN_SESSION_UP") OR (facility="SPAN" mnemonic="SESSION_UP") OR (facility="SPAN" mnemonic="PKTCAP_START") OR (mnemonic="CFGLOG_LOGGEDCMD" diff --git a/detections/network/detect_unauthorized_assets_by_mac_address.yml b/detections/network/detect_unauthorized_assets_by_mac_address.yml index aa47960e68..dd1bed53cc 100644 --- a/detections/network/detect_unauthorized_assets_by_mac_address.yml +++ b/detections/network/detect_unauthorized_assets_by_mac_address.yml @@ -1,16 +1,18 @@ name: Detect Unauthorized Assets by MAC address id: dcfd6b40-42f9-469d-a433-2e53f7489ff4 -version: 2 -date: '2017-09-13' +version: 3 +date: '2024-05-10' author: Bhavin Patel, Splunk status: experimental type: TTP -description: By populating the organization's assets within the assets_by_str.csv, - we will be able to detect unauthorized devices that are trying to connect with the - organization's network by inspecting DHCP request packets, which are issued by devices - when they attempt to obtain an IP address from the DHCP server. The MAC address - associated with the source of the DHCP request is checked against the list of known - devices, and reports on those that are not found. +description: The following analytic identifies unauthorized devices attempting to + connect to the organization's network by inspecting DHCP request packets. It detects + this activity by comparing the MAC addresses in DHCP requests against a list of + known authorized devices stored in the assets_by_str.csv file. This activity is + significant for a SOC because unauthorized devices can pose security risks, including + potential data breaches or network disruptions. If confirmed malicious, this activity + could allow an attacker to gain unauthorized network access, potentially leading + to further exploitation or data exfiltration. data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Network_Sessions where nodename=All_Sessions.DHCP All_Sessions.tag=dhcp by All_Sessions.dest_ip All_Sessions.dest_mac diff --git a/detections/network/detect_windows_dns_sigred_via_splunk_stream.yml b/detections/network/detect_windows_dns_sigred_via_splunk_stream.yml index 1c4263b7e7..6dc617e251 100644 --- a/detections/network/detect_windows_dns_sigred_via_splunk_stream.yml +++ b/detections/network/detect_windows_dns_sigred_via_splunk_stream.yml @@ -1,11 +1,18 @@ name: Detect Windows DNS SIGRed via Splunk Stream id: babd8d10-d073-11ea-87d0-0242ac130003 -version: 1 -date: '2020-07-28' +version: 2 +date: '2024-05-28' author: Shannon Davis, Splunk status: experimental type: TTP -description: "Ensure that the following prerequisites are met: (i) Both Splunk Stream DNS and TCP data are ingested. (ii) The macros 'stream:dns' and 'stream:tcp' are replaced with the appropriate configurations that are specific to your Splunk environment. The following analytic detects SIGRed exploitation attempts. SIGRed is a critical wormable vulnerability found in Windows DNS servers, known as CVE-2020-1350, which allows remote code execution. The detection is made by using an experimental search that focuses on identifying specific indicators that might suggest the presence of the SIGRed exploit such as DNS SIG records, KEY records, and TCP payloads greater than 65KB. This detection is important because it detects and responds to potential SIGRed exploitation attempts and minimizes the risk of a successful attack and its impact on the organization's infrastructure and data. False positives might occur due to the experimental nature of this analytic. Next steps include reviewing and investigating each case thoroughly given the potential for unauthorized Windows DNS server access, data breaches, and service disruptions. Additionally, you must stay updated with Microsoft's guidance on the SIGRed vulnerability." +description: "The following analytic detects attempts to exploit the SIGRed vulnerability + (CVE-2020-1350) in Windows DNS servers. It leverages Splunk Stream DNS and TCP data + to identify DNS SIG and KEY records, as well as TCP payloads exceeding 65KB. This + activity is significant because SIGRed is a critical wormable vulnerability that + allows remote code execution. If confirmed malicious, an attacker could gain unauthorized + access, execute arbitrary code, and potentially disrupt services, leading to severe + data breaches and infrastructure compromise. Immediate investigation and remediation + are crucial to mitigate these risks." data_source: [] search: '`stream_dns` | spath "query_type{}" | search "query_type{}" IN (SIG,KEY) | spath protocol_stack | search protocol_stack="ip:tcp:dns" | append [search `stream_tcp` diff --git a/detections/network/detect_windows_dns_sigred_via_zeek.yml b/detections/network/detect_windows_dns_sigred_via_zeek.yml index 88d788d304..6cffde76c0 100644 --- a/detections/network/detect_windows_dns_sigred_via_zeek.yml +++ b/detections/network/detect_windows_dns_sigred_via_zeek.yml @@ -1,12 +1,12 @@ name: Detect Windows DNS SIGRed via Zeek id: c5c622e4-d073-11ea-87d0-0242ac130003 -version: 1 -date: '2020-07-28' +version: 2 +date: '2024-05-23' author: Shannon Davis, Splunk status: experimental type: TTP description: |- - The following analytic detects the presence of SIGRed, a critical DNS vulnerability, using Zeek DNS and Zeek Conn data. SIGRed vulnerability allows attackers to run remote code on Windows DNS servers. By detecting SIGRed early, you can prevent further damage and protect the organization's network infrastructure. The detection is made by identifying specific DNS query types (SIG and KEY) in the Zeek DNS data and checks for high data transfer in the Zeek Conn data. If multiple instances of these indicators are found within a flow, it suggests the presence of SIGRed. The detection is important because it indicates a potential compromise of Windows DNS servers that suggests that an attacker might have gained unauthorized access to the DNS server and can run arbitrary code. The impact of this attack can be severe, leading to data exfiltration, unauthorized access, or disruption of critical services. Next steps include investigating the affected flow and taking immediate action to mitigate the vulnerability. This can involve patching the affected DNS server, isolating the server from the network, or conducting a forensic analysis to determine the extent of the compromise. + The following analytic detects the presence of SIGRed, a critical DNS vulnerability, using Zeek DNS and Zeek Conn data. It identifies specific DNS query types (SIG and KEY) and checks for high data transfer within a flow. This detection is significant because SIGRed allows attackers to execute remote code on Windows DNS servers, potentially leading to unauthorized access and control. If confirmed malicious, this activity could result in data exfiltration, service disruption, or further network compromise. Immediate investigation and mitigation, such as patching or isolating the affected server, are crucial. data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Network_Resolution where DNS.query_type IN (SIG,KEY) by DNS.flow_id | rename DNS.flow_id as flow_id diff --git a/detections/network/detect_zerologon_via_zeek.yml b/detections/network/detect_zerologon_via_zeek.yml index e279b2c858..d7885eff30 100644 --- a/detections/network/detect_zerologon_via_zeek.yml +++ b/detections/network/detect_zerologon_via_zeek.yml @@ -1,12 +1,12 @@ name: Detect Zerologon via Zeek id: bf7a06ec-f703-11ea-adc1-0242ac120002 -version: 1 -date: '2020-09-15' +version: 2 +date: '2024-05-28' author: Shannon Davis, Splunk status: experimental type: TTP description: |- - The following analytic detects attempts to exploit the Zerologon CVE-2020-1472 vulnerability through Zeek RPC. By detecting attempts to exploit the Zerologon vulnerability through Zeek RPC, SOC analysts can identify potential threats earlier and take appropriate action to mitigate the risks. This detection is made by a Splunk query that looks for specific Zeek RPC operations, including NetrServerPasswordSet2, NetrServerReqChallenge, and NetrServerAuthenticate3, which are aggregated by source and destination IP address and time. This detection is important because it suggests that an attacker is attempting to exploit the Zerologon vulnerability to gain unauthorized access to the domain controller. Zerologon vulnerability is a critical vulnerability that allows attackers to take over domain controllers without authentication, leading to a complete takeover of an organization's IT infrastructure. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other devastating outcomes. False positives might occur since legitimate Zeek RPC activity can trigger the analytic. Next steps include reviewing the identified source and destination IP addresses and the specific RPC operations used. Capture and inspect any relevant on-disk artifacts, and review concurrent processes to identify the attack source upon triage . + The following analytic detects attempts to exploit the Zerologon CVE-2020-1472 vulnerability via Zeek RPC. It leverages Zeek DCE-RPC data to identify specific operations: NetrServerPasswordSet2, NetrServerReqChallenge, and NetrServerAuthenticate3. This activity is significant because it indicates an attempt to gain unauthorized access to a domain controller, potentially leading to a complete takeover of an organization's IT infrastructure. If confirmed malicious, the impact could be severe, including data theft, ransomware deployment, or other devastating outcomes. Immediate investigation of the identified IP addresses and RPC operations is crucial. data_source: [] search: '`zeek_rpc` operation IN (NetrServerPasswordSet2,NetrServerReqChallenge,NetrServerAuthenticate3) | bin span=5m _time | stats values(operation) dc(operation) as opscount count(eval(operation=="NetrServerReqChallenge")) diff --git a/detections/network/dns_query_length_outliers___mltk.yml b/detections/network/dns_query_length_outliers___mltk.yml index 06ab3e2671..30677e8872 100644 --- a/detections/network/dns_query_length_outliers___mltk.yml +++ b/detections/network/dns_query_length_outliers___mltk.yml @@ -19,7 +19,7 @@ search: '| tstats `security_content_summariesonly` count min(_time) as start_tim | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | eval query_length = len(query) | apply dns_query_pdfmodel threshold=0.01 | rename "IsOutlier(query_length)" as isOutlier | search isOutlier > 0 | sort -query_length | table start_time end_time - query record_type count src dest query_length | `dns_query_length_outliers___mltk_filter` ' + query record_type count src dest query_length | `dns_query_length_outliers___mltk_filter`' how_to_implement: "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your diff --git a/detections/network/dns_query_length_with_high_standard_deviation.yml b/detections/network/dns_query_length_with_high_standard_deviation.yml index 32a4515f36..db3f32e5c8 100644 --- a/detections/network/dns_query_length_with_high_standard_deviation.yml +++ b/detections/network/dns_query_length_with_high_standard_deviation.yml @@ -1,14 +1,19 @@ name: DNS Query Length With High Standard Deviation id: 1a67f15a-f4ff-4170-84e9-08cf6f75d6f5 -version: 5 -date: '2024-02-14' +version: 6 +date: '2024-05-15' author: Bhavin Patel, Splunk status: production type: Anomaly -description: This search allows you to identify DNS requests and compute the standard - deviation on the length of the names being resolved, then filter on two times the - standard deviation to show you those queries that are unusually large for your environment. -data_source: +description: The following analytic identifies DNS queries with unusually large lengths + by computing the standard deviation of query lengths and filtering those exceeding + twice the standard deviation. It leverages DNS query data from the Network_Resolution + data model, focusing on the length of the domain names being resolved. This activity + is significant as unusually long DNS queries can indicate data exfiltration or command-and-control + communication attempts. If confirmed malicious, this activity could allow attackers + to stealthily transfer data or maintain persistent communication channels within + the network. +data_source: - Sysmon EventID 22 search: '| tstats `security_content_summariesonly` count from datamodel=Network_Resolution where NOT DNS.record_type IN("Pointer","PTR") by DNS.query host| `drop_dm_object_name("DNS")` @@ -51,6 +56,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/long_dns_queries/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/long_dns_queries/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog diff --git a/detections/network/excessive_dns_failures.yml b/detections/network/excessive_dns_failures.yml index 2aa0235411..81820f3276 100644 --- a/detections/network/excessive_dns_failures.yml +++ b/detections/network/excessive_dns_failures.yml @@ -22,7 +22,7 @@ search: '| tstats `security_content_summariesonly` count from datamodel=Network_ domain as query OUTPUT rank | where isnull(rank) | eventstats max(count) as mc by src reply_code | eval mode_query=if(count=mc, query, null()) | stats sum(count) as count values(mode_query) as query values(mc) as max_query_count by src reply_code - | where count>50 | `get_asset(src)` | `excessive_dns_failures_filter` ' + | where count>50 | `get_asset(src)` | `excessive_dns_failures_filter`' how_to_implement: To successfully implement this search you must ensure that DNS data is populating the Network_Resolution data model. known_false_positives: It is possible legitimate traffic can trigger this rule. Please diff --git a/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml b/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml index 4c47cf932f..2cb77c3b2f 100644 --- a/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml +++ b/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml @@ -1,16 +1,19 @@ name: F5 BIG-IP iControl REST Vulnerability CVE-2022-1388 id: bb1c2c30-107a-4e56-a4b9-1f7022867bfe -version: 1 -date: '2022-05-10' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies a recent unauthenticated remote code - execution vulnerablity against the F5 BIG-IP iControl REST API. The analytic identifies - the URI path found in the POCs and the HTTP Method of POST. In addition, the request - header will have the commands that may be executed in fields utilcmdargs and the - auth field of X-F5-Auth-Token, which may have a random base64 encoded value. -data_source: +description: The following analytic detects attempts to exploit the F5 BIG-IP iControl + REST API vulnerability (CVE-2022-1388) for unauthenticated remote code execution. + It identifies suspicious URI paths and POST HTTP methods, along with specific request + headers containing potential commands in the `utilcmdargs` field and a random base64 + encoded value in the `X-F5-Auth-Token` field. This activity is significant as it + targets a critical vulnerability that can allow attackers to execute arbitrary commands + on the affected system. If confirmed malicious, this could lead to full system compromise + and unauthorized access to sensitive data. +data_source: - Palo Alto Network Threat search: '| tstats count from datamodel=Web where Web.url="*/mgmt/tm/util/bash*" Web.http_method="POST" by Web.http_user_agent Web.http_method, Web.url,Web.url_length Web.src, Web.dest @@ -62,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/f5/f5.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/f5/f5.log source: pan:threat sourcetype: pan:threat update_timestamp: true diff --git a/detections/network/high_volume_of_bytes_out_to_url.yml b/detections/network/high_volume_of_bytes_out_to_url.yml index 453906056d..44ca220d6a 100644 --- a/detections/network/high_volume_of_bytes_out_to_url.yml +++ b/detections/network/high_volume_of_bytes_out_to_url.yml @@ -1,18 +1,32 @@ name: High Volume of Bytes Out to Url id: c8a6b56d-16dd-4e9c-b4bd-527742ead98d -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-24' author: Bhavin Patel, Splunk -data_source: +data_source: - Nginx Access type: Anomaly status: production -description: The following analytic detects high volume of bytes out (greater than 1GB) to a URL within 2 mins of time window. This may be - indicative of an attacker attempting to exfiltrate data. The search applies a fundamental threshold for detecting significant web uploads. This approach aims to identify potential data exfiltration activities by malware or malevolent insiders. View the alert for $dest$ to investigate further. -search: '| tstats `security_content_summariesonly` count sum(Web.bytes_out) as sum_bytes_out values(Web.user) as user values(Web.app) as app values(Web.dest) as dest from datamodel=Web by _time span=2m Web.url Web.src sourcetype | search sum_bytes_out > 1070000000 | `drop_dm_object_name("Web")`| `high_volume_of_bytes_out_to_url_filter`' +description: The following analytic detects a high volume of outbound web traffic, + specifically over 1GB of data sent to a URL within a 2-minute window. It leverages + the Web data model to identify significant uploads by analyzing the sum of bytes + out. This activity is significant as it may indicate potential data exfiltration + by malware or malicious insiders. If confirmed as malicious, this behavior could + lead to unauthorized data transfer, resulting in data breaches and loss of sensitive + information. Immediate investigation is required to determine the legitimacy of + the transfer and mitigate any potential threats. +search: '| tstats `security_content_summariesonly` count sum(Web.bytes_out) as sum_bytes_out + values(Web.user) as user values(Web.app) as app values(Web.dest) as dest from datamodel=Web + by _time span=2m Web.url Web.src sourcetype | search sum_bytes_out > 1070000000 + | `drop_dm_object_name("Web")`| `high_volume_of_bytes_out_to_url_filter`' how_to_implement: To successfully implement this search you need to be ingesting information - on Web traffic that include fields relavent for traffic into the `Web` datamodel. Please adjust the threshold for the sum of bytes out as per your environment and user behavior. -known_false_positives: This search may trigger false positives if there is a legitimate reason for a high volume of bytes out to a URL. We recommend to investigate these findings. Consider updating the filter macro to exclude the applications that are relevant to your environment. + on Web traffic that include fields relavent for traffic into the `Web` datamodel. + Please adjust the threshold for the sum of bytes out as per your environment and + user behavior. +known_false_positives: This search may trigger false positives if there is a legitimate + reason for a high volume of bytes out to a URL. We recommend to investigate these + findings. Consider updating the filter macro to exclude the applications that are + relevant to your environment. references: - https://attack.mitre.org/techniques/T1567/ - https://www.trendmicro.com/en_us/research/20/l/pawn-storm-lack-of-sophistication-as-a-strategy.html @@ -23,7 +37,8 @@ tags: asset_type: Endpoint confidence: 30 impact: 30 - message: A high volume of bytes out to a URL $url$ was detected from src $src$ to dest $dest$. + message: A high volume of bytes out to a URL $url$ was detected from src $src$ to + dest $dest$. mitre_attack_id: - T1567 observable: @@ -52,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1567/web_upload_nginx/web_upload_nginx.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1567/web_upload_nginx/web_upload_nginx.log source: /var/log/nginx/access.log sourcetype: nginx:plus:kv diff --git a/detections/network/multiple_archive_files_http_post_traffic.yml b/detections/network/multiple_archive_files_http_post_traffic.yml index 72fb45a5ae..9120c894ba 100644 --- a/detections/network/multiple_archive_files_http_post_traffic.yml +++ b/detections/network/multiple_archive_files_http_post_traffic.yml @@ -1,24 +1,20 @@ name: Multiple Archive Files Http Post Traffic id: 4477f3ea-a28f-11eb-b762-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-16' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is designed to detect high frequency of archive files data - exfiltration through HTTP POST method protocol. This are one of the common techniques - used by APT or trojan spy after doing the data collection like screenshot, recording, - sensitive data to the infected machines. The attacker may execute archiving command - to the collected data, save it a temp folder with a hidden attribute then send it - to its C2 through HTTP POST. Sometimes adversaries will rename the archive files - or encode/encrypt to cover their tracks. This detection can detect a renamed archive - files transfer to HTTP POST since it checks the request body header. Unfortunately - this detection cannot support archive that was encrypted or encoded before doing - the exfiltration. -data_source: +description: The following analytic detects the high-frequency exfiltration of archive + files via HTTP POST requests. It leverages HTTP stream logs to identify specific + archive file headers within the request body. This activity is significant as it + often indicates data exfiltration by APTs or trojan spyware after data collection. + If confirmed malicious, this behavior could lead to the unauthorized transfer of + sensitive data to an attacker’s command and control server, potentially resulting + in severe data breaches and loss of confidential information. +data_source: - Splunk Stream HTTP -search: '`stream_http` http_method=POST |eval archive_hdr1=substr(form_data,1,2) | eval archive_hdr2 = substr(form_data,1,4) |stats values(form_data) as http_request_body min(_time) as firstTime max(_time) as lastTime count by src_ip dest_ip http_method http_user_agent uri_path url bytes_in bytes_out archive_hdr1 archive_hdr2 |where count >20 AND (archive_hdr1 = "7z" OR archive_hdr1 = "PK" OR archive_hdr2="Rar!") | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `multiple_archive_files_http_post_traffic_filter` - ' +search: '`stream_http` http_method=POST |eval archive_hdr1=substr(form_data,1,2) | eval archive_hdr2 = substr(form_data,1,4) |stats values(form_data) as http_request_body min(_time) as firstTime max(_time) as lastTime count by src_ip dest_ip http_method http_user_agent uri_path url bytes_in bytes_out archive_hdr1 archive_hdr2 |where count >20 AND (archive_hdr1 = "7z" OR archive_hdr1 = "PK" OR archive_hdr2="Rar!") | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `multiple_archive_files_http_post_traffic_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled in stream @@ -35,7 +31,8 @@ tags: asset_type: Endpoint confidence: 50 impact: 50 - message: A http post $http_method$ sending packet with possible archive bytes header in uri path $uri_path$ + message: A http post $http_method$ sending packet with possible archive bytes header + in uri path $uri_path$ mitre_attack_id: - T1048.003 - T1048 @@ -68,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/archive_http_post/stream_http_events.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/archive_http_post/stream_http_events.log source: stream sourcetype: stream:http diff --git a/detections/network/ngrok_reverse_proxy_on_network.yml b/detections/network/ngrok_reverse_proxy_on_network.yml index cde26d4e83..d1b33bc26b 100644 --- a/detections/network/ngrok_reverse_proxy_on_network.yml +++ b/detections/network/ngrok_reverse_proxy_on_network.yml @@ -1,16 +1,19 @@ name: Ngrok Reverse Proxy on Network id: 5790a766-53b8-40d3-a696-3547b978fcf0 -version: 1 -date: '2022-11-16' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the 4 most common Ngrok used domains - based on DNS queries under the Network Resolution datamodel. It's possible these - domains may be ran against the Web datamodel or ran with a direct query across network/proxy - traffic. The sign of someone using Ngrok is not malicious, however, more recenctly - it has become an adversary tool. -data_source: +description: The following analytic detects DNS queries to common Ngrok domains, indicating + potential use of the Ngrok reverse proxy tool. It leverages the Network Resolution + datamodel to identify queries to domains such as "*.ngrok.com" and "*.ngrok.io". + While Ngrok usage is not inherently malicious, it has been increasingly adopted + by adversaries for covert communication and data exfiltration. If confirmed malicious, + this activity could allow attackers to bypass network defenses, establish persistent + connections, and exfiltrate sensitive data, posing a significant threat to the network's + security. +data_source: - Sysmon EventID 22 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Resolution where DNS.query IN ("*.ngrok.com","*.ngrok.io", @@ -52,7 +55,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/windows-sysmon.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1572/ngrok/windows-sysmon.log source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational sourcetype: xmlwineventlog update_timestamp: true diff --git a/detections/network/plain_http_post_exfiltrated_data.yml b/detections/network/plain_http_post_exfiltrated_data.yml index 1fbab86301..d44da6f3e8 100644 --- a/detections/network/plain_http_post_exfiltrated_data.yml +++ b/detections/network/plain_http_post_exfiltrated_data.yml @@ -1,20 +1,24 @@ name: Plain HTTP POST Exfiltrated Data id: e2b36208-a364-11eb-8909-acde48001122 -version: 2 -date: '2023-11-07' +version: 3 +date: '2024-05-26' author: Teoderick Contreras, Splunk status: production type: TTP -description: This search is to detect potential plain HTTP POST method data exfiltration. - This network traffic is commonly used by trickbot, trojanspy, keylogger or APT adversary - where arguments or commands are sent in plain text to the remote C2 server using - HTTP POST method as part of data exfiltration. -data_source: +description: The following analytic detects potential data exfiltration using plain + HTTP POST requests. It leverages network traffic logs, specifically monitoring the + `stream_http` data source for POST methods containing suspicious form data such + as "wermgr.exe" or "svchost.exe". This activity is significant because it is commonly + associated with malware like Trickbot, trojans, keyloggers, or APT adversaries, + which use plain text HTTP POST requests to communicate with remote C2 servers. If + confirmed malicious, this activity could lead to unauthorized data exfiltration, + compromising sensitive information and potentially leading to further network infiltration. +data_source: - Splunk Stream HTTP search: '`stream_http` http_method=POST form_data IN ("*wermgr.exe*","*svchost.exe*", "*name=\"proclist\"*","*ipconfig*", "*name=\"sysinfo\"*", "*net view*") |stats values(form_data) - as http_request_body min(_time) as firstTime max(_time) as lastTime count by src_ip dest_ip http_method - http_user_agent uri_path url bytes_in bytes_out | `security_content_ctime(firstTime)` + as http_request_body min(_time) as firstTime max(_time) as lastTime count by src_ip + dest_ip http_method http_user_agent uri_path url bytes_in bytes_out | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `plain_http_post_exfiltrated_data_filter`' how_to_implement: To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make @@ -29,7 +33,8 @@ tags: asset_type: Endpoint confidence: 90 impact: 70 - message: A http post $http_method$ sending packet with plain text of information in uri path $uri_path$ + message: A http post $http_method$ sending packet with plain text of information + in uri path $uri_path$ mitre_attack_id: - T1048.003 - T1048 @@ -55,6 +60,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/plain_exfil_data/stream_http_events.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048.003/plain_exfil_data/stream_http_events.log source: stream sourcetype: stream:http diff --git a/detections/network/prohibited_network_traffic_allowed.yml b/detections/network/prohibited_network_traffic_allowed.yml index 0629d51e5c..4c1c265a7e 100644 --- a/detections/network/prohibited_network_traffic_allowed.yml +++ b/detections/network/prohibited_network_traffic_allowed.yml @@ -1,15 +1,18 @@ name: Prohibited Network Traffic Allowed id: ce5a0962-849f-4720-a678-753fe6674479 -version: 2 -date: '2024-02-27' +version: 3 +date: '2024-05-11' author: Rico Valdez, Splunk status: production type: TTP -description: The following analytic detects instances where network traffic, specifically identified by port and transport layer protocol as - prohibited in the "lookup_interesting_ports" table, is allowed according to the Network_Traffic data model. It operates by cross-referencing - traffic data against predefined security policies to identify discrepancies indicative of potential misconfigurations or policy violations. - This detection is crucial for a Security Operations Center (SOC) as it highlights potential security breaches or misconfigured network devices - that could allow unauthorized access or data exfiltration, directly impacting the organization's security posture. +description: The following analytic detects instances where network traffic, identified + by port and transport layer protocol as prohibited in the "lookup_interesting_ports" + table, is allowed. It uses the Network_Traffic data model to cross-reference traffic + data against predefined security policies. This activity is significant for a SOC + as it highlights potential misconfigurations or policy violations that could lead + to unauthorized access or data exfiltration. If confirmed malicious, this could + allow attackers to bypass network defenses, leading to potential data breaches and + compromising the organization's security posture. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where All_Traffic.action = allowed by @@ -60,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048/ftp_connection/zeek_conn.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1048/ftp_connection/zeek_conn.log sourcetype: bro:conn:json - source: conn.log \ No newline at end of file + source: conn.log diff --git a/detections/network/protocol_or_port_mismatch.yml b/detections/network/protocol_or_port_mismatch.yml index 1e6d9ac2e7..7651f15b0c 100644 --- a/detections/network/protocol_or_port_mismatch.yml +++ b/detections/network/protocol_or_port_mismatch.yml @@ -1,16 +1,18 @@ name: Protocol or Port Mismatch id: 54dc1265-2f74-4b6d-b30d-49eb506a31b3 -version: 2 -date: '2020-07-21' +version: 3 +date: '2024-05-29' author: Rico Valdez, Splunk status: experimental type: Anomaly -description: This search looks for network traffic on common ports where a higher - layer protocol does not match the port that is being used. For example, this search - should identify cases where protocols other than HTTP are running on TCP port 80. - This can be used by attackers to circumvent firewall restrictions, or as an attempt - to hide malicious communications over ports and protocols that are typically allowed - and not well inspected. +description: The following analytic identifies network traffic where the higher layer + protocol does not match the expected port, such as non-HTTP traffic on TCP port + 80. It leverages data from network traffic inspection technologies like Bro or Palo + Alto Networks firewalls. This activity is significant because it may indicate attempts + to bypass firewall restrictions or conceal malicious communications. If confirmed + malicious, this behavior could allow attackers to evade detection, maintain persistence, + or exfiltrate data through commonly allowed ports, posing a significant threat to + network security. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where (All_Traffic.app=dns NOT All_Traffic.dest_port=53) diff --git a/detections/network/protocols_passing_authentication_in_cleartext.yml b/detections/network/protocols_passing_authentication_in_cleartext.yml index 598878b632..b46553a399 100644 --- a/detections/network/protocols_passing_authentication_in_cleartext.yml +++ b/detections/network/protocols_passing_authentication_in_cleartext.yml @@ -1,15 +1,18 @@ name: Protocols passing authentication in cleartext id: 6923cd64-17a0-453c-b945-81ac2d8c6db9 -version: 3 -date: '2021-08-19' +version: 4 +date: '2024-05-29' author: Rico Valdez, Splunk status: experimental type: TTP -description: The following analytic identifies cleartext protocols at risk of leaking - sensitive information. Currently, this consists of legacy protocols such as telnet - (port 23), POP3 (port 110), IMAP (port 143), and non-anonymous FTP (port 21) sessions. - While some of these protocols may be used over SSL, they typically are found on - different assigned ports in those instances. +description: The following analytic identifies the use of cleartext protocols that + risk leaking sensitive information. It detects network traffic on legacy protocols + such as Telnet (port 23), POP3 (port 110), IMAP (port 143), and non-anonymous FTP + (port 21). The detection leverages the Network_Traffic data model to identify TCP + traffic on these ports. Monitoring this activity is crucial as it can expose credentials + and other sensitive data to interception. If confirmed malicious, attackers could + capture authentication details, leading to unauthorized access and potential data + breaches. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where All_Traffic.action!=blocked AND diff --git a/detections/network/remote_desktop_network_traffic.yml b/detections/network/remote_desktop_network_traffic.yml index c73ed1fef3..90269189f7 100644 --- a/detections/network/remote_desktop_network_traffic.yml +++ b/detections/network/remote_desktop_network_traffic.yml @@ -1,22 +1,25 @@ name: Remote Desktop Network Traffic id: 272b8407-842d-4b3d-bead-a704584003d3 -version: 4 -date: '2024-02-27' +version: 5 +date: '2024-05-29' author: David Dorsey, Splunk status: production type: Anomaly -description: The following analytic detects unusual Remote Desktop Protocol (RDP) traffic on TCP/3389, the default RDP port. - It identifies this activity by filtering out traffic from known RDP sources and destinations, focusing on atypical RDP connections within the network. - This detection is crucial for a Security Operations Center (SOC) as unauthorized RDP access can indicate an attacker's attempt to gain control over - networked systems, potentially leading to data theft, ransomware deployment, or further network compromise. - The impact of such unauthorized access can be significant, ranging from data breaches to complete system and network control loss. +description: The following analytic detects unusual Remote Desktop Protocol (RDP) + traffic on TCP/3389 by filtering out known RDP sources and destinations, focusing + on atypical connections within the network. This detection leverages network traffic + data to identify potentially unauthorized RDP access. Monitoring this activity is + crucial for a SOC as unauthorized RDP access can indicate an attacker's attempt + to control networked systems, leading to data theft, ransomware deployment, or further + network compromise. If confirmed malicious, this activity could result in significant + data breaches or complete system and network control loss. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where All_Traffic.dest_port=3389 AND All_Traffic.dest_category!=common_rdp_destination AND All_Traffic.src_category!=common_rdp_source AND All_Traffic.action="allowed" by All_Traffic.src All_Traffic.dest All_Traffic.dest_port | `drop_dm_object_name("All_Traffic")` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` - | `remote_desktop_network_traffic_filter` ' + | `remote_desktop_network_traffic_filter`' how_to_implement: To successfully implement this search you need to identify systems that commonly originate remote desktop traffic and that commonly receive remote desktop traffic. You can use the included support search "Identify Systems Creating @@ -68,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.001/remote_desktop_connection/zeek_conn.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.001/remote_desktop_connection/zeek_conn.log sourcetype: bro:conn:json - source: conn.log \ No newline at end of file + source: conn.log diff --git a/detections/network/smb_traffic_spike.yml b/detections/network/smb_traffic_spike.yml index b61c4bc0c7..ab999aa0dc 100644 --- a/detections/network/smb_traffic_spike.yml +++ b/detections/network/smb_traffic_spike.yml @@ -1,12 +1,12 @@ name: SMB Traffic Spike id: 7f5fb3e1-4209-4914-90db-0ec21b936378 -version: 3 -date: '2020-07-22' +version: 4 +date: '2024-05-27' author: David Dorsey, Splunk status: experimental type: Anomaly description: |- - The following analytic detects spikes in the number of Server Message Block (SMB) traffic connections. SMB is a network protocol used for sharing files, printers, and other resources between computers. This detection is made by a Splunk query that looks for SMB traffic connections on ports 139 and 445, as well as connections using the SMB application. The query calculates the average and standard deviation of the number of SMB connections over the past 70 minutes, and identifies any sources that exceed two standard deviations from the average. This helps to filter out false positives caused by normal fluctuations in SMB traffic. This detection is important because it identifies potential SMB-based attacks, such as ransomware or data theft, which often involve a large number of SMB connections. This suggests that an attacker is attempting to exfiltrate data or spread malware within the network. Next steps include investigating the source of the traffic and determining if it is malicious. This can involve reviewing network logs, capturing and analyzing any relevant network packets, and correlating with other security events to identify the attack source and mitigate the risk. + The following analytic detects spikes in Server Message Block (SMB) traffic connections, which are used for sharing files and resources between computers. It leverages network traffic logs to monitor connections on ports 139 and 445, and SMB application usage. By calculating the average and standard deviation of SMB connections over the past 70 minutes, it identifies sources exceeding two standard deviations from the average. This activity is significant as it may indicate potential SMB-based attacks, such as ransomware or data theft. If confirmed malicious, attackers could exfiltrate data or spread malware within the network. data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Network_Traffic where All_Traffic.dest_port=139 OR All_Traffic.dest_port=445 OR All_Traffic.app=smb @@ -15,7 +15,7 @@ search: '| tstats `security_content_summariesonly` count from datamodel=Network_ "-70m@m"), count, null))) as count avg(eval(if(_time upperBound - AND num_data_samples >=50, 1, 0) | where isOutlier=1 | table src count | `smb_traffic_spike_filter` ' + AND num_data_samples >=50, 1, 0) | where isOutlier=1 | table src count | `smb_traffic_spike_filter`' how_to_implement: This search requires you to be ingesting your network traffic logs and populating the `Network_Traffic` data model. known_false_positives: A file server may experience high-demand loads that could cause diff --git a/detections/network/smb_traffic_spike___mltk.yml b/detections/network/smb_traffic_spike___mltk.yml index cf81e5e112..5f2317f4e6 100644 --- a/detections/network/smb_traffic_spike___mltk.yml +++ b/detections/network/smb_traffic_spike___mltk.yml @@ -19,7 +19,7 @@ search: '| tstats `security_content_summariesonly` count values(All_Traffic.dest _time span=1h, All_Traffic.src | eval HourOfDay=strftime(_time, "%H") | eval DayOfWeek=strftime(_time, "%A") | `drop_dm_object_name(All_Traffic)` | apply smb_pdfmodel threshold=0.001 | rename "IsOutlier(count)" as isOutlier | search isOutlier > 0 | sort -count | - table _time src dest port count | `smb_traffic_spike___mltk_filter` ' + table _time src dest port count | `smb_traffic_spike___mltk_filter`' how_to_implement: "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Traffic data model. In addition, the latest version of Machine Learning Toolkit (MLTK) must be installed on your search heads, diff --git a/detections/network/splunk_identified_ssl_tls_certificates.yml b/detections/network/splunk_identified_ssl_tls_certificates.yml index 765ac454f1..ccf832b111 100644 --- a/detections/network/splunk_identified_ssl_tls_certificates.yml +++ b/detections/network/splunk_identified_ssl_tls_certificates.yml @@ -1,15 +1,19 @@ name: Splunk Identified SSL TLS Certificates id: 620fbb89-86fd-4e2e-925f-738374277586 -version: 1 -date: '2022-05-25' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: Hunting -description: The following analytic uses tags of SSL, TLS and certificate to identify - the usage of the Splunk default certificates being utilized in the environment. - Recommended guidance is to utilize valid TLS certificates which documentation may - be found in Splunk Docs - https://docs.splunk.com/Documentation/Splunk/8.2.6/Security/AboutsecuringyourSplunkconfigurationwithSSL. -data_source: +description: The following analytic identifies the usage of Splunk default SSL/TLS + certificates within the environment. It leverages tags such as SSL, TLS, and certificate + to detect these default certificates by examining the ssl_issuer_common_name field. + This activity is significant because using default certificates can expose the environment + to potential security risks, as they are not unique and can be easily exploited. + If confirmed malicious, attackers could intercept or manipulate data, leading to + unauthorized access or data breaches. It is recommended to replace default certificates + with valid, unique TLS certificates to enhance security. +data_source: - Splunk Stream TCP search: tag IN (ssl, tls, certificate) ssl_issuer_common_name=*splunk* | stats values(src) AS "Host(s) with Default Cert" count by ssl_issuer ssl_subject_common_name ssl_subject_organization @@ -60,7 +64,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1040/ssltls/ssl_splunk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1040/ssltls/ssl_splunk.log source: stream:tcp sourcetype: stream:tcp update_timestamp: true diff --git a/detections/network/ssl_certificates_with_punycode.yml b/detections/network/ssl_certificates_with_punycode.yml index be31efed7a..15f10eb50a 100644 --- a/detections/network/ssl_certificates_with_punycode.yml +++ b/detections/network/ssl_certificates_with_punycode.yml @@ -1,17 +1,16 @@ name: SSL Certificates with Punycode id: 696694df-5706-495a-81f2-79501fa11b90 -version: 1 -date: '2022-11-01' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: experimental type: Hunting -description: The following analytic utilizes the Certificates Datamodel to look for - punycode domains, starting with xn--, found in the SSL issuer email domain. The - presence of punycode here does not equate to evil, therefore we need to decode the - punycode to determine what it translates to. Remove the CyberChef recipe as needed - and decode manually. Note that this is not the exact location of the malicious punycode - to trip CVE-2022-3602, but a method to at least identify fuzzing occurring on these - email paths. What does evil look like? it will start with +description: The following analytic detects SSL certificates with Punycode domains + in the SSL issuer email domain, identified by the prefix "xn--". It leverages the + Certificates Datamodel to flag these domains and uses CyberChef for decoding. This + activity is significant as Punycode can be used for domain spoofing and phishing + attacks. If confirmed malicious, attackers could deceive users and systems, potentially + leading to unauthorized access and data breaches. data_source: [] search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Certificates.All_Certificates by All_Certificates.SSL.ssl_issuer_email_domain diff --git a/detections/network/tor_traffic.yml b/detections/network/tor_traffic.yml index 769d5af7e7..200eddc4f1 100644 --- a/detections/network/tor_traffic.yml +++ b/detections/network/tor_traffic.yml @@ -1,23 +1,34 @@ name: TOR Traffic id: ea688274-9c06-4473-b951-e4cb7a5d7a45 -version: 3 -date: '2023-09-20' +version: 4 +date: '2024-05-29' author: David Dorsey, Bhavin Patel, Splunk status: production type: TTP -description: The following analytic looks for allowed network traffic to The Onion Router(TOR), a benign anonymity network which can be abused for a variety of nefarious purposes. Detecting Tor traffic is paramount for upholding network security and mitigating potential threats. Tor's capacity to provide users with anonymity has been exploited by cybercriminals for activities like hacking, data breaches, and illicit content dissemination. Additionally, organizations must monitor Tor usage within their networks to ensure compliance with policies and regulations, as it can bypass conventional monitoring and filtering measures. Lastly, the ability to identify Tor traffic empowers security teams to promptly investigate and address potential security incidents, fortifying the protection of sensitive data and preserving the integrity of the network environment. -data_source: +description: The following analytic identifies allowed network traffic to The Onion + Router (TOR), an anonymity network often exploited for malicious activities. It + leverages data from Next Generation Firewalls, using the Network_Traffic data model + to detect traffic where the application is TOR and the action is allowed. This activity + is significant as TOR can be used to bypass conventional monitoring, facilitating + hacking, data breaches, and illicit content dissemination. If confirmed malicious, + this could lead to unauthorized access, data exfiltration, and severe compliance + violations, compromising the integrity and security of the network. +data_source: - Palo Alto Network Traffic search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Network_Traffic where All_Traffic.app=tor AND All_Traffic.action=allowed by All_Traffic.src_ip All_Traffic.dest_ip All_Traffic.dest_port All_Traffic.action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Traffic")` | `tor_traffic_filter`' -how_to_implement: In order to properly run this search, Splunk needs to ingest data from Next Generation Firewalls like Palo Alto Networks Firewalls or other network control devices that mediate the traffic allowed into an environment. This is necessary so that the search can identify an 'action' taken on the traffic of interest. The search requires the Network_Traffic data model to be populated. +how_to_implement: In order to properly run this search, Splunk needs to ingest data + from Next Generation Firewalls like Palo Alto Networks Firewalls or other network + control devices that mediate the traffic allowed into an environment. This is necessary + so that the search can identify an 'action' taken on the traffic of interest. The + search requires the Network_Traffic data model to be populated. known_false_positives: None at this time -references: - - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRtCAK - - https://unit42.paloaltonetworks.com/tor-traffic-enterprise-networks/#:~:text=For%20enterprises%20concerned%20about%20the,the%20most%20important%20security%20risks. +references: +- https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRtCAK +- https://unit42.paloaltonetworks.com/tor-traffic-enterprise-networks/#:~:text=For%20enterprises%20concerned%20about%20the,the%20most%20important%20security%20risks. tags: analytic_story: - Prohibited Traffic Allowed or Protocol Mismatch @@ -27,7 +38,8 @@ tags: asset_type: Endpoint confidence: 80 impact: 100 - message: Suspicious network traffic allowed using TOR has been detected from $src_ip$ to $dest_ip$ + message: Suspicious network traffic allowed using TOR has been detected from $src_ip$ + to $dest_ip$ mitre_attack_id: - T1090 - T1090.003 @@ -52,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.003/pan_tor_allowed/pan_tor_allowed.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1090.003/pan_tor_allowed/pan_tor_allowed.log source: pan_tor_allowed sourcetype: pan:traffic diff --git a/detections/network/windows_ad_replication_service_traffic.yml b/detections/network/windows_ad_replication_service_traffic.yml index 4ef5761e2b..4d254d24ea 100644 --- a/detections/network/windows_ad_replication_service_traffic.yml +++ b/detections/network/windows_ad_replication_service_traffic.yml @@ -1,59 +1,60 @@ name: Windows AD Replication Service Traffic id: c6e24183-a5f4-4b2a-ad01-2eb456d09b67 -version: 1 -date: "2022-11-26" +version: 2 +date: "2024-05-19" author: Steven Dick type: TTP status: experimental data_source: [] -description: - This search looks for evidence of Active Directory replication traffic [MS-DRSR] from unexpected sources. - This traffic is often seen exclusively between Domain Controllers for AD database replication. - Any detections from non-domain controller source to a domain controller may indicate the usage of DCSync or DCShadow credential dumping techniques. -search: - '| tstats `security_content_summariesonly` count values(All_Traffic.transport) as transport values(All_Traffic.user) as user - values(All_Traffic.src_category) as src_category values(All_Traffic.dest_category) as dest_category min(_time) as firstTime max(_time) as lastTime - from datamodel=Network_Traffic where All_Traffic.app IN ("ms-dc-replication","*drsr*","ad drs") by All_Traffic.src All_Traffic.dest All_Traffic.app - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `drop_dm_object_name("All_Traffic")` - | `windows_ad_replication_service_traffic_filter`' -how_to_implement: - To successfully implement this search, you need to be ingesting +description: The following analytic identifies unexpected Active Directory replication + traffic from non-domain controller sources. It leverages data from the Network Traffic + datamodel, specifically looking for applications related to AD replication. This + activity is significant because AD replication traffic should typically only occur + between domain controllers. Detection of such traffic from other sources may indicate + malicious activities like DCSync or DCShadow, which are used for credential dumping. + If confirmed malicious, this could allow attackers to exfiltrate sensitive credentials, + leading to unauthorized access and potential domain-wide compromise. +search: '| tstats `security_content_summariesonly` count values(All_Traffic.transport) + as transport values(All_Traffic.user) as user values(All_Traffic.src_category) as + src_category values(All_Traffic.dest_category) as dest_category min(_time) as firstTime + max(_time) as lastTime from datamodel=Network_Traffic where All_Traffic.app IN ("ms-dc-replication","*drsr*","ad + drs") by All_Traffic.src All_Traffic.dest All_Traffic.app | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Traffic")` | `windows_ad_replication_service_traffic_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting application aware firewall or proxy logs into the Network Datamodel. Categorize all known domain controller Assets servers with an appropriate category for filtering. known_false_positives: New domain controllers or certian scripts run by administrators. references: - - https://adsecurity.org/?p=1729 - - https://attack.mitre.org/techniques/T1003/006/ - - https://attack.mitre.org/techniques/T1207/ +- https://adsecurity.org/?p=1729 +- https://attack.mitre.org/techniques/T1003/006/ +- https://attack.mitre.org/techniques/T1207/ tags: analytic_story: - - Sneaky Active Directory Persistence Tricks + - Sneaky Active Directory Persistence Tricks asset_type: Endpoint confidence: 100 impact: 100 message: Active Directory Replication Traffic from Unknown Source - $src$ mitre_attack_id: - - T1003 - - T1003.006 - - T1207 + - T1003 + - T1003.006 + - T1207 observable: - - name: dest - type: IP Address - role: - - Victim - - name: src - type: IP Address - role: - - Attacker + - name: dest + type: IP Address + role: + - Victim + - name: src + type: IP Address + role: + - Attacker product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - All_Traffic.src - - All_Traffic.dest - - All_Traffic.app + - All_Traffic.src + - All_Traffic.dest + - All_Traffic.app risk_score: 100 security_domain: network diff --git a/detections/network/windows_ad_rogue_domain_controller_network_activity.yml b/detections/network/windows_ad_rogue_domain_controller_network_activity.yml index 24875ceda1..e4678ee492 100644 --- a/detections/network/windows_ad_rogue_domain_controller_network_activity.yml +++ b/detections/network/windows_ad_rogue_domain_controller_network_activity.yml @@ -1,47 +1,53 @@ name: Windows AD Rogue Domain Controller Network Activity id: c4aeeeef-da7f-4338-b3ba-553cbcbe2138 -version: 1 -date: "2022-09-08" +version: 2 +date: "2024-05-18" author: Dean Luxton type: TTP status: experimental data_source: [] -description: - This detection is looking at zeek wiredata for specific replication RPC calls being performed from a device which is not a domain controller. - If you would like to capture these RPC calls using Splunk Stream, please vote for my idea here https://ideas.splunk.com/ideas/APPSID-I-619 ;) -search: '`zeek_rpc` DrsReplicaAdd OR DRSGetNCChanges - | where NOT (dest_category="Domain Controller") OR NOT (src_category="Domain Controller") - | fillnull value="Unknown" src_category, dest_category - | table _time endpoint operation src src_category dest dest_category | `windows_ad_rogue_domain_controller_network_activity_filter`' -how_to_implement: Run zeek on domain controllers to capture the DCE RPC calls, ensure the domain controller categories are defined in Assets and Identities. +description: The following analytic identifies unauthorized replication RPC calls + from non-domain controller devices. It leverages Zeek wire data to detect specific + RPC operations like DrsReplicaAdd and DRSGetNCChanges, filtering out legitimate + domain controllers. This activity is significant as it may indicate an attempt to + introduce a rogue domain controller, which can compromise the integrity of the Active + Directory environment. If confirmed malicious, this could allow attackers to manipulate + directory data, escalate privileges, and persist within the network, posing a severe + security risk. +search: '`zeek_rpc` DrsReplicaAdd OR DRSGetNCChanges | where NOT (dest_category="Domain + Controller") OR NOT (src_category="Domain Controller") | fillnull value="Unknown" + src_category, dest_category | table _time endpoint operation src src_category dest + dest_category | `windows_ad_rogue_domain_controller_network_activity_filter`' +how_to_implement: Run zeek on domain controllers to capture the DCE RPC calls, ensure + the domain controller categories are defined in Assets and Identities. known_false_positives: None. references: - - https://adsecurity.org/?p=1729 +- https://adsecurity.org/?p=1729 tags: analytic_story: - - Sneaky Active Directory Persistence Tricks + - Sneaky Active Directory Persistence Tricks asset_type: Endpoint confidence: 100 impact: 100 message: Rogue DC Activity Detected from $src_category$ device $src$ to $dest$ ($dest_category$) mitre_attack_id: - - T1207 + - T1207 observable: - - name: src - type: IP Address - role: - - Attacker - - name: dest - type: IP Address - role: - - Victim + - name: src + type: IP Address + role: + - Attacker + - name: dest + type: IP Address + role: + - Victim product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud required_fields: - - _time - - src - - dest + - _time + - src + - dest risk_score: 100 security_domain: network diff --git a/detections/network/zeek_x509_certificate_with_punycode.yml b/detections/network/zeek_x509_certificate_with_punycode.yml index 195e4a5e7d..5fddaf6167 100644 --- a/detections/network/zeek_x509_certificate_with_punycode.yml +++ b/detections/network/zeek_x509_certificate_with_punycode.yml @@ -1,18 +1,17 @@ name: Zeek x509 Certificate with Punycode id: 029d6fe4-a5fe-43af-827e-c78c50e81d81 -version: 1 -date: '2022-11-03' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk status: experimental type: Hunting -description: The following analytic utilizes the Zeek x509 log. Modify the zeek_x509 - macro with your index and sourcetype as needed. You will need to ensure the full - x509 is logged as the potentially malicious punycode is nested under subject alternative - names. In this particular analytic, it will identify punycode within the subject - alternative name email and other fields. Note, that OtherFields is meant to be BOOL - (true,false), therefore we may never see xn-- in that field. Upon identifying punycode, - manually copy and paste, or add CyberChef recipe to query, and decode the punycode - manually. +description: The following analytic detects the presence of punycode within x509 certificates + using Zeek x509 logs. It identifies punycode in the subject alternative name email + and other fields by searching for the "xn--" prefix. This activity is significant + as punycode can be used in phishing attacks or to bypass domain filters, posing + a security risk. If confirmed malicious, attackers could use these certificates + to impersonate legitimate domains, potentially leading to unauthorized access or + data breaches. data_source: [] search: '`zeek_x509` | rex field=san.email{} "\@(?xn--.*)" | rex field=san.other_fields{} "\@(?xn--.*)" | stats values(domain_detected) diff --git a/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml b/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml index 31e05bc2ac..2ee10a8f52 100644 --- a/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml +++ b/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml @@ -1,19 +1,32 @@ name: Access to Vulnerable Ivanti Connect Secure Bookmark Endpoint id: 15838756-f425-43fa-9d88-a7f88063e81a -version: 1 -date: '2024-01-16' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: This analytic monitors access to the /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark endpoint, a key indicator for both CVE-2023-46805 and CVE-2024-21887 vulnerabilities. It detects potential vulnerabilities by looking for a 403 Forbidden response with an empty body on this endpoint. This detection method is used in both Nmap script and Project Discovery Nuclei, with the latter focusing on systems where XML mitigation for these vulnerabilities has not been applied. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark*" Web.http_method=GET Web.status=403 by Web.src, Web.dest, Web.http_user_agent, Web.status, Web.url source - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic identifies access to the + /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark + endpoint, which is associated with CVE-2023-46805 and CVE-2024-21887 vulnerabilities. + It detects this activity by monitoring for GET requests that receive a 403 Forbidden + response with an empty body. This behavior is significant as it indicates potential + exploitation attempts against Ivanti Connect Secure systems. If confirmed malicious, + attackers could exploit these vulnerabilities to gain unauthorized access or control + over the affected systems, leading to potential data breaches or system compromise. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url="*/api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark*" + Web.http_method=GET Web.status=403 by Web.src, Web.dest, Web.http_user_agent, Web.status, + Web.url source | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: This analytic is limited to HTTP Status 403; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, + or Splunk for Palo Alto. +known_false_positives: This analytic is limited to HTTP Status 403; adjust as necessary. + False positives may occur if the URI path is IP-restricted or externally blocked. + It's recommended to review the context of the alerts and adjust the analytic parameters + to better fit the specific environment. references: - https://github.com/RootUp/PersonalStuff/blob/master/http-vuln-cve2023-46805_2024_21887.nse - https://github.com/projectdiscovery/nuclei-templates/blob/c6b351e71b0fb0e40e222e97038f1fe09ac58194/http/misconfiguration/ivanti/CVE-2023-46085-CVE-2024-21887-mitigation-not-applied.yaml @@ -51,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/ivanti_bookmark_web_access.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/ivanti_bookmark_web_access.log source: suricata sourcetype: suricata diff --git a/detections/web/adobe_coldfusion_access_control_bypass.yml b/detections/web/adobe_coldfusion_access_control_bypass.yml index a19139a3ae..5828ebffb2 100644 --- a/detections/web/adobe_coldfusion_access_control_bypass.yml +++ b/detections/web/adobe_coldfusion_access_control_bypass.yml @@ -1,23 +1,35 @@ name: Adobe ColdFusion Access Control Bypass id: d6821c0b-fcdc-4c95-a77f-e10752fae41a -version: 1 -date: '2023-08-23' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic detects potential exploitation attempts against Adobe ColdFusion vulnerabilities CVE-2023-29298 and CVE-2023-26360. These vulnerabilities pertain to an access control bypass and an arbitrary file read due to deserialization, respectively. By monitoring for requests to specific ColdFusion Administrator endpoints, especially those with an unexpected additional forward slash, the analytic identifies attempts to bypass access controls. Such behavior is crucial for a Security Operations Center (SOC) to identify, as exploitation can grant unauthorized access to ColdFusion administration endpoints, potentially leading to information leakage, brute force attacks, or further exploitation of other vulnerabilities. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the ColdFusion environment, potentially leading to data theft or other malicious activities. SOCs must be vigilant in monitoring for these patterns, ensuring timely detection and response to such threats, thus safeguarding the integrity and security of their ColdFusion deployments. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("//restplay*", "//CFIDE/restplay*", "//CFIDE/administrator*", "//CFIDE/adminapi*", "//CFIDE/main*", "//CFIDE/componentutils*", "//CFIDE/wizards*", "//CFIDE/servermanager*","/restplay*", "/CFIDE/restplay*", "/CFIDE/administrator*", "/CFIDE/adminapi*", "/CFIDE/main*", "/CFIDE/componentutils*", "/CFIDE/wizards*", "/CFIDE/servermanager*") Web.status=200 - by Web.http_user_agent, Web.status, Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `adobe_coldfusion_access_control_bypass_filter`' +description: The following analytic detects potential exploitation attempts against + Adobe ColdFusion vulnerabilities CVE-2023-29298 and CVE-2023-26360. It monitors + requests to specific ColdFusion Administrator endpoints, especially those with an + unexpected additional forward slash, using the Web datamodel. This activity is significant + for a SOC as it indicates attempts to bypass access controls, which can lead to + unauthorized access to ColdFusion administration endpoints. If confirmed malicious, + this could result in data theft, brute force attacks, or further exploitation of + other vulnerabilities, posing a serious security risk to the environment. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("//restplay*", "//CFIDE/restplay*", "//CFIDE/administrator*", + "//CFIDE/adminapi*", "//CFIDE/main*", "//CFIDE/componentutils*", "//CFIDE/wizards*", + "//CFIDE/servermanager*","/restplay*", "/CFIDE/restplay*", "/CFIDE/administrator*", + "/CFIDE/adminapi*", "/CFIDE/main*", "/CFIDE/componentutils*", "/CFIDE/wizards*", + "/CFIDE/servermanager*") Web.status=200 by Web.http_user_agent, Web.status, Web.http_method, + Web.url, Web.url_length, Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `adobe_coldfusion_access_control_bypass_filter`' how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. + False positives may occur if the URI path is IP-restricted or externally blocked. + It's recommended to review the context of the alerts and adjust the analytic parameters + to better fit the specific environment. references: - https://www.rapid7.com/blog/post/2023/07/11/cve-2023-29298-adobe-coldfusion-access-control-bypass/ tags: @@ -29,7 +41,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible exploitation of CVE-2023-29298 against $dest$. + message: Possible exploitation of CVE-2023-29298 against $dest$. mitre_attack_id: - T1190 observable: @@ -60,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/adobe/coldfusion_cve_2023_29298.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/adobe/coldfusion_cve_2023_29298.log source: suricata sourcetype: suricata diff --git a/detections/web/adobe_coldfusion_unauthenticated_arbitrary_file_read.yml b/detections/web/adobe_coldfusion_unauthenticated_arbitrary_file_read.yml index 5ee1bb22a0..76a708daf5 100644 --- a/detections/web/adobe_coldfusion_unauthenticated_arbitrary_file_read.yml +++ b/detections/web/adobe_coldfusion_unauthenticated_arbitrary_file_read.yml @@ -1,27 +1,34 @@ name: Adobe ColdFusion Unauthenticated Arbitrary File Read id: 695aceae-21db-4e7f-93ac-a52e39d02b93 -version: 1 -date: '2023-08-23' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic detects potential exploitation of the critical Adobe ColdFusion vulnerability, CVE-2023-26360. This flaw, rooted in the deserialization of untrusted data, enables Unauthenticated Arbitrary File Read. Exploitation often targets specific ColdFusion paths, especially related to CKEditor's file manager. - - Our analytic pinpoints exploitation by monitoring web requests to the "/cf_scripts/scripts/ajax/ckeditor/*" path. This focus helps differentiate malicious activity from standard ColdFusion traffic. For SOCs, detecting such attempts is vital given the vulnerability's CVSS score of 9.8, signaling its severity. Successful exploitation can lead to unauthorized data access, further attacks, or severe operational disruptions. - - If a true positive arises, it indicates an active breach attempt, potentially causing data theft, operational disruption, or reputational damage. In essence, this analytic provides a targeted approach to identify attempts exploiting a high-risk ColdFusion vulnerability. While false positives may occur from legitimate accesses, any alerts should be treated as high-priority, warranting immediate investigation to ensure security. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/cf_scripts/scripts/ajax/ckeditor/*") Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `adobe_coldfusion_unauthenticated_arbitrary_file_read_filter`' +description: The following analytic detects potential exploitation of the Adobe ColdFusion + vulnerability, CVE-2023-26360, which allows unauthenticated arbitrary file read. + It monitors web requests to the "/cf_scripts/scripts/ajax/ckeditor/*" path using + the Web datamodel, focusing on specific ColdFusion paths to differentiate malicious + activity from normal traffic. This activity is significant due to the vulnerability's + high CVSS score of 9.8, indicating severe risk. If confirmed malicious, it could + lead to unauthorized data access, further attacks, or severe operational disruptions, + necessitating immediate investigation. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/cf_scripts/scripts/ajax/ckeditor/*") Web.status=200 by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `adobe_coldfusion_unauthenticated_arbitrary_file_read_filter`' how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: 'In the wild, we have observed three different types of attempts that could potentially trigger false positives if the HTTP status code is not in the query. Please check this github gist for the specific URIs : https://gist.github.com/patel-bhavin/d10830f3f375a2397233f6a4fe38d5c9 . These could be legitimate requests depending on the context of your organization. Therefore, it is recommended to modify the analytic as needed to suit your specific environment.' +known_false_positives: 'In the wild, we have observed three different types of attempts + that could potentially trigger false positives if the HTTP status code is not in + the query. Please check this github gist for the specific URIs : https://gist.github.com/patel-bhavin/d10830f3f375a2397233f6a4fe38d5c9 + . These could be legitimate requests depending on the context of your organization. + Therefore, it is recommended to modify the analytic as needed to suit your specific + environment.' references: - https://www.rapid7.com/db/modules/auxiliary/gather/adobe_coldfusion_fileread_cve_2023_26360/ - https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2023/CVE-2023-26360.yaml @@ -34,7 +41,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible exploitation of CVE-2023-26360 against $dest$. + message: Possible exploitation of CVE-2023-26360 against $dest$. mitre_attack_id: - T1190 observable: @@ -65,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/adobe/cve_2023_29360_coldfusion.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/adobe/cve_2023_29360_coldfusion.log source: suricata sourcetype: suricata diff --git a/detections/web/cisco_ios_xe_implant_access.yml b/detections/web/cisco_ios_xe_implant_access.yml index e5f1ea0504..790ff1f9fd 100644 --- a/detections/web/cisco_ios_xe_implant_access.yml +++ b/detections/web/cisco_ios_xe_implant_access.yml @@ -1,22 +1,31 @@ name: Cisco IOS XE Implant Access id: 07c36cda-6567-43c3-bc1a-89dff61e2cd9 -version: 1 -date: '2023-10-17' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic identifies potential exploitation of a previously unknown vulnerability in the Web User Interface (Web UI) feature of Cisco IOS XE software (CVE-2023-20198). Successful exploitation allows an attacker to create an account on the affected device with privilege level 15 access, granting them full control of the compromised device. The detection is based on the observation of suspicious account creation and subsequent actions, including the deployment of an implant consisting of a configuration file. The implant is saved under the file path //usr//binos//conf//nginx-conf//cisco_service.conf and is not persistent, meaning a device reboot will remove it, but the newly created local user accounts remain active even after system reboots. The new user accounts have level 15 privileges, meaning they have full administrator access to the device. This privileged access to the devices and subsequent creation of new users is tracked as CVE-2023-20198. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("/webui/logoutconfirm.html?logon_hash=*") Web.http_method=POST Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic identifies the potential exploitation of a vulnerability + (CVE-2023-20198) in the Web User Interface of Cisco IOS XE software. It detects + suspicious account creation and subsequent actions, including the deployment of + a non-persistent implant configuration file. The detection leverages the Web datamodel, + focusing on specific URL patterns and HTTP methods. This activity is significant + as it indicates unauthorized administrative access, which can lead to full control + of the device. If confirmed malicious, attackers could maintain privileged access, + compromising the device's integrity and security. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/webui/logoutconfirm.html?logon_hash=*") Web.http_method=POST + Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, + Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `cisco_ios_xe_implant_access_filter`' how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk - for Palo Alto. -known_false_positives: False positives may be present, restrict to Cisco IOS XE devices or perimeter appliances. Modify the analytic as needed based on hunting for successful exploitation of CVE-2023-20198. + for Palo Alto. +known_false_positives: False positives may be present, restrict to Cisco IOS XE devices + or perimeter appliances. Modify the analytic as needed based on hunting for successful + exploitation of CVE-2023-20198. references: - https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/ - https://github.com/vulncheck-oss/cisco-ios-xe-implant-scanner @@ -57,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/cisco/iosxe/ciscocve202320198.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/cisco/iosxe/ciscocve202320198.log source: suricata sourcetype: suricata diff --git a/detections/web/citrix_adc_and_gateway_unauthorized_data_disclosure.yml b/detections/web/citrix_adc_and_gateway_unauthorized_data_disclosure.yml index 331a10159a..3e08a9a9b5 100644 --- a/detections/web/citrix_adc_and_gateway_unauthorized_data_disclosure.yml +++ b/detections/web/citrix_adc_and_gateway_unauthorized_data_disclosure.yml @@ -1,30 +1,36 @@ name: Citrix ADC and Gateway Unauthorized Data Disclosure id: b593cac5-dd20-4358-972a-d945fefdaf17 -version: 1 -date: '2023-10-24' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic detects attempts to exploit the Citrix Bleed vulnerability, which can lead to the leaking of session tokens. The vulnerability, identified as CVE-2023-4966, pertains to sensitive information disclosure in NetScaler ADC and NetScaler Gateway when set up as various server configurations. The analytic specifically searches for HTTP requests with a 200 status code targeting the /oauth/idp/.well-known/openid-configuration URL endpoint. By parsing web traffic and filtering based on the aforementioned criteria along with specific user agent details, HTTP method, source and destination IPs, and the sourcetype, the analytic aims to identify potentially malicious requests that fit the profile of this exploit. - - This behavior is essential for a Security Operations Center (SOC) to identify because if successfully exploited, attackers can gain unauthorized access, leading to a potential breach or further malicious activities within the organization's network. As the Citrix Bleed vulnerability can disclose session tokens, a successful exploit can allow attackers to impersonate legitimate users, bypassing authentication mechanisms and accessing sensitive data or systems. - - If a true positive is confirmed, it implies that an attacker is actively exploiting the vulnerability within the organization's environment. This could lead to severe consequences, including unauthorized data access, further propagation within the network, and potential disruptions or exfiltration of critical information. - - Upon flagging such activity, it's crucial for analysts to swiftly validate the alert, assess the nature and extent of the exposure, and implement necessary measures to mitigate the threat. Reviewing the details such as user agent, source, and destination IP can help in understanding the context and intent of the attack. While it's imperative to patch vulnerable systems to prevent this exploitation, early detection through this analytic provides a valuable layer of defense, enabling timely response to thwart potential breaches. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/oauth/idp/.well-known/openid-configuration*") Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic detects attempts to exploit the Citrix Bleed vulnerability + (CVE-2023-4966), which can lead to the leaking of session tokens. It identifies + HTTP requests with a 200 status code targeting the /oauth/idp/.well-known/openid-configuration + URL endpoint. By parsing web traffic and filtering based on user agent details, + HTTP method, source and destination IPs, and sourcetype, it aims to identify potentially + malicious requests. This activity is significant for a SOC because successful exploitation + can allow attackers to impersonate legitimate users, bypass authentication, and + access sensitive data. If confirmed malicious, it could lead to unauthorized data + access, network propagation, and critical information exfiltration. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/oauth/idp/.well-known/openid-configuration*") Web.status=200 + by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, + Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `citrix_adc_and_gateway_unauthorized_data_disclosure_filter`' how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk - for Palo Alto. We recommend hunting in the environment first to understand the scope of the issue and then deploying this detection to monitor for future exploitation attempts. Limit or restrict to Citrix devices only if possible. -known_false_positives: False positives may be present based on organization use of Citrix ADC and Gateway. Filter, or restrict the analytic to Citrix devices only. + for Palo Alto. We recommend hunting in the environment first to understand the scope + of the issue and then deploying this detection to monitor for future exploitation + attempts. Limit or restrict to Citrix devices only if possible. +known_false_positives: False positives may be present based on organization use of + Citrix ADC and Gateway. Filter, or restrict the analytic to Citrix devices only. references: - - https://www.assetnote.io/resources/research/citrix-bleed-leaking-session-tokens-with-cve-2023-4966 - - https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-4966 +- https://www.assetnote.io/resources/research/citrix-bleed-leaking-session-tokens-with-cve-2023-4966 +- https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-4966 tags: analytic_story: - Citrix NetScaler ADC and NetScaler Gateway CVE-2023-4966 @@ -32,7 +38,8 @@ tags: atomic_guid: [] confidence: 90 impact: 100 - message: Possible exploitation of Citrix Bleed vulnerability against $dest$ fron $src$. + message: Possible exploitation of Citrix Bleed vulnerability against $dest$ fron + $src$. mitre_attack_id: - T1190 observable: @@ -62,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/cve-2023-4966-citrix.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/cve-2023-4966-citrix.log source: suricata sourcetype: suricata diff --git a/detections/web/citrix_adc_exploitation_cve_2023_3519.yml b/detections/web/citrix_adc_exploitation_cve_2023_3519.yml index e09267c278..a7bdea2439 100644 --- a/detections/web/citrix_adc_exploitation_cve_2023_3519.yml +++ b/detections/web/citrix_adc_exploitation_cve_2023_3519.yml @@ -1,29 +1,29 @@ name: Citrix ADC Exploitation CVE-2023-3519 id: 76ac2dcb-333c-4a77-8ae9-2720cfae47a8 -version: 2 -date: '2023-07-21' +version: 3 +date: '2024-05-25' author: Michael Haag, Splunk status: production type: Hunting -data_source: +data_source: - Palo Alto Network Threat -description: This analytic is designed to assist in hunting for potential exploitation attempts against Citrix ADC in relation to CVE-2023-3519. This vulnerability, identified within Citrix ADC and NetScaler Gateway, appears to be linked with SAML processing components, with an overflow issue allowing for possible memory corruption. Preliminary findings indicate that for the exploit to be viable, SAML has to be enabled. The analytic targets POST requests to certain web endpoints which have been associated with the exploitation process. - - Given the specific nature of the vulnerability, upon deploying this analytic it is recommended to filter and narrow the focus towards your ADC assets to reduce potential noise and improve the signal of the analytic. Please note that the exploitation of this vulnerability has been reported in the wild, therefore monitoring for potential signs of exploitation should be considered high priority. - - The search query provided examines web data for POST requests made to specific URLs associated with the exploitation of this vulnerability. It aggregates and presents data to highlight potential exploitation attempts, taking into account elements like user agent, HTTP method, URL length, source, and destination. - - Please be aware that this analytic is based on current understanding of the vulnerability, and adjustments may be required as more information becomes available. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("*/saml/login","/cgi/samlauth","*/saml/activelogin","/cgi/samlart?samlart=*","*/cgi/logout","/gwtest/formssso?event=start&target=*","/netscaler/ns_gui/vpn/*") Web.http_method=POST - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic identifies potential exploitation attempts against + Citrix ADC related to CVE-2023-3519. It detects POST requests to specific web endpoints + associated with this vulnerability by leveraging the Web datamodel. This activity + is significant as CVE-2023-3519 involves a SAML processing overflow issue that can + lead to memory corruption, posing a high risk. If confirmed malicious, attackers + could exploit this to execute arbitrary code, escalate privileges, or disrupt services, + making it crucial for SOC analysts to monitor and investigate these alerts promptly. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/saml/login","/cgi/samlauth","*/saml/activelogin","/cgi/samlart?samlart=*","*/cgi/logout","/gwtest/formssso?event=start&target=*","/netscaler/ns_gui/vpn/*") Web.http_method=POST + by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, + Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `citrix_adc_exploitation_cve_2023_3519_filter`' how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: False positives may be present based on organization use of SAML utilities. Filter, or restrict the analytic to Citrix devices only. +known_false_positives: False positives may be present based on organization use of + SAML utilities. Filter, or restrict the analytic to Citrix devices only. references: - https://blog.assetnote.io/2023/07/21/citrix-CVE-2023-3519-analysis/ - https://support.citrix.com/article/CTX561482/citrix-adc-and-citrix-gateway-security-bulletin-for-cve20233519-cve20233466-cve20233467 @@ -38,7 +38,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible expliotation of CVE-2023-3519 against $dest$. + message: Possible expliotation of CVE-2023-3519 against $dest$. mitre_attack_id: - T1190 observable: @@ -62,6 +62,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/citrix-cve20233519.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/citrix-cve20233519.log source: pan:threat sourcetype: pan:threat diff --git a/detections/web/citrix_sharefile_exploitation_cve_2023_24489.yml b/detections/web/citrix_sharefile_exploitation_cve_2023_24489.yml index e263450d53..92cfe69c6f 100644 --- a/detections/web/citrix_sharefile_exploitation_cve_2023_24489.yml +++ b/detections/web/citrix_sharefile_exploitation_cve_2023_24489.yml @@ -1,30 +1,35 @@ name: Citrix ShareFile Exploitation CVE-2023-24489 id: 172c59f2-5fae-45e5-8e51-94445143e93f -version: 1 -date: '2023-07-26' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: Hunting -data_source: +data_source: - Suricata -description: The following analytic detects a potentially malicious file upload attempt to Documentum, an enterprise content management platform, via specific suspicious URLs and the HTTP POST method. This detection occurs through pattern recognition within the datamodel=Web, focusing on URL patterns that follow "/documentum/upload.aspx?parentid=", "/documentum/upload.aspx?filename=", "/documentum/upload.aspx?uploadId=*", combined with the HTTP POST method, indicative of a file upload attempt. - - This behavior is significant for a Security Operations Center (SOC) to identify, as it can signify a potential attack vector. Malicious actors might use this method to upload a harmful script or other exploitable content to Documentum, thereby establishing a foothold in the environment, spreading malware, or enabling further exploitation. - - The impact of this behavior, if a true positive, can be quite significant. An attacker could compromise the Documentum application, manipulate or steal sensitive content, and potentially gain unauthorized access to other system resources. An intrusion of this nature could disrupt business operations, result in data breaches, and even damage the organization's reputation. - - However, it's important to note that false positives may occur. For example, legitimate but uncommon file uploads might match these URL patterns. It's crucial to verify any alerts generated by this analytic to ensure accurate threat detection. This analytic provides critical insights into potential attack attempts and assists in maintaining the integrity and security of enterprise content management systems like Documentum. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url="/documentum/upload.aspx?*" AND Web.url IN ("*parentid=*","*filename=*","*uploadId=*") AND Web.url IN ("*unzip=*", "*raw=*") Web.http_method=POST - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `citrix_sharefile_exploitation_cve_2023_24489_filter`' -how_to_implement: Dependent upon the placement of the ShareFile application, ensure the latest Technology Add-On is eneabled. This detection requires the Web datamodel to be populated from a - supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk - for Palo Alto. - The ShareFile application is IIS based, therefore ingesting IIS logs and reviewing for the same pattern would identify this activity, successful or not. -known_false_positives: False positives may be present, filtering may be needed. Also, restricting to known web servers running IIS or ShareFile will change this from Hunting to TTP. +description: The following analytic detects potentially malicious file upload attempts + to Citrix ShareFile via specific suspicious URLs and the HTTP POST method. It leverages + the Web datamodel to identify URL patterns such as "/documentum/upload.aspx?parentid=", + "/documentum/upload.aspx?filename=", and "/documentum/upload.aspx?uploadId=*", combined + with the HTTP POST method. This activity is significant for a SOC as it may indicate + an attempt to upload harmful scripts or content, potentially compromising the Documentum + application. If confirmed malicious, this could lead to unauthorized access, data + breaches, and operational disruptions. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url="/documentum/upload.aspx?*" AND Web.url IN ("*parentid=*","*filename=*","*uploadId=*") + AND Web.url IN ("*unzip=*", "*raw=*") Web.http_method=POST by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `citrix_sharefile_exploitation_cve_2023_24489_filter`' +how_to_implement: Dependent upon the placement of the ShareFile application, ensure + the latest Technology Add-On is eneabled. This detection requires the Web datamodel + to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, + Splunk for Nginx, or Splunk for Palo Alto. The ShareFile application is IIS based, + therefore ingesting IIS logs and reviewing for the same pattern would identify this + activity, successful or not. +known_false_positives: False positives may be present, filtering may be needed. Also, + restricting to known web servers running IIS or ShareFile will change this from + Hunting to TTP. references: - https://blog.assetnote.io/2023/07/04/citrix-sharefile-rce/ tags: @@ -36,7 +41,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible expliotation of CVE-2023-24489 against $dest$. + message: Possible expliotation of CVE-2023-24489 against $dest$. mitre_attack_id: - T1190 observable: @@ -60,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/citrix-cve_2023_24489.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/citrix/citrix-cve_2023_24489.log source: suricata sourcetype: suricata diff --git a/detections/web/confluence_cve_2023_22515_trigger_vulnerability.yml b/detections/web/confluence_cve_2023_22515_trigger_vulnerability.yml index 7462f048dc..00769b851c 100644 --- a/detections/web/confluence_cve_2023_22515_trigger_vulnerability.yml +++ b/detections/web/confluence_cve_2023_22515_trigger_vulnerability.yml @@ -1,19 +1,27 @@ name: Confluence CVE-2023-22515 Trigger Vulnerability id: 630ea8b2-2800-4f5d-9cbc-d65c567349b0 -version: 2 -date: '2023-10-23' +version: 3 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false* and /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=0& URLs. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false*","*/server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=0&*") Web.http_method=GET Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `confluence_cve_2023_22515_trigger_vulnerability_filter`' +description: The following analytic identifies potential exploitation attempts of + the Confluence CVE-2023-22515 vulnerability. It detects successful accesses (HTTP + status 200) to specific vulnerable endpoints by analyzing web logs within the Splunk + 'Web' Data Model. This activity is significant for a SOC as it indicates possible + privilege escalation attempts in Confluence. If confirmed malicious, attackers could + gain unauthorized access or create accounts with escalated privileges, leading to + potential data breaches or further exploitation within the environment. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false*","*/server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=0&*") + Web.http_method=GET Web.status=200 by Web.http_user_agent, Web.status Web.http_method, + Web.url, Web.url_length, Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `confluence_cve_2023_22515_trigger_vulnerability_filter`' how_to_implement: To successfully implement this search you need to be ingesting information - on Web traffic that include fields relavent for traffic into the `Web` datamodel. Tested with Suricata and nginx:plus:kv. + on Web traffic that include fields relavent for traffic into the `Web` datamodel. + Tested with Suricata and nginx:plus:kv. known_false_positives: False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to Confluence servers. references: @@ -22,12 +30,13 @@ references: - https://github.com/j3seer/CVE-2023-22515-POC tags: analytic_story: - - CVE-2023-22515 Privilege Escalation Vulnerability Confluence Data Center and Server + - CVE-2023-22515 Privilege Escalation Vulnerability Confluence Data Center and Server asset_type: Web Server atomic_guid: [] confidence: 80 impact: 90 - message: Potential exploitation attempts on a known vulnerability in Atlassian Confluence detected. The source IP is $src$ and the destination hostname is $dest$. + message: Potential exploitation attempts on a known vulnerability in Atlassian Confluence + detected. The source IP is $src$ and the destination hostname is $dest$. mitre_attack_id: - T1190 observable: @@ -57,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/confluence_vuln_trigger_cve-2023-22515.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/confluence_vuln_trigger_cve-2023-22515.log source: suricata sourcetype: suricata diff --git a/detections/web/confluence_data_center_and_server_privilege_escalation.yml b/detections/web/confluence_data_center_and_server_privilege_escalation.yml index bcb6d14f32..778fd3c8cd 100644 --- a/detections/web/confluence_data_center_and_server_privilege_escalation.yml +++ b/detections/web/confluence_data_center_and_server_privilege_escalation.yml @@ -1,26 +1,35 @@ name: Confluence Data Center and Server Privilege Escalation id: 115bebac-0976-4f7d-a3ec-d1fb45a39a11 -version: 3 -date: '2023-10-18' +version: 4 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Nginx Access -description: The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /setup/*.action* URL pattern. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/setup/setupadministrator.action*", "*/setup/finishsetup.action*", "*/json/setup-restore-local.action*", "*/json/setup-restore-progress.action*", "*/json/setup-restore.action*", "*/bootstrap/selectsetupstep.action*") Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `confluence_data_center_and_server_privilege_escalation_filter`' +description: The following analytic identifies potential exploitation attempts on + a known vulnerability in Atlassian Confluence, specifically targeting the /setup/*.action* + URL pattern. It leverages web logs within the Splunk 'Web' Data Model, filtering + for successful accesses (HTTP status 200) to these endpoints. This activity is significant + as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. + If confirmed malicious, it could result in unauthorized access or account creation + with escalated privileges, leading to potential data breaches or further exploitation + within the environment. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/setup/setupadministrator.action*", "*/setup/finishsetup.action*", + "*/json/setup-restore-local.action*", "*/json/setup-restore-progress.action*", "*/json/setup-restore.action*", + "*/bootstrap/selectsetupstep.action*") Web.status=200 by Web.http_user_agent, Web.status + Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `confluence_data_center_and_server_privilege_escalation_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. known_false_positives: False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to confluence servers. references: - - https://confluence.atlassian.com/security/cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html - - https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html - - https://www.rapid7.com/blog/post/2023/10/04/etr-cve-2023-22515-zero-day-privilege-escalation-in-confluence-server-and-data-center/ - - https://attackerkb.com/topics/Q5f0ItSzw5/cve-2023-22515/rapid7-analysis +- https://confluence.atlassian.com/security/cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html +- https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html +- https://www.rapid7.com/blog/post/2023/10/04/etr-cve-2023-22515-zero-day-privilege-escalation-in-confluence-server-and-data-center/ +- https://attackerkb.com/topics/Q5f0ItSzw5/cve-2023-22515/rapid7-analysis tags: analytic_story: - CVE-2023-22515 Privilege Escalation Vulnerability Confluence Data Center and Server @@ -31,7 +40,8 @@ tags: atomic_guid: [] confidence: 80 impact: 90 - message: Potential exploitation attempts on a known vulnerability in Atlassian Confluence detected. The source IP is $src$ and the destination hostname is $dest$. + message: Potential exploitation attempts on a known vulnerability in Atlassian Confluence + detected. The source IP is $src$ and the destination hostname is $dest$. mitre_attack_id: - T1190 observable: @@ -60,6 +70,7 @@ tags: tests: - name: Nginx Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/nginx_plus_kv_confluence.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/nginx_plus_kv_confluence.log source: nginx:plus:kv sourcetype: nginx:plus:kv diff --git a/detections/web/confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527.yml b/detections/web/confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527.yml index a65d81a29e..11fa43ee4b 100644 --- a/detections/web/confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527.yml +++ b/detections/web/confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527.yml @@ -1,17 +1,25 @@ name: Confluence Pre-Auth RCE via OGNL Injection CVE-2023-22527 id: f56936c0-ae6f-4eeb-91ff-ecc1448c6105 -version: 1 -date: '2024-01-22' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: This analytic identifies a critical template injection vulnerability (CVE-2023-22527) in outdated versions of Confluence Data Center and Server, which allows an unauthenticated attacker to execute arbitrary code remotely. The vulnerability is exploited by injecting OGNL (Object-Graph Navigation Language) expressions into the application, as evidenced by POST requests to the "/template/aui/text-inline.vm" endpoint with specific content types and payloads. The search looks for POST requests with HTTP status codes 200 or 202, which may indicate successful exploitation attempts. Immediate patching to the latest version of Confluence is strongly recommended, as there are no known workarounds. This detection is crucial for identifying and responding to potential RCE attacks, ensuring that affected Confluence instances are secured against this critical threat. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/template/aui/text-inline.vm*" Web.http_method=POST Web.status IN (200, 202) by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527_filter`' +description: The following analytic identifies attempts to exploit a critical template + injection vulnerability (CVE-2023-22527) in outdated Confluence Data Center and + Server versions. It detects POST requests to the "/template/aui/text-inline.vm" + endpoint with HTTP status codes 200 or 202, indicating potential OGNL injection + attacks. This activity is significant as it allows unauthenticated attackers to + execute arbitrary code remotely. If confirmed malicious, attackers could gain full + control over the affected Confluence instance, leading to data breaches, system + compromise, and further network infiltration. Immediate patching is essential to + mitigate this threat. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url="*/template/aui/text-inline.vm*" Web.http_method=POST Web.status IN + (200, 202) by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `confluence_pre_auth_rce_via_ognl_injection_cve_2023_22527_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. known_false_positives: False positives may be present with legitimate applications. @@ -28,7 +36,8 @@ tags: atomic_guid: [] confidence: 90 impact: 90 - message: Exploitation attempts on a known vulnerability in Atlassian Confluence detected. The source IP is $src$ and the destination hostname is $dest$. + message: Exploitation attempts on a known vulnerability in Atlassian Confluence + detected. The source IP is $src$ and the destination hostname is $dest$. mitre_attack_id: - T1190 observable: @@ -55,6 +64,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/suricata_confluence_cve-2023-22527.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/suricata_confluence_cve-2023-22527.log source: suricata sourcetype: suricata diff --git a/detections/web/confluence_unauthenticated_remote_code_execution_cve_2022_26134.yml b/detections/web/confluence_unauthenticated_remote_code_execution_cve_2022_26134.yml index 0d6417a8f5..99ce8e6a16 100644 --- a/detections/web/confluence_unauthenticated_remote_code_execution_cve_2022_26134.yml +++ b/detections/web/confluence_unauthenticated_remote_code_execution_cve_2022_26134.yml @@ -1,18 +1,20 @@ name: Confluence Unauthenticated Remote Code Execution CVE-2022-26134 id: fcf4bd3f-a79f-4b7a-83bf-2692d60b859c -version: 1 -date: '2022-06-03' +version: 2 +date: '2024-05-30' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic assists with identifying CVE-2022-26134 based - exploitation utilizing the Web datamodel to cover network and CIM compliant web - logs. The parameters were captured from live scanning and the POC provided by Rapid7. - This analytic is written against multiple proof of concept codes released and seen - in the wild (scanning). During triage, review any endpoint based logs for further - activity including writing a jsp file to disk and commands/processes spawning running - as root from the Confluence process. -data_source: +description: The following analytic detects attempts to exploit CVE-2022-26134, an + unauthenticated remote code execution vulnerability in Confluence. It leverages + the Web datamodel to analyze network and CIM-compliant web logs, identifying suspicious + URL patterns and parameters indicative of exploitation attempts. This activity is + significant as it allows attackers to execute arbitrary code on the Confluence server + without authentication, potentially leading to full system compromise. If confirmed + malicious, this could result in unauthorized access, data exfiltration, and further + lateral movement within the network. Immediate investigation and remediation are + crucial to prevent extensive damage. +data_source: - Palo Alto Network Threat search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*${*", "*%2F%7B*") (Web.url="*org.apache.commons.io.IOUtils*" @@ -73,7 +75,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/confluence.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/confluence.log source: pan:threat sourcetype: pan:threat update_timestamp: true diff --git a/detections/web/connectwise_screenconnect_authentication_bypass.yml b/detections/web/connectwise_screenconnect_authentication_bypass.yml index c5339c82ed..53cb0b4819 100644 --- a/detections/web/connectwise_screenconnect_authentication_bypass.yml +++ b/detections/web/connectwise_screenconnect_authentication_bypass.yml @@ -1,21 +1,37 @@ name: ConnectWise ScreenConnect Authentication Bypass id: d3f7a803-e802-448b-8eb2-e796b223bfff -version: 2 -date: '2024-02-23' +version: 3 +date: '2024-05-24' author: Michael Haag, Splunk -data_source: +data_source: - Suricata type: TTP status: production -description: This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/SetupWizard.aspx/*","*/SetupWizard/") Web.status=200 Web.http_method=POST by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status, Web.http_method, sourcetype, source - | rex field=Web.url "/SetupWizard.aspx/(?.+)" - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `connectwise_screenconnect_authentication_bypass_filter`' -how_to_implement: To implement this analytic, ensure proper logging is occurring with IIS, Apache, or a Proxy server and that these logs are being ingested into Splunk. The analytic was written against Suricata. The proper TA will need to be enabled and should be mapped to CIM and the Web datamodel. Ingestion of the data source is required to utilize this detection. In addition, if it is not mapped to the datamodel, modify the query for your application logs to look for requests the same URI and investigate further. -known_false_positives: False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise. +description: The following analytic detects attempts to exploit the ConnectWise ScreenConnect + CVE-2024-1709 vulnerability, which allows attackers to bypass authentication via + an alternate path or channel. It leverages web request logs to identify access to + the SetupWizard.aspx page, indicating potential exploitation. This activity is significant + as it can lead to unauthorized administrative access and remote code execution. + If confirmed malicious, attackers could create administrative users and gain full + control over the affected system, posing severe security risks. Immediate remediation + by updating to version 23.9.8 or above is recommended. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/SetupWizard.aspx/*","*/SetupWizard/") Web.status=200 Web.http_method=POST + by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status, Web.http_method, + sourcetype, source | rex field=Web.url "/SetupWizard.aspx/(?.+)" | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `connectwise_screenconnect_authentication_bypass_filter`' +how_to_implement: To implement this analytic, ensure proper logging is occurring with + IIS, Apache, or a Proxy server and that these logs are being ingested into Splunk. + The analytic was written against Suricata. The proper TA will need to be enabled + and should be mapped to CIM and the Web datamodel. Ingestion of the data source + is required to utilize this detection. In addition, if it is not mapped to the datamodel, + modify the query for your application logs to look for requests the same URI and + investigate further. +known_false_positives: False positives are not expected, as the detection is based + on the presence of web requests to the SetupWizard.aspx page, which is not a common + page to be accessed by legitimate users. Note that the analytic is limited to HTTP + POST and a status of 200 to reduce false positives. Modify the query as needed to + reduce false positives or hunt for additional indicators of compromise. references: - https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass - https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2 @@ -26,7 +42,8 @@ tags: asset_type: Web Server confidence: 100 impact: 100 - message: An authentication bypass attempt against ScreenConnect has been detected on $dest$. + message: An authentication bypass attempt against ScreenConnect has been detected + on $dest$. mitre_attack_id: - T1190 observable: @@ -49,10 +66,11 @@ tags: security_domain: network cve: - CVE-2024-1708 - - CVE-2024-1709 + - CVE-2024-1709 tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/connectwise_auth_suricata.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/connectwise_auth_suricata.log sourcetype: suricata source: suricata diff --git a/detections/web/detect_remote_access_software_usage_url.yml b/detections/web/detect_remote_access_software_usage_url.yml index 8d54253062..42460961f3 100644 --- a/detections/web/detect_remote_access_software_usage_url.yml +++ b/detections/web/detect_remote_access_software_usage_url.yml @@ -1,22 +1,34 @@ name: Detect Remote Access Software Usage URL id: 9296f515-073c-43a5-88ec-eda5a4626654 -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-09' author: Steven Dick status: production type: Anomaly -description: The following analytic detects when a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. -data_source: +description: The following analytic detects the execution of known remote access software + within the environment. It leverages network logs mapped to the Web data model, + identifying specific URLs and user agents associated with remote access tools like + AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries + often use these utilities to maintain unauthorized remote access. If confirmed malicious, + this could allow attackers to control systems remotely, exfiltrate data, or further + compromise the network, posing a severe security risk. +data_source: - Palo Alto Network Threat -search: '| tstats count min(_time) as firstTime max(_time) as lastTime latest(Web.http_method) as http_method latest(Web.http_user_agent) as http_user_agent latest(Web.url) as url latest(Web.user) as user latest(Web.dest) as dest from datamodel=Web by Web.action Web.src Web.category Web.url_domain - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `drop_dm_object_name("Web")` - | lookup remote_access_software remote_domain AS url_domain OUTPUT isutility, description as signature, comment_reference as desc, category - | search isutility = True - | `detect_remote_access_software_usage_url_filter`' -how_to_implement: The detection is based on data that originates from network logs. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network logs. The logs must also be mapped to the `Web` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. -known_false_positives: It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime latest(Web.http_method) + as http_method latest(Web.http_user_agent) as http_user_agent latest(Web.url) as + url latest(Web.user) as user latest(Web.dest) as dest from datamodel=Web by Web.action + Web.src Web.category Web.url_domain | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `drop_dm_object_name("Web")` | lookup remote_access_software remote_domain AS + url_domain OUTPUT isutility, description as signature, comment_reference as desc, + category | search isutility = True | `detect_remote_access_software_usage_url_filter`' +how_to_implement: The detection is based on data that originates from network logs. + These logs must be processed using the appropriate Splunk Technology Add-ons that + are specific to the network logs. The logs must also be mapped to the `Web` data + model. Use the Splunk Common Information Model (CIM) to normalize the field names + and speed up the data modeling process. +known_false_positives: It is possible that legitimate remote access software is used + within the environment. Ensure that the lookup is reviewed and updated with any + additional remote access software that is used within the environment. references: - https://attack.mitre.org/techniques/T1219/ - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/ @@ -29,7 +41,8 @@ tags: asset_type: Network confidence: 50 impact: 50 - message: A domain for a known remote access software $url_domain$ was contacted by $src$. + message: A domain for a known remote access software $url_domain$ was contacted + by $src$. mitre_attack_id: - T1219 observable: @@ -53,13 +66,14 @@ tags: - _time - Web.action - Web.src - - Web.category - - Web.url_domain + - Web.category + - Web.url_domain risk_score: 25 security_domain: network tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_palo.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1219/screenconnect/screenconnect_palo.log source: screenconnect_palo - sourcetype: pan:threat \ No newline at end of file + sourcetype: pan:threat diff --git a/detections/web/exploit_public_facing_application_via_apache_commons_text.yml b/detections/web/exploit_public_facing_application_via_apache_commons_text.yml index 84e60aed5b..7d640a4274 100644 --- a/detections/web/exploit_public_facing_application_via_apache_commons_text.yml +++ b/detections/web/exploit_public_facing_application_via_apache_commons_text.yml @@ -5,20 +5,16 @@ date: '2024-05-21' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies activity related to Text4Shell, or - the critical vulnerability CVE-2022-42889 in Apache Commons Text Library. Apache - Commons Text versions 1.5 through 1.9 are affected, but it has been patched in version - 1.10. The analytic may need to be tuned for your environment before enabling as - a TTP, or direct Notable. Apache Commons Text is a Java library described as a library - focused on algorithms working on strings. We can see it as a general-purpose text - manipulation toolkit. This vulnerability affects the StringSubstitutor interpolator - class, which is included in the Commons Text library. A default interpolator allows - for string lookups that can lead to Remote Code Execution. This is due to a logic - flaw that makes the script, dns, and url lookup keys interpolated by default, as - opposed to what it should be, according to the documentation of the StringLookupFactory - class. Those keys allow an attacker to execute arbitrary code via lookups. -data_source: -- Bro +description: The following analytic detects attempts to exploit the CVE-2022-42889 + vulnerability in the Apache Commons Text Library, known as Text4Shell. It leverages + the Web datamodel to identify suspicious HTTP requests containing specific lookup + keys (url, dns, script) that can lead to Remote Code Execution (RCE). This activity + is significant as it targets a critical vulnerability that can allow attackers to + execute arbitrary code on the server. If confirmed malicious, this could lead to + full system compromise, data exfiltration, or further lateral movement within the + network. +data_source: +- Nginx Access search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.http_method IN (POST, GET) by Web.src Web.status Web.uri_path Web.dest Web.http_method Web.uri_query Web.http_user_agent @@ -96,4 +92,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/text4shell/text4shell_nginx.log source: nginx:plus:kv - sourcetype: nginx:plus:kv \ No newline at end of file + sourcetype: nginx:plus:kv diff --git a/detections/web/f5_tmui_authentication_bypass.yml b/detections/web/f5_tmui_authentication_bypass.yml index 9f25f72989..57992b1fa8 100644 --- a/detections/web/f5_tmui_authentication_bypass.yml +++ b/detections/web/f5_tmui_authentication_bypass.yml @@ -1,20 +1,30 @@ name: F5 TMUI Authentication Bypass id: 88bf127c-613e-4579-99e4-c4d4b02f3840 -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic is designed to detect attempts to exploit the CVE-2023-46747 vulnerability, a critical authentication bypass flaw in F5 BIG-IP that can lead to unauthenticated remote code execution (RCE). This vulnerability specifically affects the BIG-IP Configuration utility (TMUI) and has been assigned a high severity CVSSv3 score of 9.8. The analytic identifies this behavior by monitoring for a specific URI path - "*/mgmt/tm/auth/user/*", with the PATCH method and 200 status. Additional URI's will occur around the same time include "*/mgmt/shared/authn/login*" and "*/tmui/login.jsp*", which are associated with the exploitation of this vulnerability. This behavior is significant for a Security Operations Center (SOC) as it indicates an attempt to bypass authentication mechanisms, potentially leading to unauthorized access and control over the system. If a true positive is identified, it suggests that an attacker is attempting to exploit a known vulnerability to gain unauthorized access and execute arbitrary code, which could lead to data theft, system disruption, or further malicious activities within the network. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/mgmt/tm/auth/user/*") Web.http_method=PATCH Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic detects attempts to exploit the CVE-2023-46747 + vulnerability, an authentication bypass flaw in F5 BIG-IP's Configuration utility + (TMUI). It identifies this activity by monitoring for specific URI paths such as + "*/mgmt/tm/auth/user/*" with the PATCH method and a 200 status code. This behavior + is significant for a SOC as it indicates potential unauthorized access attempts, + leading to remote code execution. If confirmed malicious, an attacker could gain + unauthorized access, execute arbitrary code, steal data, disrupt systems, or conduct + further malicious activities within the network. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/mgmt/tm/auth/user/*") Web.http_method=PATCH Web.status=200 + by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, + Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `f5_tmui_authentication_bypass_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on Web traffic that include fields relevant for traffic into the `Web` datamodel. -known_false_positives: False positives should be limited to as this is strict to active exploitation. Reduce noise by filtering to F5 devices with TMUI enabled or filter data as needed. +known_false_positives: False positives should be limited to as this is strict to active + exploitation. Reduce noise by filtering to F5 devices with TMUI enabled or filter + data as needed. references: - https://www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/ - https://github.com/projectdiscovery/nuclei-templates/blob/3b0bb71bd627c6c3139e1d06c866f8402aa228ae/http/cves/2023/CVE-2023-46747.yaml @@ -27,7 +37,8 @@ tags: - CVE-2023-46747 confidence: 90 impact: 100 - message: Potential CVE-2023-46747 F5 TMUI Authentication Bypass may be occurring against $dest$ from $src$. + message: Potential CVE-2023-46747 F5 TMUI Authentication Bypass may be occurring + against $dest$ from $src$. observable: - name: dest type: Hostname @@ -55,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/f5/f5_tmui.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/f5/f5_tmui.log source: suricata sourcetype: suricata diff --git a/detections/web/fortinet_appliance_auth_bypass.yml b/detections/web/fortinet_appliance_auth_bypass.yml index 05700479c0..185ae83c36 100644 --- a/detections/web/fortinet_appliance_auth_bypass.yml +++ b/detections/web/fortinet_appliance_auth_bypass.yml @@ -1,31 +1,19 @@ name: Fortinet Appliance Auth bypass id: a83122f2-fa09-4868-a230-544dbc54bc1c -version: 1 -date: '2022-10-14' +version: 2 +date: '2024-05-12' author: Michael Haag, Splunk status: production type: TTP -description: 'CVE-2022-40684 is a Fortinet appliance auth bypass that is actively - being exploited and a POC is released publicy. The POC adds a SSH key to the appliance. - Note that the exploit can be used with any HTTP method (GET, POST, PUT, DELETE, - etc). The REST API request failing is not an indication that an attacker was unsuccessful. - Horizon3 was able to modify the admin SSH keys though a REST API request that reportedly - failed. The collection /api/v2/ endpoints can be used to configure the system and - modify the administrator user. Any logs found that meet the above conditions and - also have a URL containing /api/v2/ should be cause for concern. Further investigation - of any matching log entries can reveal any damage an attack has done. Additionally, - an attacker may perform the following actions to further compromise a system Modify - the admin SSH key to enable the attacker to login to the compromised system. - - Add new local users. - - Update networking configurations to reroute traffic. - - Download the system configuration. - - Initiate packet captures to capture other sensitive system information. Reference - Horizon3.ai' -data_source: +description: 'The following analytic detects attempts to exploit CVE-2022-40684, a + Fortinet appliance authentication bypass vulnerability. It identifies REST API requests + to the /api/v2/ endpoint using various HTTP methods (GET, POST, PUT, DELETE) that + may indicate unauthorized modifications, such as adding SSH keys or creating new + users. This detection leverages the Web datamodel to monitor specific URL patterns + and HTTP methods. This activity is significant as it can lead to unauthorized access + and control over the appliance. If confirmed malicious, attackers could gain persistent + access, reroute network traffic, or capture sensitive information.' +data_source: - Palo Alto Network Threat search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/api/v2/cmdb/system/admin*") Web.http_method IN ("GET", "PUT") @@ -82,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/fortigate/fortinetcve202240684.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/fortigate/fortinetcve202240684.log source: pan:threat sourcetype: pan:threat update_timestamp: true diff --git a/detections/web/hunting_for_log4shell.yml b/detections/web/hunting_for_log4shell.yml index 85ef12d31c..d5aa4dc7ba 100644 --- a/detections/web/hunting_for_log4shell.yml +++ b/detections/web/hunting_for_log4shell.yml @@ -1,48 +1,19 @@ name: Hunting for Log4Shell id: 158b68fa-5d1a-11ec-aac8-acde48001122 -version: 1 -date: '2021-12-14' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: Hunting -description: 'The following hunting query assists with quickly assessing CVE-2021-44228, - or Log4Shell, activity mapped to the Web Datamodel. This is a combination query - attempting to identify, score and dashboard. Because the Log4Shell vulnerability - requires the string to be in the logs, this will work to identify the activity anywhere - in the HTTP headers using _raw. Modify the first line to use the same pattern matching - against other log sources. Scoring is based on a simple rubric of 0-5. 5 being the - best match, and less than 5 meant to identify additional patterns that will equate - to a higher total score. - - The first jndi match identifies the standard pattern of `{jndi:` - - jndi_fastmatch is meant to identify any jndi in the logs. The score is set low and - is meant to be the "base" score used later. - - jndi_proto is a protocol match that identifies `jndi` and one of `ldap, ldaps, rmi, - dns, nis, iiop, corba, nds, http, https.` - - all_match is a very well written regex by https://gist.github.com/Schvenn that identifies - nearly all patterns of this attack behavior. - - env works to identify environment variables in the header, meant to capture `AWS_ACCESS_KEY_ID`, - `AWS_SECRET_ACCESS_KEY` and `env`. - - uri_detect is string match looking for the common uri paths currently being scanned/abused - in the wild. - - keywords matches on enumerated values that, like `$ctx:loginId`, that may be found - in the header used by the adversary. - - lookup matching is meant to catch some basic obfuscation that has been identified - using upper, lower and date. - - Scoring will then occur based on any findings. The base score is meant to be 2 , - created by jndi_fastmatch. Everything else is meant to increase that score. - - Finally, a simple table is created to show the scoring and the _raw field. Sort - based on score or columns of interest.' -data_source: +description: 'The following analytic detects potential exploitation attempts of the + Log4Shell vulnerability (CVE-2021-44228) by analyzing HTTP headers for specific + patterns. It leverages the Web Datamodel and evaluates various indicators such as + the presence of `{jndi:`, environment variables, and common URI paths. This detection + is significant as Log4Shell allows remote code execution, posing a severe threat + to systems. If confirmed malicious, attackers could gain unauthorized access, execute + arbitrary code, and potentially compromise sensitive data, leading to extensive + damage and data breaches.' +data_source: - Nginx Access search: '| from datamodel Web.Web | eval jndi=if(match(_raw, "(\{|%7B)[jJnNdDiI]{4}:"),4,0) | eval jndi_fastmatch=if(match(_raw, "[jJnNdDiI]{4}"),2,0) | eval jndi_proto=if(match(_raw,"(?i)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http|https):"),5,0) @@ -56,7 +27,8 @@ search: '| from datamodel Web.Web | eval jndi=if(match(_raw, "(\{|%7B)[jJnNdDiI] "(?i)({|%7b)(main|sys|k8s|spring|lower|upper|env|date|sd)"),4,0) | addtotals fieldname=Score, jndi, jndi_proto, env_var, uridetect, all_match, jndi_fastmatch, keywords, obf, lookups | where Score > 2 | stats values(Score) by jndi, jndi_proto, env_var, uridetect, - all_match, jndi_fastmatch, keywords, lookups, obf, dest, src, http_method, _raw | `hunting_for_log4shell_filter`' + all_match, jndi_fastmatch, keywords, lookups, obf, dest, src, http_method, _raw + | `hunting_for_log4shell_filter`' how_to_implement: Out of the box, the Web datamodel is required to be pre-filled. However, tested was performed against raw httpd access logs. Change the first line to any dataset to pass the regex's against. @@ -109,6 +81,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/log4shell-nginx.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/log4shell-nginx.log source: /var/log/nginx/access.log sourcetype: nginx:plus:kv diff --git a/detections/web/ivanti_connect_secure_command_injection_attempts.yml b/detections/web/ivanti_connect_secure_command_injection_attempts.yml index 1ed741ff9c..c65d92aa41 100644 --- a/detections/web/ivanti_connect_secure_command_injection_attempts.yml +++ b/detections/web/ivanti_connect_secure_command_injection_attempts.yml @@ -1,20 +1,32 @@ name: Ivanti Connect Secure Command Injection Attempts id: 1f32a7e0-a060-4545-b7de-73fcf9ad536e -version: 2 -date: '2024-01-17' +version: 3 +date: '2024-05-20' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: This analytic is designed to identify the exploit phase of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a POST request is made to the /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection URI. This request exploits the command injection vulnerability to execute arbitrary commands. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN("*/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection*","*/api/v1/totp/user-backup-code/../../license/keys-status/*") Web.http_method IN ("POST", "GET") Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.http_method, Web.status - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `ivanti_connect_secure_command_injection_attempts_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +description: The following analytic identifies attempts to exploit the CVE-2023-46805 + and CVE-2024-21887 vulnerabilities in Ivanti Connect Secure. It detects POST requests + to specific URIs that leverage command injection to execute arbitrary commands. + The detection uses the Web datamodel to monitor for these requests and checks for + a 200 OK response, indicating a successful exploit attempt. This activity is significant + as it can lead to unauthorized command execution on the server. If confirmed malicious, + attackers could gain control over the system, leading to potential data breaches + or further network compromise. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN("*/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection*","*/api/v1/totp/user-backup-code/../../license/keys-status/*") + Web.http_method IN ("POST", "GET") Web.status=200 by Web.src, Web.dest, Web.http_user_agent, + Web.url, Web.http_method, Web.status | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `ivanti_connect_secure_command_injection_attempts_filter`' +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, + or Splunk for Palo Alto. +known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. + False positives may occur if the URI path is IP-restricted or externally blocked. + It's recommended to review the context of the alerts and adjust the analytic parameters + to better fit the specific environment. references: - https://github.com/RootUp/PersonalStuff/blob/master/http-vuln-cve2023-46805_2024_21887.nse - https://github.com/projectdiscovery/nuclei-templates/blob/c6b351e71b0fb0e40e222e97038f1fe09ac58194/http/misconfiguration/ivanti/CVE-2023-46085-CVE-2024-21887-mitigation-not-applied.yaml @@ -54,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_secure_connect_exploitphase.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_secure_connect_exploitphase.log source: suricata sourcetype: suricata diff --git a/detections/web/ivanti_connect_secure_ssrf_in_saml_component.yml b/detections/web/ivanti_connect_secure_ssrf_in_saml_component.yml index f30d79da35..d47456ac9a 100644 --- a/detections/web/ivanti_connect_secure_ssrf_in_saml_component.yml +++ b/detections/web/ivanti_connect_secure_ssrf_in_saml_component.yml @@ -1,23 +1,35 @@ name: Ivanti Connect Secure SSRF in SAML Component id: 8e6ca490-7af3-4299-9a24-39fb69759925 -version: 1 -date: '2024-02-05' +version: 2 +date: '2024-05-29' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic is designed to identify POST request activities targeting specific endpoints known to be vulnerable to the SSRF issue (CVE-2024-21893) in Ivanti's products. It aggregates data from the Web data model, focusing on endpoints /dana-ws/saml20.ws, /dana-ws/saml.ws, /dana-ws/samlecp.ws, and /dana-na/auth/saml-logout.cgi. The query filters for POST requests that received a HTTP 200 OK response, indicating successful request execution. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/dana-ws/saml20.ws*","*/dana-ws/saml.ws*","*/dana-ws/samlecp.ws*","*/dana-na/auth/saml-logout.cgi/*") Web.http_method=POST Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status, Web.http_method - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `ivanti_connect_secure_ssrf_in_saml_component_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the HTTP Status is removed, as most failed attempts result in a 301. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +description: The following analytic identifies POST requests targeting endpoints vulnerable + to the SSRF issue (CVE-2024-21893) in Ivanti's products. It leverages the Web data + model, focusing on endpoints such as /dana-ws/saml20.ws, /dana-ws/saml.ws, /dana-ws/samlecp.ws, + and /dana-na/auth/saml-logout.cgi. The detection filters for POST requests that + received an HTTP 200 OK response, indicating successful execution. This activity + is significant as it may indicate an attempt to exploit SSRF vulnerabilities, potentially + allowing attackers to access internal services or sensitive data. If confirmed malicious, + this could lead to unauthorized access and data exfiltration. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/dana-ws/saml20.ws*","*/dana-ws/saml.ws*","*/dana-ws/samlecp.ws*","*/dana-na/auth/saml-logout.cgi/*") + Web.http_method=POST Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url, + Web.status, Web.http_method | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `ivanti_connect_secure_ssrf_in_saml_component_filter`' +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, + or Splunk for Palo Alto. +known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. + False positives may occur if the HTTP Status is removed, as most failed attempts + result in a 301. It's recommended to review the context of the alerts and adjust + the analytic parameters to better fit the specific environment. references: - - https://attackerkb.com/topics/FGlK1TVnB2/cve-2024-21893/rapid7-analysis - - https://www.assetnote.io/resources/research/ivantis-pulse-connect-secure-auth-bypass-round-two +- https://attackerkb.com/topics/FGlK1TVnB2/cve-2024-21893/rapid7-analysis +- https://www.assetnote.io/resources/research/ivantis-pulse-connect-secure-auth-bypass-round-two tags: cve: - CVE-2024-21893 @@ -55,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_saml.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_saml.log source: suricata - sourcetype: suricata \ No newline at end of file + sourcetype: suricata diff --git a/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml b/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml index aec9e9a8cd..a3724e46c5 100644 --- a/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml +++ b/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml @@ -1,20 +1,32 @@ name: Ivanti Connect Secure System Information Access via Auth Bypass id: d51c13dd-a232-4c83-a2bb-72ab36233c5d -version: 1 -date: '2024-01-16' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: Anomaly -data_source: +data_source: - Suricata -description: This analytic is designed to identify the "check phase" of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a GET request is made to the /api/v1/totp/user-backup-code/../../system/system-information URI. This request exploits the authentication bypass vulnerability to gain access to system information. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/api/v1/totp/user-backup-code/../../system/system-information*" Web.http_method=GET Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies attempts to exploit the CVE-2023-46805 + and CVE-2024-21887 vulnerabilities in Ivanti Connect Secure. It detects GET requests + to the /api/v1/totp/user-backup-code/../../system/system-information URI, which + leverage an authentication bypass to access system information. The detection uses + the Web datamodel to identify requests with a 200 OK response, indicating a successful + exploit attempt. This activity is significant as it reveals potential unauthorized + access to sensitive system information. If confirmed malicious, attackers could + gain critical insights into the system, facilitating further exploitation and compromise. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url="*/api/v1/totp/user-backup-code/../../system/system-information*" + Web.http_method=GET Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `ivanti_connect_secure_system_information_access_via_auth_bypass_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. -known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, + or Splunk for Palo Alto. +known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. + False positives may occur if the URI path is IP-restricted or externally blocked. + It's recommended to review the context of the alerts and adjust the analytic parameters + to better fit the specific environment. references: - https://github.com/RootUp/PersonalStuff/blob/master/http-vuln-cve2023-46805_2024_21887.nse - https://github.com/projectdiscovery/nuclei-templates/blob/c6b351e71b0fb0e40e222e97038f1fe09ac58194/http/misconfiguration/ivanti/CVE-2023-46085-CVE-2024-21887-mitigation-not-applied.yaml @@ -51,6 +63,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_secure_connect_checkphase.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_secure_connect_checkphase.log source: suricata sourcetype: suricata diff --git a/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078.yml b/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078.yml index 493f50e042..190dd5dbca 100644 --- a/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078.yml +++ b/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078.yml @@ -1,21 +1,33 @@ name: Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35078 id: 66b9c9ba-7fb2-4e80-a3a2-496e5e078167 -version: 1 -date: '2023-07-31' +version: 2 +date: '2024-05-18' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The given analytic is designed to detect the exploitation of CVE-2023-35078, a vulnerability in Ivanti Endpoint Manager Mobile (EPMM) affecting versions up to 11.4. Specifically, the query searches web logs for HTTP requests to the potentially vulnerable endpoint "/mifs/aad/api/v2/authorized/users?*" with a successful status code of 200. This analytic is instrumental in detecting unauthorized remote access to restricted functionalities or resources within the application, a behavior worth identifying for a Security Operations Center (SOC). By monitoring specific patterns and successful access indicators, it reveals an active attempt to exploit the vulnerability, potentially leading to data theft, unauthorized modifications, or further system compromise. If successfully executed, the impact can be severe, necessitating immediate action. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/mifs/aad/api/v2/authorized/users?*") Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078_filter`' -how_to_implement: To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. -known_false_positives: The Proof of Concept exploit script indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search. If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability. +description: The following analytic detects attempts to exploit CVE-2023-35078, a + vulnerability in Ivanti Endpoint Manager Mobile (EPMM) versions up to 11.4. It identifies + HTTP requests to the endpoint "/mifs/aad/api/v2/authorized/users?*" with a status + code of 200 in web logs. This activity is significant as it indicates unauthorized + remote access to restricted functionalities or resources. If confirmed malicious, + this could lead to data theft, unauthorized modifications, or further system compromise, + necessitating immediate action to mitigate potential severe impacts. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/mifs/aad/api/v2/authorized/users?*") Web.status=200 by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35078_filter`' +how_to_implement: To implement this analytic, a network product similar to Suricata + or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work + with your products. +known_false_positives: The Proof of Concept exploit script indicates that status=200 + is required for successful exploitation of the vulnerability. False positives may + be present if status=200 is removed from the search. If it is removed,then the + search also alert on status=301 and status=404 which indicates unsuccessful exploitation + attempts. Analysts may find it useful to hunt for these status codes as well, but + it is likely to produce a significant number of alerts as this is a widespread vulnerability. references: - https://forums.ivanti.com/s/article/CVE-2023-35078-Remote-unauthenticated-API-access-vulnerability?language=en_US - https://github.com/vchan-in/CVE-2023-35078-Exploit-POC/blob/main/cve_2023_35078_poc.py @@ -53,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_CVE202335078.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_CVE202335078.log source: suricata sourcetype: suricata diff --git a/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082.yml b/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082.yml index c5be53493f..83094bd53a 100644 --- a/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082.yml +++ b/detections/web/ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082.yml @@ -1,22 +1,35 @@ name: Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35082 id: e03edeba-4942-470c-a664-27253f3ad351 -version: 1 -date: '2023-08-08' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: 'The following analytic detects potential unauthorized access attempts exploiting CVE-2023-35082 within Ivantis software products. Initially assessed to affect only MobileIron Core versions up to 11.2, further insights revealed its influence extending to Ivanti Endpoint Manager Mobile (EPMM) versions 11.10, 11.9, 11.8, and MobileIron Core 11.7 and below. The vulnerability facilitates unauthorized API access via the specific URI path /mifs/asfV3/api/v2/. The analytic identifies this behavior by monitoring web access logs for this URI pattern coupled with a HTTP 200 response code, signifying successful unauthorized access. - Such behavior is imperative for a Security Operations Center (SOC) to recognize, as it highlights potential security breaches which, if not addressed, could lead to unauthorized data access, system modifications, or further exploitation. In the event of a true positive, the implications are severe: an attacker might have gained unbridled access to sensitive organizational data or could modify systems maliciously. Be vigilant of potential false positives; benign activities might occasionally match the pattern. During triage, closely scrutinize the source of the access request and its subsequent actions. This analytic aids analysts in early threat detection, allowing for proactive risk mitigation.' -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/mifs/asfV3/api/v2/*") Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082_filter`' -how_to_implement: To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. -known_false_positives: Similar to CVE-2023-35078, the path for exploitation indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search. If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability. +description: 'The following analytic detects potential unauthorized access attempts + exploiting CVE-2023-35082 within Ivanti''s software products. It identifies access + to the specific URI path /mifs/asfV3/api/v2/ with an HTTP 200 response code in web + access logs, indicating successful unauthorized access. This activity is significant + for a SOC as it highlights potential security breaches that could lead to unauthorized + data access or system modifications. If confirmed malicious, an attacker could gain + unbridled access to sensitive organizational data or modify systems maliciously, + posing severe security risks.' +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/mifs/asfV3/api/v2/*") Web.status=200 by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `ivanti_epmm_remote_unauthenticated_api_access_cve_2023_35082_filter`' +how_to_implement: To implement this analytic, a network product similar to Suricata + or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work + with your products. +known_false_positives: Similar to CVE-2023-35078, the path for exploitation indicates + that status=200 is required for successful exploitation of the vulnerability. False + positives may be present if status=200 is removed from the search. If it is removed,then + the search also alert on status=301 and status=404 which indicates unsuccessful + exploitation attempts. Analysts may find it useful to hunt for these status codes + as well, but it is likely to produce a significant number of alerts as this is a + widespread vulnerability. references: - https://forums.ivanti.com/s/article/CVE-2023-35082-Remote-Unauthenticated-API-Access-Vulnerability-in-MobileIron-Core-11-2-and-older?language=en_US - https://github.com/vchan-in/CVE-2023-35078-Exploit-POC/blob/main/cve_2023_35078_poc.py @@ -55,7 +68,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_CVE202335082.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/suricata_ivanti_CVE202335082.log source: suricata sourcetype: suricata diff --git a/detections/web/ivanti_sentry_authentication_bypass.yml b/detections/web/ivanti_sentry_authentication_bypass.yml index 637e56a58d..220df4f5d7 100644 --- a/detections/web/ivanti_sentry_authentication_bypass.yml +++ b/detections/web/ivanti_sentry_authentication_bypass.yml @@ -1,21 +1,33 @@ name: Ivanti Sentry Authentication Bypass id: b8e0d1cf-e6a8-4d46-a5ae-aebe18ead8f8 -version: 1 -date: '2023-08-24' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: This analytic is designed to detect unauthenticated access to the System Manager Portal in Ivanti Sentry, formerly known as MobileIron Sentry. The vulnerability, designated as CVE-2023-38035, affects all supported versions 9.18, 9.17, and 9.16, as well as older versions. The analytic works by monitoring for changes in the configuration of Sentry and the underlying operating system. Such changes could indicate an attacker attempting to execute OS commands as root. This behavior is of significant concern for a Security Operations Center (SOC) as it presents a substantial security risk, particularly if port 8443, the default port for the System Manager Portal, is exposed to the internet. If the analytic returns a true positive, it suggests that an attacker has gained unauthorized access to the Sentry system, potentially leading to a significant system compromise and data breach. It is important to note that while the issue has a high CVSS score, the risk of exploitation is low for customers who do not expose port 8443 to the internet. The search specifically looks for HTTP requests to certain endpoints ("/mics/services/configservice/*", "/mics/services/*","/mics/services/MICSLogService*") and HTTP status code of 200. Unusual or unexpected patterns in these parameters could indicate an attack. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/mics/services/configservice/*", "/mics/services/*","/mics/services/MICSLogService*") Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic identifies unauthenticated access attempts to + the System Manager Portal in Ivanti Sentry, exploiting CVE-2023-38035. It detects + this activity by monitoring HTTP requests to specific endpoints ("/mics/services/configservice/*", + "/mics/services/*", "/mics/services/MICSLogService*") with a status code of 200. + This behavior is significant for a SOC as it indicates potential unauthorized access, + which could lead to OS command execution as root. If confirmed malicious, this activity + could result in significant system compromise and data breaches, especially if port + 8443 is exposed to the internet. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/mics/services/configservice/*", "/mics/services/*","/mics/services/MICSLogService*") + Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, + Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `ivanti_sentry_authentication_bypass_filter`' -how_to_implement: To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. -known_false_positives: It is important to note that false positives may occur if the search criteria are expanded beyond the HTTP status code 200. In other words, if the search includes other HTTP status codes, the likelihood of encountering false positives increases. This is due to the fact that HTTP status codes other than 200 may not necessarily indicate a successful exploitation attempt. +how_to_implement: To implement this analytic, a network product similar to Suricata + or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work + with your products. +known_false_positives: It is important to note that false positives may occur if the + search criteria are expanded beyond the HTTP status code 200. In other words, if + the search includes other HTTP status codes, the likelihood of encountering false + positives increases. This is due to the fact that HTTP status codes other than 200 + may not necessarily indicate a successful exploitation attempt. references: - https://github.com/horizon3ai/CVE-2023-38035/blob/main/CVE-2023-38035.py - https://www.horizon3.ai/ivanti-sentry-authentication-bypass-cve-2023-38035-deep-dive/ @@ -29,7 +41,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible exploitation of CVE-2023-38035 against $dest$. + message: Possible exploitation of CVE-2023-38035 against $dest$. mitre_attack_id: - T1190 observable: @@ -59,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/ivanti_sentry_CVE_2023_38035.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ivanti/ivanti_sentry_CVE_2023_38035.log source: suricata sourcetype: suricata diff --git a/detections/web/jenkins_arbitrary_file_read_cve_2024_23897.yml b/detections/web/jenkins_arbitrary_file_read_cve_2024_23897.yml index 6129793455..145082ee5c 100644 --- a/detections/web/jenkins_arbitrary_file_read_cve_2024_23897.yml +++ b/detections/web/jenkins_arbitrary_file_read_cve_2024_23897.yml @@ -1,19 +1,29 @@ name: Jenkins Arbitrary File Read CVE-2024-23897 id: c641260d-2b48-4eb1-b1e8-2cc5b8b99ab1 -version: 1 -date: '2024-01-26' +version: 2 +date: '2024-05-24' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Nginx Access -description: The following analtyic identifies a Jenkins Arbitrary File Read CVE-2024-23897 exploitation. This attack allows an attacker to read arbitrary files on the Jenkins server. This can be used to obtain sensitive information such as credentials, private keys, and other sensitive information. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/cli?remoting=false*" Web.status=200 Web.http_method=POST by Web.src, Web.dest, Web.http_user_agent, Web.url Web.status, Web.http_method - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `jenkins_arbitrary_file_read_cve_2024_23897_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. If unable to utilize the Web datamodel, modify query to your data source. -known_false_positives: False positives should be limited as this detection is based on a specific URL path and HTTP status code. Adjust the search as necessary to fit the environment. +description: The following analytic identifies attempts to exploit Jenkins Arbitrary + File Read CVE-2024-23897. It detects HTTP POST requests to Jenkins URLs containing + "*/cli?remoting=false*" with a 200 status code. This activity is significant as + it indicates potential unauthorized access to sensitive files on the Jenkins server, + such as credentials and private keys. If confirmed malicious, this could lead to + severe data breaches, unauthorized access, and further exploitation within the environment. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url="*/cli?remoting=false*" Web.status=200 Web.http_method=POST by Web.src, + Web.dest, Web.http_user_agent, Web.url Web.status, Web.http_method | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `jenkins_arbitrary_file_read_cve_2024_23897_filter`' +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, + or Splunk for Palo Alto. If unable to utilize the Web datamodel, modify query to + your data source. +known_false_positives: False positives should be limited as this detection is based + on a specific URL path and HTTP status code. Adjust the search as necessary to fit + the environment. references: - https://github.com/projectdiscovery/nuclei-templates/pull/9025 - https://github.com/jenkinsci-cert/SECURITY-3314-3315 @@ -59,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jenkins/nginx_jenkins_cve_2023_23897.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jenkins/nginx_jenkins_cve_2023_23897.log source: nginx:plus:kv sourcetype: nginx:plus:kv diff --git a/detections/web/jetbrains_teamcity_authentication_bypass_cve_2024_27198.yml b/detections/web/jetbrains_teamcity_authentication_bypass_cve_2024_27198.yml index 20f44dd269..9548f959e1 100644 --- a/detections/web/jetbrains_teamcity_authentication_bypass_cve_2024_27198.yml +++ b/detections/web/jetbrains_teamcity_authentication_bypass_cve_2024_27198.yml @@ -1,19 +1,33 @@ name: JetBrains TeamCity Authentication Bypass CVE-2024-27198 id: fbcc04c7-8a79-453c-b3a9-c232c423bdd4 -version: 1 -date: '2024-03-04' +version: 2 +date: '2024-05-20' author: Michael Haag, Splunk -data_source: +data_source: - Suricata type: TTP status: production -description: 'The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution. Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures.' -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where ((Web.url="*?jsp=*" AND Web.url="*;.jsp*") Web.status=200 Web.http_method=POST) OR (Web.url IN ("*jsp=/app/rest/users;.jsp","*?jsp=/app/rest/users;.jsp","*?jsp=.*/app/rest/users/id:*/tokens;*") Web.status=200 Web.http_method=POST ) by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.status, Web.http_method, sourcetype, source - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `jetbrains_teamcity_authentication_bypass_cve_2024_27198_filter`' -how_to_implement: The detection relies on the Web datamodel and a CIM compliant log source, that may include Nginx, TeamCity logs, or other web server logs. -known_false_positives: False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources. +description: 'The following analytic identifies attempts to exploit the JetBrains + TeamCity Authentication Bypass vulnerability (CVE-2024-27198). It detects suspicious + POST requests to the `/app/rest/users` and `/app/rest/users/id:1/tokens` endpoints, + which are indicative of attempts to create new administrator users or generate admin + access tokens without authentication. This detection leverages the Web datamodel + and CIM-compliant log sources, such as Nginx or TeamCity logs. This activity is + significant as it can lead to full control over the TeamCity server, including all + projects, builds, agents, and artifacts. If confirmed malicious, attackers could + gain unauthorized administrative access, leading to severe security breaches.' +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where ((Web.url="*?jsp=*" AND Web.url="*;.jsp*") Web.status=200 Web.http_method=POST) + OR (Web.url IN ("*jsp=/app/rest/users;.jsp","*?jsp=/app/rest/users;.jsp","*?jsp=.*/app/rest/users/id:*/tokens;*") + Web.status=200 Web.http_method=POST ) by Web.src, Web.dest, Web.http_user_agent, + Web.url, Web.status, Web.http_method, sourcetype, source | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `jetbrains_teamcity_authentication_bypass_cve_2024_27198_filter`' +how_to_implement: The detection relies on the Web datamodel and a CIM compliant log + source, that may include Nginx, TeamCity logs, or other web server logs. +known_false_positives: False positives are not expected, as this detection is based + on the presence of specific URI paths and HTTP methods that are indicative of the + CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based + on organization log sources. references: - https://github.com/projectdiscovery/nuclei-templates/pull/9279/files - https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/ @@ -26,7 +40,8 @@ tags: asset_type: Web Server confidence: 90 impact: 90 - message: Possible JetBrains TeamCity Authentication Bypass CVE-2024-27198 Attempt against $dest$ from $src$. + message: Possible JetBrains TeamCity Authentication Bypass CVE-2024-27198 Attempt + against $dest$ from $src$. mitre_attack_id: - T1190 observable: @@ -58,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27198.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27198.log sourcetype: suricata - source: suricata \ No newline at end of file + source: suricata diff --git a/detections/web/jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198.yml b/detections/web/jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198.yml index 5e43bd6eeb..132724f73a 100644 --- a/detections/web/jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198.yml +++ b/detections/web/jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198.yml @@ -1,20 +1,32 @@ name: JetBrains TeamCity Authentication Bypass Suricata CVE-2024-27198 id: fbcc04c7-8a79-453c-b3a9-c232c423bdd3 -version: 1 -date: '2024-03-04' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk -data_source: +data_source: - Suricata type: TTP status: production -description: 'The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution.Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures.' -search: '`suricata` - ((http.url="*?jsp=*" AND http.url="*;.jsp*") http.status=200 http_method=POST) OR (http.url IN ("*jsp=/app/rest/users;.jsp","*?jsp=/app/rest/users;.jsp","*?jsp=.*/app/rest/users/id:*/tokens;*") http.status=200 http_method=POST ) - | stats count min(_time) as firstTime max(_time) as lastTime by src, dest, http.http_user_agent, http.url, http.status,http_method - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)`| `jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198_filter`' -how_to_implement: The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed. -known_false_positives: False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources. +description: 'The following analytic detects attempts to exploit the CVE-2024-27198 + vulnerability in JetBrains TeamCity on-premises servers, which allows attackers + to bypass authentication mechanisms. It leverages Suricata HTTP traffic logs to + identify suspicious POST requests to the `/app/rest/users` and `/app/rest/users/id:1/tokens` + endpoints. This activity is significant because it can lead to unauthorized administrative + access, enabling attackers to gain full control over the TeamCity server, including + projects, builds, agents, and artifacts. If confirmed malicious, this could result + in severe security breaches and compromise the integrity of the development environment.' +search: '`suricata` ((http.url="*?jsp=*" AND http.url="*;.jsp*") http.status=200 http_method=POST) + OR (http.url IN ("*jsp=/app/rest/users;.jsp","*?jsp=/app/rest/users;.jsp","*?jsp=.*/app/rest/users/id:*/tokens;*") + http.status=200 http_method=POST ) | stats count min(_time) as firstTime max(_time) + as lastTime by src, dest, http.http_user_agent, http.url, http.status,http_method + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `jetbrains_teamcity_authentication_bypass_suricata_cve_2024_27198_filter`' +how_to_implement: The following detection relies on the Suricata TA and ensuring it + is properly configured to monitor HTTP traffic. Modify the query for your environment + and log sources as needed. +known_false_positives: False positives are not expected, as this detection is based + on the presence of specific URI paths and HTTP methods that are indicative of the + CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based + on organization log sources. references: - https://github.com/projectdiscovery/nuclei-templates/pull/9279/files - https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/ @@ -26,7 +38,8 @@ tags: asset_type: Web Server confidence: 90 impact: 90 - message: Possible JetBrains TeamCity Authentication Bypass Attempt against $dest$ from $src$. + message: Possible JetBrains TeamCity Authentication Bypass Attempt against $dest$ + from $src$. mitre_attack_id: - T1190 observable: @@ -56,6 +69,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27198.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27198.log sourcetype: suricata source: suricata diff --git a/detections/web/jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199.yml b/detections/web/jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199.yml index b796684e28..d1ed0622f0 100644 --- a/detections/web/jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199.yml +++ b/detections/web/jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199.yml @@ -1,19 +1,37 @@ name: JetBrains TeamCity Limited Auth Bypass Suricata CVE-2024-27199 id: a1e68dcd-2e24-4434-bd0e-b3d4de139d58 -version: 1 -date: '2024-03-04' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk -data_source: +data_source: - Suricata type: TTP status: production -description: 'CVE-2024-27199 reveals a critical vulnerability in JetBrains TeamCity web server, allowing unauthenticated attackers to bypass authentication for a limited set of endpoints. This vulnerability exploits path traversal issues, enabling attackers to access and potentially modify system settings or disclose sensitive server information without proper authentication. Identified vulnerable paths include /res/, /update/, and /.well-known/acme-challenge/, among others. Attackers can manipulate these paths to reach restricted JSP pages and servlet endpoints, such as /app/https/settings/uploadCertificate, which could allow for the uploading of malicious HTTPS certificates or modification of server settings. This detection aims to identify potential exploitation attempts by monitoring for unusual access patterns to these endpoints, which could indicate an authentication bypass attempt in progress.' -search: '`suricata` http.url IN ("*../admin/diagnostic.jsp*", "*../app/https/settings/*", "*../app/pipeline*", "*../app/oauth/space/createBuild.html*", "*../res/*", "*../update/*", "*../.well-known/acme-challenge/*", "*../app/availableRunners*", "*../app/https/settings/setPort*", "*../app/https/settings/certificateInfo*", "*../app/https/settings/defaultHttpsPort*", "*../app/https/settings/fetchFromAcme*", "*../app/https/settings/removeCertificate*", "*../app/https/settings/uploadCertificate*", "*../app/https/settings/termsOfService*", "*../app/https/settings/triggerAcmeChallenge*", "*../app/https/settings/cancelAcmeChallenge*", "*../app/https/settings/getAcmeOrder*", "*../app/https/settings/setRedirectStrategy*") http.status=200 http_method=GET - | stats count min(_time) as firstTime max(_time) as lastTime by src, dest, http_user_agent, http.url, http.status, http_method - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199_filter`' -how_to_implement: The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed. -known_false_positives: False positives are not expected, however, monitor, filter, and tune as needed based on organization log sources. The analytic is restricted to 200 and GET requests to specific URI paths, which should limit false positives. +description: 'The following analytic identifies attempts to exploit CVE-2024-27199, + a critical vulnerability in JetBrains TeamCity web server, allowing unauthenticated + access to specific endpoints. It detects unusual access patterns to vulnerable paths + such as /res/, /update/, and /.well-known/acme-challenge/ by monitoring HTTP traffic + logs via Suricata. This activity is significant as it could indicate an attacker + bypassing authentication to access or modify system settings. If confirmed malicious, + this could lead to unauthorized changes, disclosure of sensitive information, or + uploading of malicious certificates, severely compromising the server''s security.' +search: '`suricata` http.url IN ("*../admin/diagnostic.jsp*", "*../app/https/settings/*", + "*../app/pipeline*", "*../app/oauth/space/createBuild.html*", "*../res/*", "*../update/*", + "*../.well-known/acme-challenge/*", "*../app/availableRunners*", "*../app/https/settings/setPort*", + "*../app/https/settings/certificateInfo*", "*../app/https/settings/defaultHttpsPort*", + "*../app/https/settings/fetchFromAcme*", "*../app/https/settings/removeCertificate*", + "*../app/https/settings/uploadCertificate*", "*../app/https/settings/termsOfService*", + "*../app/https/settings/triggerAcmeChallenge*", "*../app/https/settings/cancelAcmeChallenge*", + "*../app/https/settings/getAcmeOrder*", "*../app/https/settings/setRedirectStrategy*") + http.status=200 http_method=GET | stats count min(_time) as firstTime max(_time) + as lastTime by src, dest, http_user_agent, http.url, http.status, http_method | + `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `jetbrains_teamcity_limited_auth_bypass_suricata_cve_2024_27199_filter`' +how_to_implement: The following detection relies on the Suricata TA and ensuring it + is properly configured to monitor HTTP traffic. Modify the query for your environment + and log sources as needed. +known_false_positives: False positives are not expected, however, monitor, filter, + and tune as needed based on organization log sources. The analytic is restricted + to 200 and GET requests to specific URI paths, which should limit false positives. references: - https://github.com/projectdiscovery/nuclei-templates/blob/f644ec82dfe018890c6aa308967424d26c0f1522/http/cves/2024/CVE-2024-27199.yaml - https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/ @@ -25,7 +43,8 @@ tags: asset_type: Web Server confidence: 70 impact: 90 - message: Possible JetBrains TeamCity Limited Authentication Bypass Attempt against $dest$ from $src$. + message: Possible JetBrains TeamCity Limited Authentication Bypass Attempt against + $dest$ from $src$. mitre_attack_id: - T1190 observable: @@ -55,7 +74,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27199.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity_cve_2024_27199.log sourcetype: suricata source: suricata diff --git a/detections/web/jetbrains_teamcity_rce_attempt.yml b/detections/web/jetbrains_teamcity_rce_attempt.yml index 63148a7035..abca1f2fc1 100644 --- a/detections/web/jetbrains_teamcity_rce_attempt.yml +++ b/detections/web/jetbrains_teamcity_rce_attempt.yml @@ -1,21 +1,29 @@ name: JetBrains TeamCity RCE Attempt id: 89a58e5f-1365-4793-b45c-770abbb32b6c -version: 1 -date: '2023-10-01' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: 'The following analytic is designed to detect attempts to exploit the CVE-2023-42793 vulnerability in TeamCity On-Premises. It focuses on identifying suspicious POST requests to /app/rest/users/id:1/tokens/RPC2, which is the initial point of exploitation. This could indicate an unauthenticated attacker trying to gain administrative access through Remote Code Execution (RCE).' -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/app/rest/users/id:1/tokens/RPC2*") Web.status=200 Web.http_method=POST - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: 'The following analytic detects attempts to exploit the CVE-2023-42793 + vulnerability in JetBrains TeamCity On-Premises. It identifies suspicious POST requests + to /app/rest/users/id:1/tokens/RPC2, leveraging the Web datamodel to monitor specific + URL patterns and HTTP methods. This activity is significant as it may indicate an + unauthenticated attacker attempting to gain administrative access via Remote Code + Execution (RCE). If confirmed malicious, this could allow the attacker to execute + arbitrary code, potentially compromising the entire TeamCity environment and leading + to further unauthorized access and data breaches.' +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/app/rest/users/id:1/tokens/RPC2*") Web.status=200 Web.http_method=POST + by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, + Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `jetbrains_teamcity_rce_attempt_filter`' -how_to_implement: The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source. -known_false_positives: If TeamCity is not in use, this analytic will not return results. Monitor and tune for your environment. +how_to_implement: The following analytic requires the Web datamodel. Ensure data source + is mapped correctly or modify and tune for your data source. +known_false_positives: If TeamCity is not in use, this analytic will not return results. + Monitor and tune for your environment. references: - https://blog.jetbrains.com/teamcity/2023/09/critical-security-issue-affecting-teamcity-on-premises-update-to-2023-05-4-now/ - https://www.sonarsource.com/blog/teamcity-vulnerability/ @@ -32,7 +40,8 @@ tags: atomic_guid: [] confidence: 90 impact: 90 - message: Potential JetBrains TeamCity RCE Attempt detected against URL $url$ on $dest$. + message: Potential JetBrains TeamCity RCE Attempt detected against URL $url$ on + $dest$. mitre_attack_id: - T1190 observable: @@ -65,6 +74,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/jetbrains/teamcity.log source: suricata sourcetype: suricata diff --git a/detections/web/juniper_networks_remote_code_execution_exploit_detection.yml b/detections/web/juniper_networks_remote_code_execution_exploit_detection.yml index 8108ff7dc8..2fc4c95b69 100644 --- a/detections/web/juniper_networks_remote_code_execution_exploit_detection.yml +++ b/detections/web/juniper_networks_remote_code_execution_exploit_detection.yml @@ -1,21 +1,34 @@ name: Juniper Networks Remote Code Execution Exploit Detection id: 6cc4cc3d-b10a-4fac-be1e-55d384fc690e -version: 1 -date: '2023-08-29' +version: 2 +date: '2024-05-14' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic detects the exploitation of a remote code execution vulnerability in Juniper Networks devices. The vulnerability involves multiple steps, including uploading a malicious PHP file and an INI file to the target server, and then executing the PHP code by manipulating the PHP configuration via the uploaded INI file. The analytic specifically looks for requests to /webauth_operation.php?PHPRC=*, which are used to upload the files and execute the code, respectively. This behavior is worth identifying for a SOC because it indicates that an attacker is attempting to exploit the vulnerability to gain unauthorized access to the device and execute arbitrary code. If a true positive is found, it suggests that an attacker has successfully exploited the vulnerability and may have gained control over the device, leading to data theft, network compromise, or other damaging outcomes. Upon triage, review the request parameters and the response to determine if the exploitation was successful. Capture and inspect any relevant network traffic and server logs to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("*/webauth_operation.php?PHPRC=*") Web.status=200 - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `juniper_networks_remote_code_execution_exploit_detection_filter`' -how_to_implement: To implement this search, ensure that the Web data model is populated. The search is activated when the Web data model is accelerated. Network products, such as Suricata or Palo Alto, need to be mapped to the Web data model. Adjust the mapping as necessary to suit your specific products. -known_false_positives: Be aware of potential false positives - legitimate uses of the /webauth_operation.php endpoint may cause benign activities to be flagged.The URL in the analytic is specific to a successful attempt to exploit the vulnerability. Review contents of the HTTP body to determine if the request is malicious. If the request is benign, add the URL to the whitelist or continue to monitor. +description: The following analytic detects attempts to exploit a remote code execution + vulnerability in Juniper Networks devices. It identifies requests to /webauth_operation.php?PHPRC=*, + which are indicative of uploading and executing malicious PHP files. This detection + leverages the Web data model, focusing on specific URL patterns and HTTP status + codes. This activity is significant because it signals an attempt to gain unauthorized + access and execute arbitrary code on the device. If confirmed malicious, the attacker + could gain control over the device, leading to data theft, network compromise, or + other severe consequences. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/webauth_operation.php?PHPRC=*") Web.status=200 by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `juniper_networks_remote_code_execution_exploit_detection_filter`' +how_to_implement: To implement this search, ensure that the Web data model is populated. + The search is activated when the Web data model is accelerated. Network products, + such as Suricata or Palo Alto, need to be mapped to the Web data model. Adjust the + mapping as necessary to suit your specific products. +known_false_positives: Be aware of potential false positives - legitimate uses of + the /webauth_operation.php endpoint may cause benign activities to be flagged.The + URL in the analytic is specific to a successful attempt to exploit the vulnerability. + Review contents of the HTTP body to determine if the request is malicious. If the + request is benign, add the URL to the whitelist or continue to monitor. references: - https://supportportal.juniper.net/s/article/2023-08-Out-of-Cycle-Security-Bulletin-Junos-OS-SRX-Series-and-EX-Series-Multiple-vulnerabilities-in-J-Web-can-be-combined-to-allow-a-preAuth-Remote-Code-Execution?language=en_US - https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2023/CVE-2023-36844.yaml @@ -35,7 +48,9 @@ tags: atomic_guid: [] confidence: 80 impact: 90 - message: 'This analytic has identified a potential exploitation of a remote code execution vulnerability in Juniper Networks devices on $dest$ on the URL $url$ used for the exploit.' + message: 'This analytic has identified a potential exploitation of a remote code + execution vulnerability in Juniper Networks devices on $dest$ on the URL $url$ + used for the exploit.' observable: - name: dest type: Hostname @@ -67,6 +82,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/juniper/suricata_junos_cvemegazord.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/juniper/suricata_junos_cvemegazord.log source: suricata sourcetype: suricata diff --git a/detections/web/log4shell_jndi_payload_injection_attempt.yml b/detections/web/log4shell_jndi_payload_injection_attempt.yml index 9357b24330..fa9fb75dbe 100644 --- a/detections/web/log4shell_jndi_payload_injection_attempt.yml +++ b/detections/web/log4shell_jndi_payload_injection_attempt.yml @@ -1,28 +1,19 @@ name: Log4Shell JNDI Payload Injection Attempt id: c184f12e-5c90-11ec-bf1f-497c9a704a72 -version: 1 -date: '2021-12-13' +version: 2 +date: '2024-05-25' author: Jose Hernandez status: production type: Anomaly -description: CVE-2021-44228 Log4Shell payloads can be injected via various methods, - but on of the most common vectors injection is via Web calls. Many of the vulnerable - java web applications that are using log4j have a web component to them are specially - targets of this injection, specifically projects like Apache Struts, Flink, Druid, - and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, - its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against - vulnerable web applications the invocation can be seen in various part of web logs. - Specifically it has been successfully exploited via headers like X-Forwarded-For, - User-Agent, Referer, and X-Api-Version. In this detection we first limit the scope - of our search to the Web Datamodel and use the `| from datamodel` function to benefit - from schema accelerated searching capabilities, mainly because the second part of - the detection is pretty heavy, it runs a regex across all _raw events that looks - for `${jndi:ldap://` pattern across all potential web fields available to the raw - data, like http headers for example. If you see results for this detection, it means - that there was a attempt at a injection, which could be a reconnaissance activity - or a valid expliotation attempt, but this does not exactly mean that the host was - indeed successfully exploited. -data_source: +description: The following analytic identifies attempts to inject Log4Shell JNDI payloads + via web calls. It leverages the Web datamodel and uses regex to detect patterns + like `${jndi:ldap://` in raw web event data, including HTTP headers. This activity + is significant because it targets vulnerabilities in Java web applications using + Log4j, such as Apache Struts and Solr. If confirmed malicious, this could allow + attackers to execute arbitrary code, potentially leading to full system compromise. + Immediate investigation is required to determine if the attempt was successful and + to mitigate any potential exploitation. +data_source: - Nginx Access search: '| from datamodel Web.Web | regex _raw="[jJnNdDiI]{4}(\:|\%3A|\/|\%2F)\w+(\:\/\/|\%3A\%2F\%2F)(\$\{.*?\}(\.)?)?" | fillnull | stats count by action, category, dest, dest_port, http_content_type, @@ -80,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_proxy_logs/log4j_proxy_logs.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_proxy_logs/log4j_proxy_logs.log source: nginx sourcetype: nginx:plus:kv diff --git a/detections/web/log4shell_jndi_payload_injection_with_outbound_connection.yml b/detections/web/log4shell_jndi_payload_injection_with_outbound_connection.yml index 1da495900c..a67f0cc60f 100644 --- a/detections/web/log4shell_jndi_payload_injection_with_outbound_connection.yml +++ b/detections/web/log4shell_jndi_payload_injection_with_outbound_connection.yml @@ -1,21 +1,19 @@ name: Log4Shell JNDI Payload Injection with Outbound Connection id: 69afee44-5c91-11ec-bf1f-497c9a704a72 -version: 1 -date: '2021-12-13' +version: 2 +date: '2024-05-16' author: Jose Hernandez status: production type: Anomaly -description: CVE-2021-44228 Log4Shell payloads can be injected via various methods, - but on of the most common vectors injection is via Web calls. Many of the vulnerable - java web applications that are using log4j have a web component to them are specially - targets of this injection, specifically projects like Apache Struts, Flink, Druid, - and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, - its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against - vulnerable web applications the invocation can be seen in various part of web logs. - Specifically it has been successfully exploited via headers like X-Forwarded-For, - User-Agent, Referer, and X-Api-Version. In this detection we match the invocation - function with a network connection to a malicious ip address. -data_source: +description: The following analytic detects Log4Shell JNDI payload injections via + outbound connections. It identifies suspicious LDAP lookup functions in web logs, + such as `${jndi:ldap://PAYLOAD_INJECTED}`, and correlates them with network traffic + to known malicious IP addresses. This detection leverages the Web and Network_Traffic + data models in Splunk. Monitoring this activity is crucial as it targets vulnerabilities + in Java web applications using log4j, potentially leading to remote code execution. + If confirmed malicious, attackers could gain unauthorized access, execute arbitrary + code, and compromise sensitive data within the affected environment. +data_source: - Splunk Stream IP search: '| from datamodel Web.Web | rex field=_raw max_match=0 "[jJnNdDiI]{4}(\:|\%3A|\/|\%2F)(?\w+)(\:\/\/|\%3A\%2F\%2F)(\$\{.*?\}(\.)?)?(?[a-zA-Z0-9\.\-\_\$]+)" | join affected_host type=inner [| tstats `security_content_summariesonly` count @@ -75,9 +73,11 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_proxy_logs/log4j_proxy_logs.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_proxy_logs/log4j_proxy_logs.log source: nginx sourcetype: nginx:plus:kv - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_network_logs/log4j_network_logs.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/log4j_network_logs/log4j_network_logs.log source: stream:Splunk_IP sourcetype: stream:ip diff --git a/detections/web/microsoft_sharepoint_server_elevation_of_privilege.yml b/detections/web/microsoft_sharepoint_server_elevation_of_privilege.yml index 1972a83e54..fe3ef716bc 100644 --- a/detections/web/microsoft_sharepoint_server_elevation_of_privilege.yml +++ b/detections/web/microsoft_sharepoint_server_elevation_of_privilege.yml @@ -1,22 +1,30 @@ name: Microsoft SharePoint Server Elevation of Privilege id: fcf4bd3f-a79f-4b7a-83bf-2692d60b859d -version: 1 -date: '2023-09-27' +version: 2 +date: '2024-05-19' author: Michael Haag, Gowthamaraj Rajendran, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic detects potential exploitation attempts against Microsoft SharePoint Server vulnerability CVE-2023-29357. This vulnerability pertains to an elevation of privilege due to improper handling of authentication tokens. By monitoring for suspicious activities related to SharePoint Server, the analytic identifies attempts to exploit this vulnerability. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the SharePoint environment, potentially leading to data theft or other malicious activities. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/_api/web/siteusers*","/_api/web/currentuser*") Web.status=200 Web.http_method=GET - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `microsoft_sharepoint_server_elevation_of_privilege_filter`' -how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Microsoft SharePoint. -known_false_positives: False positives may occur if there are legitimate activities that mimic the exploitation pattern. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. +description: The following analytic detects potential exploitation attempts against + Microsoft SharePoint Server vulnerability CVE-2023-29357. It leverages the Web datamodel + to monitor for specific API calls and HTTP methods indicative of privilege escalation + attempts. This activity is significant as it may indicate an attacker is trying + to gain unauthorized privileged access to the SharePoint environment. If confirmed + malicious, the impact could include unauthorized access to sensitive data, potential + data theft, and further compromise of the SharePoint server, leading to a broader + security breach. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/_api/web/siteusers*","/_api/web/currentuser*") Web.status=200 + Web.http_method=GET by Web.http_user_agent, Web.status Web.http_method, Web.url, + Web.url_length, Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `microsoft_sharepoint_server_elevation_of_privilege_filter`' +how_to_implement: This detection requires the Web datamodel to be populated from a + supported Technology Add-On like Splunk for Microsoft SharePoint. +known_false_positives: False positives may occur if there are legitimate activities + that mimic the exploitation pattern. It's recommended to review the context of the + alerts and adjust the analytic parameters to better fit the specific environment. references: - https://socradar.io/microsoft-sharepoint-server-elevation-of-privilege-vulnerability-exploit-cve-2023-29357/ - https://github.com/LuemmelSec/CVE-2023-29357/blob/main/CVE-2023-29357/Program.cs @@ -29,7 +37,7 @@ tags: atomic_guid: [] confidence: 50 impact: 90 - message: Possible exploitation of CVE-2023-29357 against $dest$ from $src$. + message: Possible exploitation of CVE-2023-29357 against $dest$ from $src$. mitre_attack_id: - T1068 observable: @@ -60,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/sharepoint/sharepointeop.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/sharepoint/sharepointeop.log source: suricata - sourcetype: suricata \ No newline at end of file + sourcetype: suricata diff --git a/detections/web/nginx_connectwise_screenconnect_authentication_bypass.yml b/detections/web/nginx_connectwise_screenconnect_authentication_bypass.yml index 1fb504ca71..3dbacac6c5 100644 --- a/detections/web/nginx_connectwise_screenconnect_authentication_bypass.yml +++ b/detections/web/nginx_connectwise_screenconnect_authentication_bypass.yml @@ -1,19 +1,34 @@ name: Nginx ConnectWise ScreenConnect Authentication Bypass id: b3f7a803-e802-448b-8eb2-e796b223bccc -version: 1 -date: '2024-02-23' +version: 2 +date: '2024-05-16' author: Michael Haag, Splunk -data_source: +data_source: - Nginx Access type: TTP status: production -description: This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. -search: '`nginx_access_logs` uri_path IN ("*/SetupWizard.aspx/*","*/SetupWizard/") status=200 http_method=POST | stats count min(_time) as firstTime max(_time) as lastTime by src, dest, http_user_agent, url, uri_path, status, http_method, sourcetype, source - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic detects attempts to exploit the ConnectWise ScreenConnect + CVE-2024-1709 vulnerability, which allows attackers to bypass authentication via + alternate paths or channels. It leverages Nginx access logs to identify web requests + to the SetupWizard.aspx page, indicating potential exploitation. This activity is + significant as it can lead to unauthorized administrative access and remote code + execution. If confirmed malicious, attackers could create administrative users and + gain full control over the affected ScreenConnect instance, posing severe security + risks. Immediate remediation by updating to version 23.9.8 or above is recommended. +search: '`nginx_access_logs` uri_path IN ("*/SetupWizard.aspx/*","*/SetupWizard/") + status=200 http_method=POST | stats count min(_time) as firstTime max(_time) as + lastTime by src, dest, http_user_agent, url, uri_path, status, http_method, sourcetype, + source | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `nginx_connectwise_screenconnect_authentication_bypass_filter`' -how_to_implement: To implement this analytic, ensure proper logging is occurring with Nginx, access.log and error.log, and that these logs are being ingested into Splunk. STRT utilizes this nginx.conf https://gist.github.com/MHaggis/26f59108b04da8f1d870c9cc3a3c8eec to properly log as much data with Nginx. -known_false_positives: False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise. +how_to_implement: To implement this analytic, ensure proper logging is occurring with + Nginx, access.log and error.log, and that these logs are being ingested into Splunk. + STRT utilizes this nginx.conf https://gist.github.com/MHaggis/26f59108b04da8f1d870c9cc3a3c8eec + to properly log as much data with Nginx. +known_false_positives: False positives are not expected, as the detection is based + on the presence of web requests to the SetupWizard.aspx page, which is not a common + page to be accessed by legitimate users. Note that the analytic is limited to HTTP + POST and a status of 200 to reduce false positives. Modify the query as needed to + reduce false positives or hunt for additional indicators of compromise. references: - https://docs.splunk.com/Documentation/AddOns/released/NGINX/Sourcetypes - https://gist.github.com/MHaggis/26f59108b04da8f1d870c9cc3a3c8eec @@ -26,7 +41,8 @@ tags: asset_type: Web Proxy confidence: 100 impact: 100 - message: An authentication bypass attempt against ScreenConnect has been detected on $dest$. + message: An authentication bypass attempt against ScreenConnect has been detected + on $dest$. mitre_attack_id: - T1190 observable: @@ -53,10 +69,11 @@ tags: security_domain: network cve: - CVE-2024-1708 - - CVE-2024-1709 + - CVE-2024-1709 tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/nginx_screenconnect.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/screenconnect/nginx_screenconnect.log sourcetype: nginx:plus:kv source: nginx:plus:kv diff --git a/detections/web/papercut_ng_remote_web_access_attempt.yml b/detections/web/papercut_ng_remote_web_access_attempt.yml index acbc6c76cc..1fc500207c 100644 --- a/detections/web/papercut_ng_remote_web_access_attempt.yml +++ b/detections/web/papercut_ng_remote_web_access_attempt.yml @@ -1,25 +1,37 @@ name: PaperCut NG Remote Web Access Attempt id: 9fcb214a-dc42-4ce7-a650-f1d2cab16a6a -version: 1 -date: '2023-05-15' +version: 2 +date: '2024-05-23' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: The following analytic is designed to detect potential exploitation attempts on publicly accessible PaperCut NG servers. It identifies connections from public IP addresses to the server and specifically monitors for URI paths commonly found in proof-of-concept (POC) scripts for exploiting PaperCut NG vulnerabilities. These URI paths have been observed in both Metasploit modules and standalone scripts used for attacking PaperCut NG servers. - When a public IP address is detected accessing one or more of these suspicious URI paths, an alert may be generated to notify the security team of the potential threat. The team can then investigate the source IP address, the targeted PaperCut NG server, and any other relevant information to determine the nature of the activity and take appropriate actions to mitigate the risk. -search: '| tstats count from datamodel=Web where Web.url IN ("/app?service=page/SetupCompleted", "/app", "/app?service=page/PrinterList", "/app?service=direct/1/PrinterList/selectPrinter&sp=*", "/app?service=direct/1/PrinterDetails/printerOptionsTab.tab") NOT (src IN ("10.*.*.*","172.16.*.*", "192.168.*.*", "169.254.*.*", "127.*.*.*", "fc00::*", "fd00::*", "fe80::*")) by Web.http_user_agent Web.http_method, Web.url,Web.url_length Web.src, Web.dest Web.dest_port sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` +description: The following analytic detects potential exploitation attempts on publicly + accessible PaperCut NG servers. It identifies connections from public IP addresses + to the server, specifically monitoring URI paths commonly used in proof-of-concept + scripts for exploiting PaperCut NG vulnerabilities. This detection leverages web + traffic data from the `Web` datamodel, focusing on specific URI paths and excluding + internal IP ranges. This activity is significant as it may indicate an attempt to + exploit known vulnerabilities in PaperCut NG, potentially leading to unauthorized + access or control of the server. If confirmed malicious, attackers could gain administrative + access, leading to data breaches or further network compromise. +search: '| tstats count from datamodel=Web where Web.url IN ("/app?service=page/SetupCompleted", + "/app", "/app?service=page/PrinterList", "/app?service=direct/1/PrinterList/selectPrinter&sp=*", + "/app?service=direct/1/PrinterDetails/printerOptionsTab.tab") NOT (src IN ("10.*.*.*","172.16.*.*", + "192.168.*.*", "169.254.*.*", "127.*.*.*", "fc00::*", "fd00::*", "fe80::*")) by + Web.http_user_agent Web.http_method, Web.url,Web.url_length Web.src, Web.dest Web.dest_port + sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `papercut_ng_remote_web_access_attempt_filter`' how_to_implement: To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. known_false_positives: False positives may be present, filter as needed. references: - - https://www.cisa.gov/news-events/alerts/2023/05/11/cisa-and-fbi-release-joint-advisory-response-active-exploitation-papercut-vulnerability - - https://www.papercut.com/kb/Main/PO-1216-and-PO-1219 - - https://www.horizon3.ai/papercut-cve-2023-27350-deep-dive-and-indicators-of-compromise/ - - https://www.bleepingcomputer.com/news/security/hackers-actively-exploit-critical-rce-bug-in-papercut-servers/ - - https://www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software +- https://www.cisa.gov/news-events/alerts/2023/05/11/cisa-and-fbi-release-joint-advisory-response-active-exploitation-papercut-vulnerability +- https://www.papercut.com/kb/Main/PO-1216-and-PO-1219 +- https://www.horizon3.ai/papercut-cve-2023-27350-deep-dive-and-indicators-of-compromise/ +- https://www.bleepingcomputer.com/news/security/hackers-actively-exploit-critical-rce-bug-in-papercut-servers/ +- https://www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software tags: analytic_story: - PaperCut MF NG Vulnerability @@ -54,6 +66,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/papercutng-suricata.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/papercut/papercutng-suricata.log source: suricata sourcetype: suricata diff --git a/detections/web/proxyshell_proxynotshell_behavior_detected.yml b/detections/web/proxyshell_proxynotshell_behavior_detected.yml index e62809b2a9..a7a9c09997 100644 --- a/detections/web/proxyshell_proxynotshell_behavior_detected.yml +++ b/detections/web/proxyshell_proxynotshell_behavior_detected.yml @@ -1,20 +1,19 @@ name: ProxyShell ProxyNotShell Behavior Detected id: c32fab32-6aaf-492d-bfaf-acbed8e50cdf -version: 1 -date: '2023-07-10' +version: 2 +date: '2024-05-21' author: Michael Haag, Splunk status: production type: Correlation -description: The following correlation will identify activity related to Windows Exchange - being actively exploited by adversaries related to ProxyShell or ProxyNotShell. - In addition, the analytic correlates post-exploitation Cobalt Strike analytic story. - Common post-exploitation behavior has been seen in the wild includes adversaries - running nltest, Cobalt Strike, Mimikatz and adding a new user. The correlation specifically - looks for 5 distinct analyticstories to trigger. Modify or tune as needed for your - organization. 5 analytics is an arbitrary number but was chosen to reduce the amount - of noise but also require the 2 analytic stories or a ProxyShell and CobaltStrike - to fire. Adversaries will exploit the vulnerable Exchange server, abuse SSRF, drop - a web shell, utilize the PowerShell Exchange modules and begin post-exploitation. +description: The following analytic identifies potential exploitation of Windows Exchange + servers via ProxyShell or ProxyNotShell vulnerabilities, followed by post-exploitation + activities such as running nltest, Cobalt Strike, Mimikatz, and adding new users. + It leverages data from multiple analytic stories, requiring at least five distinct + sources to trigger, thus reducing noise. This activity is significant as it indicates + a high likelihood of an active compromise, potentially leading to unauthorized access, + privilege escalation, and persistent threats within the environment. If confirmed + malicious, attackers could gain control over the Exchange server, exfiltrate data, + and maintain long-term access. data_source: [] search: '| 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) @@ -71,7 +70,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/proxyshell/proxyshell-risk.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/proxyshell/proxyshell-risk.log source: proxyshell sourcetype: stash update_timestamp: true diff --git a/detections/web/spring4shell_payload_url_request.yml b/detections/web/spring4shell_payload_url_request.yml index a19a9c0b3b..1355219306 100644 --- a/detections/web/spring4shell_payload_url_request.yml +++ b/detections/web/spring4shell_payload_url_request.yml @@ -1,16 +1,19 @@ name: Spring4Shell Payload URL Request id: 9d44d649-7d67-4559-95c1-8022ff49420b -version: 1 -date: '2022-07-12' +version: 2 +date: '2024-05-26' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic is static indicators related to CVE-2022-22963, - Spring4Shell. The 3 indicators provide an amount of fidelity that source IP is attemping - to exploit a web shell on the destination. The filename and cmd are arbitrary in - this exploitation. Java will write a JSP to disk and a process will spawn from Java - based on the cmd passed. This is indicative of typical web shell activity. -data_source: +description: The following analytic detects attempts to exploit the Spring4Shell vulnerability + (CVE-2022-22963) by identifying specific URL patterns associated with web shell + payloads. It leverages web traffic data, focusing on HTTP GET requests with URLs + containing indicators like "tomcatwar.jsp," "poc.jsp," and "shell.jsp." This activity + is significant as it suggests an attacker is trying to deploy a web shell, which + can lead to remote code execution. If confirmed malicious, this could allow the + attacker to gain persistent access, execute arbitrary commands, and potentially + escalate privileges within the compromised environment. +data_source: - Nginx Access search: '| tstats count from datamodel=Web where Web.http_method IN ("GET") Web.url IN ("*tomcatwar.jsp*","*poc.jsp*","*shell.jsp*") by Web.http_user_agent Web.http_method, @@ -64,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/spring4shell_nginx.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/spring4shell_nginx.log source: /var/log/nginx/access.log sourcetype: nginx:plus:kv diff --git a/detections/web/sql_injection_with_long_urls.yml b/detections/web/sql_injection_with_long_urls.yml index a4d7f4738a..768940b1f0 100644 --- a/detections/web/sql_injection_with_long_urls.yml +++ b/detections/web/sql_injection_with_long_urls.yml @@ -1,11 +1,18 @@ name: SQL Injection with Long URLs id: e0aad4cf-0790-423b-8328-7564d0d938f9 -version: 3 -date: '2022-03-28' +version: 4 +date: '2024-05-12' author: Bhavin Patel, Splunk status: experimental type: TTP -description: "The following analytic detects long URLs that contain multiple SQL commands. A proactive approach helps to detect and respond to potential threats earlier, mitigating the risks associated with SQL injection attacks. This detection is made by a Splunk query that searches for web traffic data where the destination category is a web server and the URL length is greater than 1024 characters or the HTTP user agent length is greater than 200 characters. This detection is important because it suggests that an attacker is attempting to exploit a web application through SQL injection. SQL injection is a common technique used by attackers to exploit vulnerabilities in web applications and gain unauthorized access to databases. Attackers can insert malicious SQL commands into a URL to manipulate the application's database and retrieve sensitive information or modify data. The impact of a successful SQL injection attack can be severe, potentially leading to data breaches, unauthorized access, and even complete compromise of the affected system. False positives might occur since the legitimate use of web applications or specific URLs in your environment can trigger the detection. Therefore, you must review and validate any alerts generated by this analytic before taking any action. Next steps include reviewing the source and destination of the web traffic, as well as the specific URL and HTTP user agent. Additionally, capture and analyze any relevant on-disk artifacts and review concurrent processes to determine the source of the attack." +description: "The following analytic detects long URLs containing multiple SQL commands, + indicating a potential SQL injection attack. This detection leverages web traffic + data, specifically targeting web server destinations with URLs longer than 1024 + characters or HTTP user agents longer than 200 characters. SQL injection is significant + as it allows attackers to manipulate a web application's database, potentially leading + to unauthorized data access or modification. If confirmed malicious, this activity + could result in data breaches, unauthorized access, and complete system compromise. + Immediate investigation and validation of alerts are crucial to mitigate these risks." data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Web where Web.dest_category=web_server AND (Web.url_length > 1024 OR Web.http_user_agent_length diff --git a/detections/web/supernova_webshell.yml b/detections/web/supernova_webshell.yml index 1080be1b61..df3acd20f3 100644 --- a/detections/web/supernova_webshell.yml +++ b/detections/web/supernova_webshell.yml @@ -1,12 +1,12 @@ name: Supernova Webshell id: 2ec08a09-9ff1-4dac-b59f-1efd57972ec1 -version: 1 -date: '2021-01-06' +version: 2 +date: '2024-05-26' author: John Stoner, Splunk status: experimental type: TTP description: |- - The following analytic detects the presence of the Supernova webshell, which was used in the SUNBURST attack. This webshell can be used by attackers to gain unauthorized access to a compromised system and run arbitrary code. This detection is made by a Splunk query that searches for specific patterns in web URLs, including "*logoimagehandler.ashx*codes*", "*logoimagehandler.ashx*clazz*", "*logoimagehandler.ashx*method*", and "*logoimagehandler.ashx*args*". These patterns are commonly used by the Supernova webshell to communicate with its command and control server. This detection is important because it indicates a potential compromise and unauthorized access to the system to run arbitrary code, which can lead to data theft, ransomware, or other damaging outcomes. False positives might occur since the patterns used by the webshell can also be present in legitimate web traffic. In such cases, tune the search to the specific environment and monitor it closely for any suspicious activity. Next steps include reviewing the web URLs and inspecting any relevant on-disk artifacts. Additionally, review concurrent processes and network connections to identify the source of the attack. + The following analytic detects the presence of the Supernova webshell, used in the SUNBURST attack, by identifying specific patterns in web URLs. The detection leverages Splunk to search for URLs containing "*logoimagehandler.ashx*codes*", "*logoimagehandler.ashx*clazz*", "*logoimagehandler.ashx*method*", and "*logoimagehandler.ashx*args*". This activity is significant as it indicates potential unauthorized access and arbitrary code execution on a compromised system. If confirmed malicious, this could lead to data theft, ransomware deployment, or other severe outcomes. Immediate steps include reviewing the web URLs, inspecting on-disk artifacts, and analyzing concurrent processes and network connections. data_source: [] search: '| tstats `security_content_summariesonly` count from datamodel=Web.Web where web.url=*logoimagehandler.ashx*codes* OR Web.url=*logoimagehandler.ashx*clazz* OR diff --git a/detections/web/vmware_aria_operations_exploit_attempt.yml b/detections/web/vmware_aria_operations_exploit_attempt.yml index e10cf0e98e..a873108626 100644 --- a/detections/web/vmware_aria_operations_exploit_attempt.yml +++ b/detections/web/vmware_aria_operations_exploit_attempt.yml @@ -1,29 +1,30 @@ name: VMWare Aria Operations Exploit Attempt id: d5d865e4-03e6-43da-98f4-28a4f42d4df7 -version: 1 -date: '2023-06-21' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Palo Alto Network Threat -description: The following analytic is designed to detect potential exploitation attempts against VMWare vRealize Network Insight that align with the characteristics of CVE-2023-20887. This specific vulnerability is a critical security flaw that, if exploited, could allow an attacker to execute arbitrary code on the affected system. - - The analytic operates by monitoring web traffic, specifically HTTP POST requests, directed towards a specific URL endpoint ("/saas./resttosaasservlet"). This endpoint is known to be vulnerable and is a common target for attackers exploiting this vulnerability. - - The behavior this analytic detects is the sending of HTTP POST requests to the vulnerable endpoint. This is a significant indicator of an attempted exploit as it is the primary method used to trigger the vulnerability. The analytic detects this behavior by analyzing web traffic data and identifying HTTP POST requests directed at the vulnerable endpoint. - - Identifying this behavior is crucial for a Security Operations Center (SOC) as it can indicate an active attempt to exploit a known vulnerability within the network. If the identified behavior is a true positive, it suggests an attacker is attempting to exploit the CVE-2023-20887 vulnerability in VMWare vRealize Network Insight. The impact of such an attack could be severe, potentially allowing the attacker to execute arbitrary code on the affected system, leading to unauthorized access, data theft, or further propagation within the network. -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("*/saas./resttosaasservlet*") Web.http_method=POST Web.status IN ("unknown", "200") - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: The following analytic detects potential exploitation attempts against + VMWare vRealize Network Insight, specifically targeting the CVE-2023-20887 vulnerability. + It monitors web traffic for HTTP POST requests directed at the vulnerable endpoint + "/saas./resttosaasservlet." This detection leverages web traffic data, focusing + on specific URL patterns and HTTP methods. Identifying this behavior is crucial + for a SOC as it indicates an active exploit attempt. If confirmed malicious, the + attacker could execute arbitrary code, leading to unauthorized access, data theft, + or further network compromise. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*/saas./resttosaasservlet*") Web.http_method=POST Web.status + IN ("unknown", "200") by Web.http_user_agent, Web.status Web.http_method, Web.url, + Web.url_length, Web.src, Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `vmware_aria_operations_exploit_attempt_filter`' how_to_implement: To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. Restrict to specific dest assets to reduce false positives. -known_false_positives: False positives will be present based on gateways in use, modify the status field as needed. +known_false_positives: False positives will be present based on gateways in use, modify + the status field as needed. references: - https://nvd.nist.gov/vuln/detail/CVE-2023-20887 - https://viz.greynoise.io/tag/vmware-aria-operations-for-networks-rce-attempt?days=30 @@ -38,7 +39,8 @@ tags: atomic_guid: [] confidence: 80 impact: 90 - message: An exploitation attempt has occurred against $dest$ from $src$ related to CVE-2023-20887 + message: An exploitation attempt has occurred against $dest$ from $src$ related + to CVE-2023-20887 mitre_attack_id: - T1133 - T1190 @@ -69,6 +71,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/vmware/vmware_aria.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/vmware/vmware_aria.log source: pan:threat sourcetype: pan:threat diff --git a/detections/web/vmware_workspace_one_freemarker_server_side_template_injection.yml b/detections/web/vmware_workspace_one_freemarker_server_side_template_injection.yml index 5e957a2d05..65d65d4321 100644 --- a/detections/web/vmware_workspace_one_freemarker_server_side_template_injection.yml +++ b/detections/web/vmware_workspace_one_freemarker_server_side_template_injection.yml @@ -1,17 +1,19 @@ name: VMware Workspace ONE Freemarker Server-side Template Injection id: 9e5726fe-8fde-460e-bd74-cddcf6c86113 -version: 1 -date: '2022-05-19' +version: 2 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: Anomaly -description: The following analytic identifies the server side template injection - related to CVE-2022-22954. Based on the scanning activity across the internet and - proof of concept code available the template injection occurs at catalog-portal/ui/oauth/verify?error=&deviceudid=. - Upon triage, review parallel processes and VMware logs. Following the deviceudid= - may be a command to be executed. Capture any file creates and review modified files - on disk. -data_source: +description: The following analytic detects server-side template injection attempts + related to CVE-2022-22954 in VMware Workspace ONE. It leverages web or proxy logs + to identify HTTP GET requests to the endpoint catalog-portal/ui/oauth/verify with + the freemarker.template.utility.Execute command. This activity is significant as + it indicates potential exploitation attempts that could lead to remote code execution. + If confirmed malicious, an attacker could execute arbitrary commands on the server, + leading to full system compromise, data exfiltration, or further lateral movement + within the network. +data_source: - Palo Alto Network Threat search: '| tstats count from datamodel=Web where Web.http_method IN ("GET") Web.url="*/catalog-portal/ui/oauth/verify?error=&deviceudid=*" AND Web.url="*freemarker.template.utility.Execute*" by Web.http_user_agent Web.http_method, @@ -63,7 +65,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/vmware/vmware_scanning_pan_threat.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/vmware/vmware_scanning_pan_threat.log source: pan:threat sourcetype: pan:threat update_timestamp: true diff --git a/detections/web/web_jsp_request_via_url.yml b/detections/web/web_jsp_request_via_url.yml index 09505d855f..1fce35b1a7 100644 --- a/detections/web/web_jsp_request_via_url.yml +++ b/detections/web/web_jsp_request_via_url.yml @@ -1,16 +1,19 @@ name: Web JSP Request via URL id: 2850c734-2d44-4431-8139-1a56f6f54c01 -version: 1 -date: '2022-04-05' +version: 2 +date: '2024-05-15' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the common URL requests used by a recent - CVE - CVE-2022-22965, or Spring4Shell, to access a webshell on the remote webserver. - The filename and cmd are arbitrary in this exploitation. Java will write a JSP to - disk and a process will spawn from Java based on the cmd passed. This is indicative - of typical web shell activity. -data_source: +description: The following analytic identifies URL requests associated with CVE-2022-22965 + (Spring4Shell) exploitation attempts, specifically targeting webshell access on + a remote webserver. It detects HTTP GET requests with URLs containing ".jsp?cmd=" + or "j&cmd=" patterns. This activity is significant as it indicates potential webshell + deployment, which can lead to unauthorized remote command execution. If confirmed + malicious, attackers could gain control over the webserver, execute arbitrary commands, + and potentially escalate privileges, leading to severe data breaches and system + compromise. +data_source: - Nginx Access search: '| tstats count from datamodel=Web where Web.http_method IN ("GET") Web.url IN ("*.jsp?cmd=*","*j&cmd=*") by Web.http_user_agent Web.http_method, Web.url,Web.url_length @@ -65,6 +68,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/spring4shell_nginx.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/spring4shell_nginx.log source: /var/log/nginx/access.log sourcetype: nginx:plus:kv diff --git a/detections/web/web_remote_shellservlet_access.yml b/detections/web/web_remote_shellservlet_access.yml index 6177f925fe..10353c2884 100644 --- a/detections/web/web_remote_shellservlet_access.yml +++ b/detections/web/web_remote_shellservlet_access.yml @@ -1,19 +1,30 @@ name: Web Remote ShellServlet Access id: c2a332c3-24a2-4e24-9455-0e80332e6746 -version: 2 -date: '2024-04-02' +version: 3 +date: '2024-05-19' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Nginx Access -description: This analytic identifies attempts to access the Remote ShellServlet on a web server, which is utilized to execute commands. Such activity is commonly linked with web shells and other forms of malicious behavior. It was specifically detected on a Confluence server in relation to CVE-2023-22518 and CVE-2023-22515. Activities preceding access to the shell servlet include the addition of a plugin to Confluence. Additionally, it is advisable to monitor for ShellServlet?act=3, ShellServlet, or obfuscated variations such as Sh3llServlet1. -search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*plugins/servlet/com.jsos.shell/*") Web.status=200 by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `web_remote_shellservlet_access_filter`' -how_to_implement: This analytic necessitates the collection of web data, which can be achieved through Splunk Stream or by utilizing the Splunk Add-on for Apache Web Server. No additional configuration is required for this analytic. -known_false_positives: False positives may occur depending on the web server's configuration. If the web server is intentionally configured to utilize the Remote ShellServlet, then the detections by this analytic would not be considered true positives. +description: The following analytic identifies attempts to access the Remote ShellServlet + on a web server, specifically targeting Confluence servers vulnerable to CVE-2023-22518 + and CVE-2023-22515. It leverages web data to detect URLs containing "*plugins/servlet/com.jsos.shell/*" + with a status code of 200. This activity is significant as it is commonly associated + with web shells and other malicious behaviors, potentially leading to unauthorized + command execution. If confirmed malicious, attackers could gain remote code execution + capabilities, compromising the server and potentially the entire network. +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("*plugins/servlet/com.jsos.shell/*") Web.status=200 by Web.http_user_agent, + Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype + | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `web_remote_shellservlet_access_filter`' +how_to_implement: This analytic necessitates the collection of web data, which can + be achieved through Splunk Stream or by utilizing the Splunk Add-on for Apache Web + Server. No additional configuration is required for this analytic. +known_false_positives: False positives may occur depending on the web server's configuration. + If the web server is intentionally configured to utilize the Remote ShellServlet, + then the detections by this analytic would not be considered true positives. references: - http://www.servletsuite.com/servlets/shell.htm tags: @@ -23,7 +34,8 @@ tags: atomic_guid: [] confidence: 90 impact: 90 - message: An attempt to access the Remote ShellServlet on a web server was detected. The source IP is $src$ and the destination hostname is $dest$. + message: An attempt to access the Remote ShellServlet on a web server was detected. + The source IP is $src$ and the destination hostname is $dest$. mitre_attack_id: - T1190 observable: @@ -53,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/nginx_shellservlet.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/confluence/nginx_shellservlet.log source: /var/log/nginx/access.log sourcetype: nginx:plus:kv diff --git a/detections/web/web_spring4shell_http_request_class_module.yml b/detections/web/web_spring4shell_http_request_class_module.yml index 6b7c4e4983..c0b3fb7032 100644 --- a/detections/web/web_spring4shell_http_request_class_module.yml +++ b/detections/web/web_spring4shell_http_request_class_module.yml @@ -1,15 +1,19 @@ name: Web Spring4Shell HTTP Request Class Module id: fcdfd69d-0ca3-4476-920e-9b633cb4593e -version: 1 -date: '2022-04-06' +version: 2 +date: '2024-05-28' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies the payload related to Spring4Shell, - CVE-2022-22965. This analytic uses Splunk Stream HTTP to view the http request body, - form data. STRT reviewed all the current proof of concept code and determined the - commonality with the payloads being passed used the same fields "class.module.classLoader.resources.context.parent.pipeline.first". -data_source: +description: The following analytic detects HTTP requests containing payloads related + to the Spring4Shell vulnerability (CVE-2022-22965). It leverages Splunk Stream HTTP + data to inspect the HTTP request body and form data for specific fields such as + "class.module.classLoader.resources.context.parent.pipeline.first". This activity + is significant as it indicates an attempt to exploit a critical vulnerability in + Spring Framework, potentially leading to remote code execution. If confirmed malicious, + this could allow attackers to gain unauthorized access, execute arbitrary code, + and compromise the affected system. +data_source: - Splunk Stream HTTP search: '`stream_http` http_method IN ("POST") | stats values(form_data) as http_request_body min(_time) as firstTime max(_time) as lastTime count by src dest http_method http_user_agent @@ -63,6 +67,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/http_request_body_streams.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/http_request_body_streams.log source: stream:http sourcetype: stream:http diff --git a/detections/web/web_spring_cloud_function_functionrouter.yml b/detections/web/web_spring_cloud_function_functionrouter.yml index e08aa4b4e6..f850adbf3b 100644 --- a/detections/web/web_spring_cloud_function_functionrouter.yml +++ b/detections/web/web_spring_cloud_function_functionrouter.yml @@ -1,18 +1,19 @@ name: Web Spring Cloud Function FunctionRouter id: 89dddbad-369a-4f8a-ace2-2439218735bc -version: 1 -date: '2022-04-05' +version: 2 +date: '2024-05-22' author: Michael Haag, Splunk status: production type: TTP -description: The following analytic identifies activity related to the web application - Spring Cloud Function that was recently idenfied as vulnerable. This is CVE-2022-22963. - Multiple proof of concept code was released. The URI that is hit includes `functionrouter`. - The specifics of the exploit include a status of 500. In this query we did not include - it, but for filtering you can add Web.status=500. The exploit data itself (based - on all the POCs) is located in the form_data field. This field will include all - class.modules being called. -data_source: +description: The following analytic identifies HTTP POST requests to the Spring Cloud + Function endpoint containing "functionRouter" in the URL. It leverages the Web data + model to detect these requests based on specific fields such as http_method, url, + and http_user_agent. This activity is significant because it targets CVE-2022-22963, + a known vulnerability in Spring Cloud Function, which has multiple proof-of-concept + exploits available. If confirmed malicious, this activity could allow attackers + to execute arbitrary code, potentially leading to unauthorized access, data exfiltration, + or further compromise of the affected system. +data_source: - Splunk Stream HTTP search: '| tstats count from datamodel=Web where Web.http_method IN ("POST") Web.url="*/functionRouter*" by Web.http_user_agent Web.http_method, Web.url,Web.url_length Web.src, Web.dest @@ -64,6 +65,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/all_functionrouter_http_streams.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/all_functionrouter_http_streams.log source: stream:http sourcetype: stream:http diff --git a/detections/web/windows_exchange_autodiscover_ssrf_abuse.yml b/detections/web/windows_exchange_autodiscover_ssrf_abuse.yml index 22f9862f3e..8ff6285ca5 100644 --- a/detections/web/windows_exchange_autodiscover_ssrf_abuse.yml +++ b/detections/web/windows_exchange_autodiscover_ssrf_abuse.yml @@ -1,20 +1,18 @@ name: Windows Exchange Autodiscover SSRF Abuse id: d436f9e7-0ee7-4a47-864b-6dea2c4e2752 -version: 1 -date: '2023-07-10' +version: 2 +date: '2024-05-16' author: Michael Haag, Nathaniel Stearns, Splunk status: production type: TTP -description: The following analytic utilizes the Web datamodel and identifies the - ProxyShell or ProxyNotShell abuse. This vulnerability is a Server Side Request Forgery - (SSRF) vulnerability, which is a web vulnerability that allows an adversary to exploit - vulnerable functionality to access server side or local network services by affectively - traversing the external firewall using vulnerable web functionality. This analytic - looks for the URI path and query of autodiscover, powershell and mapi along with - a POST occurring. It will tally a simple score and show the output of the events - that match. This analytic may be added to by simply creating a new eval statement - and modifying the hardcode digit for Score. -data_source: +description: The following analytic detects potential abuse of the ProxyShell or ProxyNotShell + vulnerabilities in Microsoft Exchange via Server Side Request Forgery (SSRF). It + leverages the Web datamodel to identify suspicious POST requests with specific URI + paths and queries related to autodiscover, powershell, and mapi. This activity is + significant as it may indicate an attempt to exploit Exchange server vulnerabilities + to access internal services or sensitive data. If confirmed malicious, this could + lead to unauthorized access, data exfiltration, or further compromise of the network. +data_source: - Windows IIS search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where (Web.status=200 OR Web.status=302 OR Web.status=401) @@ -79,7 +77,8 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/proxyshell/proxyshell.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/proxyshell/proxyshell.log source: ms:iis:splunk sourcetype: ms:iis:splunk update_timestamp: true diff --git a/detections/web/wordpress_bricks_builder_plugin_rce.yml b/detections/web/wordpress_bricks_builder_plugin_rce.yml index 6d55c5e9b8..8be952b7ad 100644 --- a/detections/web/wordpress_bricks_builder_plugin_rce.yml +++ b/detections/web/wordpress_bricks_builder_plugin_rce.yml @@ -1,33 +1,45 @@ name: WordPress Bricks Builder plugin RCE id: 56a8771a-3fda-4959-b81d-2f266e2f679f -version: 1 -date: '2024-02-22' +version: 2 +date: '2024-05-17' author: Michael Haag, Splunk -data_source: +data_source: - Nginx Access type: TTP status: production -description: The following analytic identifies potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability. The search is focused on the URL path "/wp-json/bricks/v1/render_element" with a status code of 200 and a POST method. It has been addressed by the theme developers in version 1.9.6.1 released on February 13, 2024. The vulnerability is tracked as CVE-2024-25600. The POC exploit is simple enough and will spawn commands on the target server. The exploit is actively being used in the wild. -search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("*/wp-json/bricks/v1/render_element") Web.status=200 Web.http_method=POST by Web.src, Web.dest, Web.http_user_agent, Web.url, Web.uri_path, Web.status, Web.http_method, sourcetype, source - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | `wordpress_bricks_builder_plugin_rce_filter`' -how_to_implement: The search is based on data in the Web datamodel and was modeled from NGINX logs. Ensure that the Web datamodel is accelerated and that the data source for the Web datamodel is properly configured. If using other web sources, modify they query, or review the data, as needed. -known_false_positives: False positives may be possible, however we restricted it to HTTP Status 200 and POST requests, based on the POC. Upon investigation review the POST body for the actual payload - or command - being executed. +description: The following analytic identifies potential exploitation of the WordPress + Bricks Builder plugin RCE vulnerability. It detects HTTP POST requests to the URL + path "/wp-json/bricks/v1/render_element" with a status code of 200, leveraging the + Web datamodel. This activity is significant as it indicates an attempt to exploit + CVE-2024-25600, a known vulnerability that allows remote code execution. If confirmed + malicious, an attacker could execute arbitrary commands on the target server, leading + to potential full system compromise and unauthorized access to sensitive data. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Web where Web.url IN ("*/wp-json/bricks/v1/render_element") + Web.status=200 Web.http_method=POST by Web.src, Web.dest, Web.http_user_agent, Web.url, + Web.uri_path, Web.status, Web.http_method, sourcetype, source | `drop_dm_object_name("Web")` + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `wordpress_bricks_builder_plugin_rce_filter`' +how_to_implement: The search is based on data in the Web datamodel and was modeled + from NGINX logs. Ensure that the Web datamodel is accelerated and that the data + source for the Web datamodel is properly configured. If using other web sources, + modify they query, or review the data, as needed. +known_false_positives: False positives may be possible, however we restricted it to + HTTP Status 200 and POST requests, based on the POC. Upon investigation review the + POST body for the actual payload - or command - being executed. references: - - https://attack.mitre.org/techniques/T1190 - - https://github.com/Tornad0007/CVE-2024-25600-Bricks-Builder-plugin-for-WordPress/blob/main/exploit.py - - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25600 - - https://op-c.net/blog/cve-2024-25600-wordpresss-bricks-builder-rce-flaw-under-active-exploitation/ - - https://thehackernews.com/2024/02/wordpress-bricks-theme-under-active.html +- https://attack.mitre.org/techniques/T1190 +- https://github.com/Tornad0007/CVE-2024-25600-Bricks-Builder-plugin-for-WordPress/blob/main/exploit.py +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25600 +- https://op-c.net/blog/cve-2024-25600-wordpresss-bricks-builder-rce-flaw-under-active-exploitation/ +- https://thehackernews.com/2024/02/wordpress-bricks-theme-under-active.html tags: analytic_story: - WordPress Vulnerabilities asset_type: Web Server confidence: 100 impact: 100 - message: Potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability on $dest$ by $src$. + message: Potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability + on $dest$ by $src$. mitre_attack_id: - T1190 observable: @@ -60,6 +72,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/wordpress/bricks_cve_2024_25600.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/wordpress/bricks_cve_2024_25600.log source: nginx:plus:kv sourcetype: nginx:plus:kv diff --git a/detections/web/ws_ftp_remote_code_execution.yml b/detections/web/ws_ftp_remote_code_execution.yml index ed2889b9c9..12d1f3d7d0 100644 --- a/detections/web/ws_ftp_remote_code_execution.yml +++ b/detections/web/ws_ftp_remote_code_execution.yml @@ -1,21 +1,30 @@ name: WS FTP Remote Code Execution id: b84e8f39-4e7b-4d4f-9e7c-fcd29a227845 -version: 1 -date: '2023-10-01' +version: 2 +date: '2024-05-11' author: Michael Haag, Splunk status: production type: TTP -data_source: +data_source: - Suricata -description: 'The following analytic is designed to detect a Remote Code Execution (RCE) vulnerability (CVE-2023-40044) in WS_FTP, a managed file transfer software by Progress. The search specifically looks for HTTP requests to the "/AHT/AhtApiService.asmx/AuthUser" URL with a status of 200, which could indicate an exploitation attempt.' -search: '| tstats count min(_time) as firstTime max(_time) - as lastTime from datamodel=Web where Web.url IN ("/AHT/AhtApiService.asmx/AuthUser") Web.status=200 Web.http_method=POST - by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype - | `drop_dm_object_name("Web")` - | `security_content_ctime(firstTime)` +description: 'The following analytic detects potential Remote Code Execution (RCE) + attempts exploiting CVE-2023-40044 in WS_FTP software. It identifies HTTP POST requests + to the "/AHT/AhtApiService.asmx/AuthUser" URL with a status code of 200. This detection + leverages the Web datamodel to monitor specific URL patterns and HTTP status codes. + This activity is significant as it may indicate an exploitation attempt, potentially + allowing an attacker to execute arbitrary code on the server. If confirmed malicious, + this could lead to unauthorized access, data exfiltration, or further compromise + of the affected system.' +search: '| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web + where Web.url IN ("/AHT/AhtApiService.asmx/AuthUser") Web.status=200 Web.http_method=POST + by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, + Web.dest, sourcetype | `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `ws_ftp_remote_code_execution_filter`' -how_to_implement: The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source. -known_false_positives: If WS_FTP Server is not in use, this analytic will not return results. Monitor and tune for your environment. Note the MetaSploit module is focused on only hitting /AHT/ and not the full /AHT/AhtApiService.asmx/AuthUser URL. +how_to_implement: The following analytic requires the Web datamodel. Ensure data source + is mapped correctly or modify and tune for your data source. +known_false_positives: If WS_FTP Server is not in use, this analytic will not return + results. Monitor and tune for your environment. Note the MetaSploit module is focused + on only hitting /AHT/ and not the full /AHT/AhtApiService.asmx/AuthUser URL. references: - https://github.com/projectdiscovery/nuclei-templates/pull/8296/files - https://www.assetnote.io/resources/research/rce-in-progress-ws-ftp-ad-hoc-via-iis-http-modules-cve-2023-40044 @@ -29,7 +38,8 @@ tags: atomic_guid: [] confidence: 80 impact: 90 - message: Potential WS FTP Remote Code Execution detected against URL $url$ on $dest$ from $src$ + message: Potential WS FTP Remote Code Execution detected against URL $url$ on $dest$ + from $src$ mitre_attack_id: - T1190 observable: @@ -40,11 +50,11 @@ tags: - name: dest type: Hostname role: - - Victim + - Victim - name: src type: IP Address role: - - Attacker + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security @@ -63,6 +73,7 @@ tags: tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ws_ftp/wsftpweb.log + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/ws_ftp/wsftpweb.log source: suricata sourcetype: suricata diff --git a/detections/web/zscaler_adware_activities_threat_blocked.yml b/detections/web/zscaler_adware_activities_threat_blocked.yml index 610f745c55..2637a4838c 100644 --- a/detections/web/zscaler_adware_activities_threat_blocked.yml +++ b/detections/web/zscaler_adware_activities_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler Adware Activities Threat Blocked id: 3407b250-345a-4d71-80db-c91e555a3ece -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-15' author: Gowthamaraj Rajendran, Splunk status: production type: Anomaly data_source: [] -description: The following analytic is designed to detect potential adware activity which is blocked by Zscaler. Utilizing Splunk search functionality, it filters web proxy logs for blocked actions associated with adware threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible adware intrusions. -search: '`zscaler_proxy` action=blocked threatname=*adware* - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies potential adware activity blocked by + Zscaler. It leverages web proxy logs to detect blocked actions associated with adware + threats. Key data points such as device owner, user, URL category, destination URL, + and IP are analyzed. This activity is significant as adware can degrade system performance, + lead to unwanted advertisements, and potentially expose users to further malicious + content. If confirmed malicious, it could indicate an attempt to compromise user + systems, necessitating further investigation and remediation to prevent potential + data breaches or system exploitation. +search: '`zscaler_proxy` action=blocked threatname=*adware* | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user urlcategory url + src dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_adware_activities_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler sourcetype: zscalernss-web diff --git a/detections/web/zscaler_behavior_analysis_threat_blocked.yml b/detections/web/zscaler_behavior_analysis_threat_blocked.yml index 258c4d56f7..a2b7853530 100644 --- a/detections/web/zscaler_behavior_analysis_threat_blocked.yml +++ b/detections/web/zscaler_behavior_analysis_threat_blocked.yml @@ -1,18 +1,28 @@ name: Zscaler Behavior Analysis Threat Blocked id: 289ad59f-8939-4331-b805-f2bd51d36fb8 -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-17' author: Rod Soto, Gowthamaraj Rajendran, Splunk status: production type: Anomaly data_source: [] -description: The analytic is built to identify threats blocked by the Zscaler proxy based on behavior analysis. It filters web proxy logs for entries where actions are blocked and threat names and classes are specified. The search further refines the results to include only those with reasons related to "block". It then aggregates the count, providing a clear view of the threat landscape as handled by the behavior analysis proxy. -search: '`zscaler_proxy` action=blocked threatname!="None" threatclass="Behavior Analysis" - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user threatname url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies threats blocked by the Zscaler proxy + based on behavior analysis. It leverages web proxy logs to detect entries where + actions are blocked and threat names and classes are specified. This detection is + significant as it highlights potential malicious activities that were intercepted + by Zscaler's behavior analysis, providing early indicators of threats. If confirmed + malicious, these blocked threats could indicate attempted breaches or malware infections, + helping security teams to understand and mitigate potential risks in their environment. +search: '`zscaler_proxy` action=blocked threatname!="None" threatclass="Behavior Analysis" + | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner + user threatname url src dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_behavior_analysis_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscalar configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -22,7 +32,8 @@ tags: asset_type: Web Server confidence: 80 impact: 10 - message: Potential Adware Behavior Analysis Threat from dest -[$dest$] on $src$ for user-[$user$]. + message: Potential Adware Behavior Analysis Threat from dest -[$dest$] on $src$ + for user-[$user$]. mitre_attack_id: - T1566 observable: @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_cryptominer_downloaded_threat_blocked.yml b/detections/web/zscaler_cryptominer_downloaded_threat_blocked.yml index 8aee6fa555..f89e0356df 100644 --- a/detections/web/zscaler_cryptominer_downloaded_threat_blocked.yml +++ b/detections/web/zscaler_cryptominer_downloaded_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler CryptoMiner Downloaded Threat Blocked id: ed76ce37-bab9-4ec0-bf3e-9c6a6cf43365 -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-22' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is crafted to detect potential download of cryptomining software within a network that is blocked by Zscaler. Utilizing Splunk search functionality, it sifts through web proxy logs for blocked actions associated with cryptominer threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible cryptominer downloads. This detection, categorized as an anomaly, aids in early identification and mitigation of cryptomining activities, ensuring network integrity and resource availability. -search: '`zscaler_proxy` action=blocked threatname=*miner* - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies attempts to download cryptomining software + that are blocked by Zscaler. It leverages web proxy logs to detect blocked actions + associated with cryptominer threats, analyzing key data points such as device owner, + user, URL category, destination URL, and IP. This activity is significant for a + SOC as it helps in early identification and mitigation of cryptomining activities, + which can compromise network integrity and resource availability. If confirmed malicious, + this activity could lead to unauthorized use of network resources for cryptomining, + potentially degrading system performance and increasing operational costs. +search: '`zscaler_proxy` action=blocked threatname=*miner* | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_cryptominer_downloaded_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -22,7 +33,8 @@ tags: asset_type: Web Server confidence: 80 impact: 40 - message: Potential CryptoMiner Downloaded Threat from dest -[$dest$] on $src$ for user-[$user$]. + message: Potential CryptoMiner Downloaded Threat from dest -[$dest$] on $src$ for + user-[$user$]. mitre_attack_id: - T1566 observable: @@ -49,14 +61,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler sourcetype: zscalernss-web diff --git a/detections/web/zscaler_employment_search_web_activity.yml b/detections/web/zscaler_employment_search_web_activity.yml index e843745807..d515afdc21 100644 --- a/detections/web/zscaler_employment_search_web_activity.yml +++ b/detections/web/zscaler_employment_search_web_activity.yml @@ -1,18 +1,29 @@ name: Zscaler Employment Search Web Activity id: 5456bdef-d765-4565-8e1f-61ca027bc50e -version: 1 -date: '2023-11-14' +version: 2 +date: '2024-05-11' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: "The analytic is designed to identify destinations within a network deemed as potential Empolyment Searches. Utilizing Splunk's search functionality, it processes web proxy logs, focusing on entries marked as 'Job/Employment Search'. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the employment risk destinations. This anomaly-type detection aids in monitoring and managing risks, promoting a secure environment from insider threats." -search: '`zscaler_proxy` urlsupercategory="Job/Employment Search" - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: "The following analytic identifies web activity related to employment + searches within a network. It leverages Zscaler web proxy logs, focusing on entries + categorized as 'Job/Employment Search'. Key data points such as device owner, user, + URL category, destination URL, and IP are analyzed. This detection is significant + for SOCs as it helps monitor potential insider threats by identifying users who + may be seeking new employment. If confirmed malicious, this activity could indicate + a risk of data exfiltration or other insider threats, potentially leading to sensitive + information leakage or other security breaches." +search: '`zscaler_proxy` urlsupercategory="Job/Employment Search" | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_employment_search_web_activity_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -22,7 +33,8 @@ tags: asset_type: Web Server confidence: 80 impact: 5 - message: Potential Employment Search Web Activity from dest -[$dest$] on $src$ for user-[$user$]. + message: Potential Employment Search Web Activity from dest -[$dest$] on $src$ for + user-[$user$]. mitre_attack_id: - T1566 observable: @@ -49,14 +61,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_exploit_threat_blocked.yml b/detections/web/zscaler_exploit_threat_blocked.yml index 49d4cdfadf..d242640e18 100644 --- a/detections/web/zscaler_exploit_threat_blocked.yml +++ b/detections/web/zscaler_exploit_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler Exploit Threat Blocked id: 94665d8c-b841-4ff4-acb4-34d613e2cbfe -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-13' author: Rod Soto, Gowthamaraj Rajendran, Splunk status: production type: TTP data_source: [] -description: The analytic is aimed at detecting potential exploit attempts that involve command and script interpreters blocked by Zscaler. By querying web proxy logs, it isolates incidents where actions have been either blocked with references to exploits. The search compiles statistics by user, threat name, URL, hostname, file class, and filename, giving a detailed view of any exploit-related activity. Marked as a tactic, technique, and procedure (TTP), this analytic is essential for identifying and mitigating exploit attempts. -search: '`zscaler_proxy` action=blocked threatname=*exploit* - | stats count min(_time) as firstTime max(_time) as lastTime by user threatname src hostname fileclass filename url dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies potential exploit attempts involving + command and script interpreters blocked by Zscaler. It leverages web proxy logs + to detect incidents where actions are blocked due to exploit references. The detection + compiles statistics by user, threat name, URL, hostname, file class, and filename. + This activity is significant as it helps identify and mitigate exploit attempts, + which are critical for maintaining security. If confirmed malicious, such activity + could lead to unauthorized code execution, privilege escalation, or persistent access + within the environment, posing a severe threat to organizational security. +search: '`zscaler_proxy` action=blocked threatname=*exploit* | stats count min(_time) + as firstTime max(_time) as lastTime by user threatname src hostname fileclass filename + url dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_exploit_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_legal_liability_threat_blocked.yml b/detections/web/zscaler_legal_liability_threat_blocked.yml index 17ebcf1a1a..3975036c91 100644 --- a/detections/web/zscaler_legal_liability_threat_blocked.yml +++ b/detections/web/zscaler_legal_liability_threat_blocked.yml @@ -1,21 +1,31 @@ name: Zscaler Legal Liability Threat Blocked id: bbf55ebf-c416-4f62-94d9-4064f2a28014 -version: 1 -date: '2023-10-31' +version: 2 +date: '2024-05-23' author: Rod Soto, Gowthamaraj Rajendran, Splunk status: production type: Anomaly data_source: [] -description: The analytic is aimed at identifying the most significant legal liability threats blocked by zcaler web proxy. It leverages web proxy logs to list the destinations, device owners, users, URL categories, and actions that are associated with Legal Liability, by utilizing stats on unique fields, it ensures a precise focus on unique legal liability threats, thereby providing valuable insights for organizations to enforce legal compliance and risk management. -search: '`zscaler_proxy` urlclass="Legal Liability" - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` - | dedup urlcategory | `zscaler_legal_liability_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +description: The following analytic identifies significant legal liability threats + blocked by the Zscaler web proxy. It uses web proxy logs to track destinations, + device owners, users, URL categories, and actions associated with legal liability. + By leveraging statistics on unique fields, it ensures a precise focus on these threats. + This activity is significant for SOC as it helps enforce legal compliance and risk + management. If confirmed malicious, it could indicate attempts to access legally + sensitive or restricted content, potentially leading to legal repercussions and + compliance violations. +search: '`zscaler_proxy` urlclass="Legal Liability" | stats count min(_time) as firstTime + max(_time) as lastTime by action deviceowner user urlcategory url src dest | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | dedup urlcategory | `zscaler_legal_liability_threat_blocked_filter`' +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: -- https://help.zscaler.com/zia/nss-feed-output-format-web-logs +- https://help.zscaler.com/zia/nss-feed-output-format-web-logs tags: analytic_story: - Zscaler Browser Proxy Threats @@ -49,14 +59,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_malware_activity_threat_blocked.yml b/detections/web/zscaler_malware_activity_threat_blocked.yml index 97d7e7c3e5..856cc106f2 100644 --- a/detections/web/zscaler_malware_activity_threat_blocked.yml +++ b/detections/web/zscaler_malware_activity_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler Malware Activity Threat Blocked id: ae874ad8-e353-40a7-87d4-420cdfb27d1a -version: 1 -date: '2023-10-25' +version: 2 +date: '2024-05-12' author: Rod Soto, Gowthamaraj Rajendran, Splunk status: production type: Anomaly data_source: [] -description: The analytic targets the detection of potential malware activities within a network that are blocked by Zscaler. By filtering web proxy logs for blocked actions associated with malware, where a threat category is specified, the analytic aggregates occurrences by user, URL, and threat category. This approach ensures a focused identification of malware activities, making it an effective tool for ongoing network security monitoring and anomaly detection. -search: '`zscaler_proxy` action=blocked threatname=*malware* threatcategory!=None - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies potential malware activities within + a network that are blocked by Zscaler. It leverages web proxy logs to filter for + blocked actions associated with malware, aggregating occurrences by user, URL, and + threat category. This detection is significant for SOC as it highlights attempts + to access malicious content, indicating potential compromise or targeted attacks. + If confirmed malicious, this activity could signify an ongoing attempt to infiltrate + the network, necessitating immediate investigation to prevent further threats and + ensure network integrity. +search: '`zscaler_proxy` action=blocked threatname=*malware* threatcategory!=None + | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner + user urlcategory url src dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_malware_activity_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscalar configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_phishing_activity_threat_blocked.yml b/detections/web/zscaler_phishing_activity_threat_blocked.yml index a94678d350..46e4d27601 100644 --- a/detections/web/zscaler_phishing_activity_threat_blocked.yml +++ b/detections/web/zscaler_phishing_activity_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler Phishing Activity Threat Blocked id: 68d3e2c1-e97f-4310-b080-dea180b48aa9 -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-12' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is devised to detect likely phishing attempts within a network blocked by Zscaler. By leveraging Splunk search functionality, it evaluates web proxy logs for blocked actions correlated with phishing threats, specifically those tagged as HTML.Phish. Critical data points such as the user, threat name, URL, and hostname are analyzed to accentuate possible phishing activities. This anomaly-type detection serves as an early warning system, facilitating prompt investigation and mitigation of phishing threats, thereby bolstering network security. -search: '`zscaler_proxy` action=blocked threatname="HTML.Phish*" - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user threatname url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies potential phishing attempts blocked + by Zscaler within a network. It leverages web proxy logs to detect actions tagged + as HTML.Phish. The detection method involves analyzing critical data points such + as user, threat name, URL, and hostname. This activity is significant for a SOC + as it serves as an early warning system for phishing threats, enabling prompt investigation + and mitigation. If confirmed malicious, this activity could indicate an attempt + to deceive users into divulging sensitive information, potentially leading to data + breaches or credential theft. +search: '`zscaler_proxy` action=blocked threatname="HTML.Phish*" | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user threatname url src + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_phishing_activity_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscalar configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_potentially_abused_file_download.yml b/detections/web/zscaler_potentially_abused_file_download.yml index 8ccc847973..818100944d 100644 --- a/detections/web/zscaler_potentially_abused_file_download.yml +++ b/detections/web/zscaler_potentially_abused_file_download.yml @@ -1,18 +1,28 @@ name: Zscaler Potentially Abused File Download id: b0c21379-f4ba-4bac-a958-897e260f964a -version: 1 -date: '2023-11-21' +version: 2 +date: '2024-05-22' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is engineered to detect potential rarely abused malicious filetypes downloaded within a network. They are usually used to spread malwares. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to potential threats. Essential data points like the deviceowner, user, urlcategory, url, dest, and filename taken are analyzed to highlight possible malicious endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of malicious download activities, ensuring a safer network environment. -search: '`zscaler_proxy` url IN ("*.scr", "*.dll", "*.bat", "*.lnk") - | stats count min(_time) as firstTime max(_time) as lastTime by deviceowner user urlcategory url src filename dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies the download of potentially malicious + file types, such as .scr, .dll, .bat, and .lnk, within a network. It leverages web + proxy logs from Zscaler, focusing on blocked actions and analyzing fields like deviceowner, + user, urlcategory, url, dest, and filename. This activity is significant as these + file types are often used to spread malware, posing a threat to network security. + If confirmed malicious, this activity could lead to malware execution, data compromise, + or further network infiltration. +search: '`zscaler_proxy` url IN ("*.scr", "*.dll", "*.bat", "*.lnk") | stats count + min(_time) as firstTime max(_time) as lastTime by deviceowner user urlcategory url + src filename dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_potentially_abused_file_download_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +59,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_privacy_risk_destinations_threat_blocked.yml b/detections/web/zscaler_privacy_risk_destinations_threat_blocked.yml index cef1444d8b..1c3d4fe82c 100644 --- a/detections/web/zscaler_privacy_risk_destinations_threat_blocked.yml +++ b/detections/web/zscaler_privacy_risk_destinations_threat_blocked.yml @@ -1,19 +1,29 @@ name: Zscaler Privacy Risk Destinations Threat Blocked id: 5456bdef-d765-4565-8e1f-61ca027bc50d -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-24' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is designed to identify blocked destinations within a network deemed as privacy risks by Zscaler. Utilizing Splunk search functionality, it processes web proxy logs, focusing on entries marked as Privacy Risk. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the privacy risk destinations. This anomaly-type detection aids in monitoring and managing privacy risks, promoting a secure network environment. -search: '`zscaler_proxy` action=blocked urlclass="Privacy Risk" - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | dedup urlcategory - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies blocked destinations within a network + that are deemed privacy risks by Zscaler. It leverages web proxy logs, focusing + on entries marked as "Privacy Risk." Key data points such as device owner, user, + URL category, destination URL, and IP are analyzed. This activity is significant + for a SOC as it helps monitor and manage privacy risks, ensuring a secure network + environment. If confirmed malicious, this activity could indicate attempts to access + or exfiltrate sensitive information, posing a significant threat to data privacy + and security. +search: '`zscaler_proxy` action=blocked urlclass="Privacy Risk" | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src + dest | dedup urlcategory | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_privacy_risk_destinations_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -50,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_scam_destinations_threat_blocked.yml b/detections/web/zscaler_scam_destinations_threat_blocked.yml index a70bfebc16..46a7960ad0 100644 --- a/detections/web/zscaler_scam_destinations_threat_blocked.yml +++ b/detections/web/zscaler_scam_destinations_threat_blocked.yml @@ -1,17 +1,28 @@ name: Zscaler Scam Destinations Threat Blocked id: a0c21379-f4ba-4bac-a958-897e260f964a -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-27' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is engineered to detect potential scam activities within a network by Zscaler. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to scam threats. Essential data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible scam endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of scam activities, ensuring a safer network environment. -search: '`zscaler_proxy` action=blocked threatname=*scam* - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` +description: The following analytic identifies blocked scam-related activities detected + by Zscaler within a network. It leverages web proxy logs to examine actions flagged + as scam threats, focusing on data points such as device owner, user, URL category, + destination URL, and IP. This detection is significant for SOC as it helps in the + early identification and mitigation of scam activities, ensuring network safety. + If confirmed malicious, this activity could indicate attempts to deceive users, + potentially leading to data theft or financial loss. +search: '`zscaler_proxy` action=blocked threatname=*scam* | stats count min(_time) + as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src + dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_scam_destinations_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -48,14 +59,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/detections/web/zscaler_virus_download_threat_blocked.yml b/detections/web/zscaler_virus_download_threat_blocked.yml index e5e4d9dd6a..3393bd7b75 100644 --- a/detections/web/zscaler_virus_download_threat_blocked.yml +++ b/detections/web/zscaler_virus_download_threat_blocked.yml @@ -1,18 +1,29 @@ name: Zscaler Virus Download threat blocked id: aa19e627-d448-4a31-85cd-82068dec5691 -version: 1 -date: '2023-10-30' +version: 2 +date: '2024-05-17' author: Gowthamaraj Rajendran, Rod Soto, Splunk status: production type: Anomaly data_source: [] -description: The analytic is formulated to detect blocked virus download activities within a network by Zscaler. Employing Splunk's search functionality, it reviews web proxy logs for blocked actions indicative of virus threats downloads. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to pinpoint possible virus downloads. As an anomaly-type detection, this analytic facilitates early detection and remediation of virus download attempts, contributing to enhanced network security. -search: '`zscaler_proxy` action=blocked threatname!="None" threatclass=Virus - | stats count min(_time) as firstTime max(_time) as lastTime by action deviceowner user urlcategory url src dest - | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` +description: The following analytic identifies attempts to download viruses that were + blocked by Zscaler within a network. It leverages web proxy logs to detect blocked + actions indicative of virus download attempts. Key data points such as device owner, + user, URL category, destination URL, and IP are analyzed. This activity is significant + as it helps in early detection and remediation of potential virus threats, enhancing + network security. If confirmed malicious, this activity could indicate an attempt + to compromise the network, potentially leading to data breaches or further malware + infections. +search: '`zscaler_proxy` action=blocked threatname!="None" threatclass=Virus | stats + count min(_time) as firstTime max(_time) as lastTime by action deviceowner user + urlcategory url src dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `zscaler_virus_download_threat_blocked_filter`' -how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. +how_to_implement: You must install the latest version of Zscaler Add-on from Splunkbase. + You must be ingesting Zscaler events into your Splunk environment through an ingester. + This analytic was written to be used with the "zscalernss-web" sourcetype leveraging + the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. + Security teams are encouraged to adjust the detection parameters, ensuring the detection + is tailored to their specific environment. known_false_positives: False positives are limited to Zscaler configuration. references: - https://help.zscaler.com/zia/nss-feed-output-format-web-logs @@ -49,14 +60,15 @@ tags: - deviceowner - user - urlcategory - - url - - dest - - dest_ip + - url + - dest + - dest_ip - action security_domain: threat tests: - name: True Positive Test attack_data: - - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json + - data: + https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1566/zscalar_web_proxy/zscalar_web_proxy.json source: zscaler - sourcetype: zscalernss-web \ No newline at end of file + sourcetype: zscalernss-web diff --git a/dev/endpoint/curl_download_and_bash_execution.yml b/dev/endpoint/curl_download_and_bash_execution.yml index 112e6a34d7..ca56a403dc 100644 --- a/dev/endpoint/curl_download_and_bash_execution.yml +++ b/dev/endpoint/curl_download_and_bash_execution.yml @@ -69,4 +69,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/java_writing_jsp_file.yml b/dev/endpoint/java_writing_jsp_file.yml index ee946194ba..31e442bd94 100644 --- a/dev/endpoint/java_writing_jsp_file.yml +++ b/dev/endpoint/java_writing_jsp_file.yml @@ -68,4 +68,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/spring4shell/java_write_jsp-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml b/dev/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml index a90ed9fdf9..ef53991417 100644 --- a/dev/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml +++ b/dev/endpoint/linux_account_manipulation_of_ssh_config_and_keys.yml @@ -56,4 +56,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_add_files_in_known_crontab_directories.yml b/dev/endpoint/linux_add_files_in_known_crontab_directories.yml index 06fc89c857..173a50356b 100644 --- a/dev/endpoint/linux_add_files_in_known_crontab_directories.yml +++ b/dev/endpoint/linux_add_files_in_known_crontab_directories.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_add_user_account.yml b/dev/endpoint/linux_add_user_account.yml index 721a9eb869..3a981ab90e 100644 --- a/dev/endpoint/linux_add_user_account.yml +++ b/dev/endpoint/linux_add_user_account.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/linux_adduser/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_adding_crontab_using_list_parameter.yml b/dev/endpoint/linux_adding_crontab_using_list_parameter.yml index f575b4c3a6..edf667f465 100644 --- a/dev/endpoint/linux_adding_crontab_using_list_parameter.yml +++ b/dev/endpoint/linux_adding_crontab_using_list_parameter.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_list_parameter/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_apt_get_privilege_escalation.yml b/dev/endpoint/linux_apt_get_privilege_escalation.yml index cc67782702..366445fc2a 100644 --- a/dev/endpoint/linux_apt_get_privilege_escalation.yml +++ b/dev/endpoint/linux_apt_get_privilege_escalation.yml @@ -65,5 +65,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt_get/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_apt_privilege_escalation.yml b/dev/endpoint/linux_apt_privilege_escalation.yml index 0e99d64c8e..e874966639 100644 --- a/dev/endpoint/linux_apt_privilege_escalation.yml +++ b/dev/endpoint/linux_apt_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/apt/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_at_allow_config_file_creation.yml b/dev/endpoint/linux_at_allow_config_file_creation.yml index 508edabf92..5c33a14901 100644 --- a/dev/endpoint/linux_at_allow_config_file_creation.yml +++ b/dev/endpoint/linux_at_allow_config_file_creation.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_at_application_execution.yml b/dev/endpoint/linux_at_application_execution.yml index db86911941..1e9c02f275 100644 --- a/dev/endpoint/linux_at_application_execution.yml +++ b/dev/endpoint/linux_at_application_execution.yml @@ -60,4 +60,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_awk_privilege_escalation.yml b/dev/endpoint/linux_awk_privilege_escalation.yml index df0abb0e89..bd9aaf4539 100644 --- a/dev/endpoint/linux_awk_privilege_escalation.yml +++ b/dev/endpoint/linux_awk_privilege_escalation.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/awk/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_busybox_privilege_escalation.yml b/dev/endpoint/linux_busybox_privilege_escalation.yml index 766c72be8f..b4dc8979ce 100644 --- a/dev/endpoint/linux_busybox_privilege_escalation.yml +++ b/dev/endpoint/linux_busybox_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/busybox/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_c89_privilege_escalation.yml b/dev/endpoint/linux_c89_privilege_escalation.yml index aabaa263ac..50312ea89e 100644 --- a/dev/endpoint/linux_c89_privilege_escalation.yml +++ b/dev/endpoint/linux_c89_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c89/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_c99_privilege_escalation.yml b/dev/endpoint/linux_c99_privilege_escalation.yml index c59d23755f..8e4b8ff9ee 100644 --- a/dev/endpoint/linux_c99_privilege_escalation.yml +++ b/dev/endpoint/linux_c99_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/c99/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_change_file_owner_to_root.yml b/dev/endpoint/linux_change_file_owner_to_root.yml index 31cb6cf931..94f70fb652 100644 --- a/dev/endpoint/linux_change_file_owner_to_root.yml +++ b/dev/endpoint/linux_change_file_owner_to_root.yml @@ -58,4 +58,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_clipboard_data_copy.yml b/dev/endpoint/linux_clipboard_data_copy.yml index 4b463b25c2..fa24f802be 100644 --- a/dev/endpoint/linux_clipboard_data_copy.yml +++ b/dev/endpoint/linux_clipboard_data_copy.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1115/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_common_process_for_elevation_control.yml b/dev/endpoint/linux_common_process_for_elevation_control.yml index d7e5a0114b..3fb272275e 100644 --- a/dev/endpoint/linux_common_process_for_elevation_control.yml +++ b/dev/endpoint/linux_common_process_for_elevation_control.yml @@ -93,4 +93,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_composer_privilege_escalation.yml b/dev/endpoint/linux_composer_privilege_escalation.yml index 94efab82d5..a1b28e59e8 100644 --- a/dev/endpoint/linux_composer_privilege_escalation.yml +++ b/dev/endpoint/linux_composer_privilege_escalation.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/composer/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_cpulimit_privilege_escalation.yml b/dev/endpoint/linux_cpulimit_privilege_escalation.yml index 3bce76236c..886009ea58 100644 --- a/dev/endpoint/linux_cpulimit_privilege_escalation.yml +++ b/dev/endpoint/linux_cpulimit_privilege_escalation.yml @@ -66,5 +66,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/cpulimit/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_csvtool_privilege_escalation.yml b/dev/endpoint/linux_csvtool_privilege_escalation.yml index 9777eed52c..5c6d74f3a4 100644 --- a/dev/endpoint/linux_csvtool_privilege_escalation.yml +++ b/dev/endpoint/linux_csvtool_privilege_escalation.yml @@ -61,5 +61,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/csvtool/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_curl_upload_file.yml b/dev/endpoint/linux_curl_upload_file.yml index 89bb44795f..c810ebb3c3 100644 --- a/dev/endpoint/linux_curl_upload_file.yml +++ b/dev/endpoint/linux_curl_upload_file.yml @@ -80,5 +80,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_dd_file_overwrite.yml b/dev/endpoint/linux_dd_file_overwrite.yml index fa1caed075..134800c879 100644 --- a/dev/endpoint/linux_dd_file_overwrite.yml +++ b/dev/endpoint/linux_dd_file_overwrite.yml @@ -52,4 +52,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/linux_dd_file_overwrite/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_decode_base64_to_shell.yml b/dev/endpoint/linux_decode_base64_to_shell.yml index 73e4cff118..73a38becf9 100644 --- a/dev/endpoint/linux_decode_base64_to_shell.yml +++ b/dev/endpoint/linux_decode_base64_to_shell.yml @@ -67,5 +67,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_deleting_critical_directory_using_rm_command.yml b/dev/endpoint/linux_deleting_critical_directory_using_rm_command.yml index a811b937b2..0b573a38e1 100644 --- a/dev/endpoint/linux_deleting_critical_directory_using_rm_command.yml +++ b/dev/endpoint/linux_deleting_critical_directory_using_rm_command.yml @@ -60,4 +60,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_deletion_of_cron_jobs.yml b/dev/endpoint/linux_deletion_of_cron_jobs.yml index 6ffcf08b33..e6922761b1 100644 --- a/dev/endpoint/linux_deletion_of_cron_jobs.yml +++ b/dev/endpoint/linux_deletion_of_cron_jobs.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_deletion_of_init_daemon_script.yml b/dev/endpoint/linux_deletion_of_init_daemon_script.yml index 050d7ac807..c139919851 100644 --- a/dev/endpoint/linux_deletion_of_init_daemon_script.yml +++ b/dev/endpoint/linux_deletion_of_init_daemon_script.yml @@ -56,4 +56,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_deletion_of_services.yml b/dev/endpoint/linux_deletion_of_services.yml index ae51b09c7f..487761fb6c 100644 --- a/dev/endpoint/linux_deletion_of_services.yml +++ b/dev/endpoint/linux_deletion_of_services.yml @@ -58,4 +58,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_deletion_of_ssl_certificate.yml b/dev/endpoint/linux_deletion_of_ssl_certificate.yml index 6a1757b861..a0ac97d0a9 100644 --- a/dev/endpoint/linux_deletion_of_ssl_certificate.yml +++ b/dev/endpoint/linux_deletion_of_ssl_certificate.yml @@ -59,4 +59,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/acidrain/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_disable_services.yml b/dev/endpoint/linux_disable_services.yml index 9548d01fce..12fb5a6386 100644 --- a/dev/endpoint/linux_disable_services.yml +++ b/dev/endpoint/linux_disable_services.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_doas_conf_file_creation.yml b/dev/endpoint/linux_doas_conf_file_creation.yml index 306793a46c..72934a3eb3 100644 --- a/dev/endpoint/linux_doas_conf_file_creation.yml +++ b/dev/endpoint/linux_doas_conf_file_creation.yml @@ -54,4 +54,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_doas_tool_execution.yml b/dev/endpoint/linux_doas_tool_execution.yml index d8d78d74c4..0f3f1e3f0d 100644 --- a/dev/endpoint/linux_doas_tool_execution.yml +++ b/dev/endpoint/linux_doas_tool_execution.yml @@ -54,4 +54,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/doas_exec/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_docker_privilege_escalation.yml b/dev/endpoint/linux_docker_privilege_escalation.yml index 33d10e0e72..ae128bff7f 100644 --- a/dev/endpoint/linux_docker_privilege_escalation.yml +++ b/dev/endpoint/linux_docker_privilege_escalation.yml @@ -66,5 +66,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/docker/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_edit_cron_table_parameter.yml b/dev/endpoint/linux_edit_cron_table_parameter.yml index da64a96cbd..3a7b34e1bc 100644 --- a/dev/endpoint/linux_edit_cron_table_parameter.yml +++ b/dev/endpoint/linux_edit_cron_table_parameter.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_edit_parameter/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_emacs_privilege_escalation.yml b/dev/endpoint/linux_emacs_privilege_escalation.yml index 188c7c9044..6e10a076b4 100644 --- a/dev/endpoint/linux_emacs_privilege_escalation.yml +++ b/dev/endpoint/linux_emacs_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/emacs/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_file_created_in_kernel_driver_directory.yml b/dev/endpoint/linux_file_created_in_kernel_driver_directory.yml index 4dcfabdcba..4f15b09552 100644 --- a/dev/endpoint/linux_file_created_in_kernel_driver_directory.yml +++ b/dev/endpoint/linux_file_created_in_kernel_driver_directory.yml @@ -56,4 +56,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_file_creation_in_init_boot_directory.yml b/dev/endpoint/linux_file_creation_in_init_boot_directory.yml index d259cdef14..17089f7851 100644 --- a/dev/endpoint/linux_file_creation_in_init_boot_directory.yml +++ b/dev/endpoint/linux_file_creation_in_init_boot_directory.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_file_creation_in_profile_directory.yml b/dev/endpoint/linux_file_creation_in_profile_directory.yml index 9ec55d1d47..d34b70b535 100644 --- a/dev/endpoint/linux_file_creation_in_profile_directory.yml +++ b/dev/endpoint/linux_file_creation_in_profile_directory.yml @@ -53,4 +53,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_find_privilege_escalation.yml b/dev/endpoint/linux_find_privilege_escalation.yml index b99d1bcb19..c498d890bb 100644 --- a/dev/endpoint/linux_find_privilege_escalation.yml +++ b/dev/endpoint/linux_find_privilege_escalation.yml @@ -65,5 +65,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/find/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_gdb_privilege_escalation.yml b/dev/endpoint/linux_gdb_privilege_escalation.yml index 0ebdf76fdd..bbe155eb3f 100644 --- a/dev/endpoint/linux_gdb_privilege_escalation.yml +++ b/dev/endpoint/linux_gdb_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gdb/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_gem_privilege_escalation.yml b/dev/endpoint/linux_gem_privilege_escalation.yml index daeb92ed49..9d2f025e69 100644 --- a/dev/endpoint/linux_gem_privilege_escalation.yml +++ b/dev/endpoint/linux_gem_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gem/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_gnu_awk_privilege_escalation.yml b/dev/endpoint/linux_gnu_awk_privilege_escalation.yml index 02cc79428d..f7e6293bc9 100644 --- a/dev/endpoint/linux_gnu_awk_privilege_escalation.yml +++ b/dev/endpoint/linux_gnu_awk_privilege_escalation.yml @@ -67,5 +67,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/gawk/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_ingress_tool_transfer_hunting.yml b/dev/endpoint/linux_ingress_tool_transfer_hunting.yml index 20e5ae720f..e9b1929248 100644 --- a/dev/endpoint/linux_ingress_tool_transfer_hunting.yml +++ b/dev/endpoint/linux_ingress_tool_transfer_hunting.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_ingress_tool_transfer_with_curl.yml b/dev/endpoint/linux_ingress_tool_transfer_with_curl.yml index 0023b27f6e..4d2822d3fc 100644 --- a/dev/endpoint/linux_ingress_tool_transfer_with_curl.yml +++ b/dev/endpoint/linux_ingress_tool_transfer_with_curl.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_insert_kernel_module_using_insmod_utility.yml b/dev/endpoint/linux_insert_kernel_module_using_insmod_utility.yml index cbc866aa30..08bf70fe8c 100644 --- a/dev/endpoint/linux_insert_kernel_module_using_insmod_utility.yml +++ b/dev/endpoint/linux_insert_kernel_module_using_insmod_utility.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_install_kernel_module_using_modprobe_utility.yml b/dev/endpoint/linux_install_kernel_module_using_modprobe_utility.yml index a5c8918f84..f9be77532e 100644 --- a/dev/endpoint/linux_install_kernel_module_using_modprobe_utility.yml +++ b/dev/endpoint/linux_install_kernel_module_using_modprobe_utility.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/loading_linux_kernel_module/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_iptables_firewall_modification.yml b/dev/endpoint/linux_iptables_firewall_modification.yml index 533e36fc1f..bc64379af3 100644 --- a/dev/endpoint/linux_iptables_firewall_modification.yml +++ b/dev/endpoint/linux_iptables_firewall_modification.yml @@ -58,4 +58,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_java_spawning_shell.yml b/dev/endpoint/linux_java_spawning_shell.yml index 4206667114..b73e7ca450 100644 --- a/dev/endpoint/linux_java_spawning_shell.yml +++ b/dev/endpoint/linux_java_spawning_shell.yml @@ -69,4 +69,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/java/java_spawn_shell_nix.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_kernel_module_enumeration.yml b/dev/endpoint/linux_kernel_module_enumeration.yml index b2c2f7ed09..6b41f0d000 100644 --- a/dev/endpoint/linux_kernel_module_enumeration.yml +++ b/dev/endpoint/linux_kernel_module_enumeration.yml @@ -65,5 +65,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1082/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_kworker_process_in_writable_process_path.yml b/dev/endpoint/linux_kworker_process_in_writable_process_path.yml index 959a0c31e6..889fadb668 100644 --- a/dev/endpoint/linux_kworker_process_in_writable_process_path.yml +++ b/dev/endpoint/linux_kworker_process_in_writable_process_path.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_make_privilege_escalation.yml b/dev/endpoint/linux_make_privilege_escalation.yml index dfafc4e83b..cdbe3bd005 100644 --- a/dev/endpoint/linux_make_privilege_escalation.yml +++ b/dev/endpoint/linux_make_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/make/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_mysql_privilege_escalation.yml b/dev/endpoint/linux_mysql_privilege_escalation.yml index 83f14a5ea9..52b3c9f4b5 100644 --- a/dev/endpoint/linux_mysql_privilege_escalation.yml +++ b/dev/endpoint/linux_mysql_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/mysql/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_node_privilege_escalation.yml b/dev/endpoint/linux_node_privilege_escalation.yml index 8bab4bc178..5bbf8cabdc 100644 --- a/dev/endpoint/linux_node_privilege_escalation.yml +++ b/dev/endpoint/linux_node_privilege_escalation.yml @@ -67,5 +67,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/node/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_nopasswd_entry_in_sudoers_file.yml b/dev/endpoint/linux_nopasswd_entry_in_sudoers_file.yml index 5e48ce4a1a..583470b1e9 100644 --- a/dev/endpoint/linux_nopasswd_entry_in_sudoers_file.yml +++ b/dev/endpoint/linux_nopasswd_entry_in_sudoers_file.yml @@ -54,4 +54,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/nopasswd_sudoers/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_obfuscated_files_or_information_base64_decode.yml b/dev/endpoint/linux_obfuscated_files_or_information_base64_decode.yml index 0279453088..67991a8df0 100644 --- a/dev/endpoint/linux_obfuscated_files_or_information_base64_decode.yml +++ b/dev/endpoint/linux_obfuscated_files_or_information_base64_decode.yml @@ -65,5 +65,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_octave_privilege_escalation.yml b/dev/endpoint/linux_octave_privilege_escalation.yml index 7b84eb5dcb..33b16e8927 100644 --- a/dev/endpoint/linux_octave_privilege_escalation.yml +++ b/dev/endpoint/linux_octave_privilege_escalation.yml @@ -67,5 +67,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/octave/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_openvpn_privilege_escalation.yml b/dev/endpoint/linux_openvpn_privilege_escalation.yml index ab7bcfb707..c28b187d4e 100644 --- a/dev/endpoint/linux_openvpn_privilege_escalation.yml +++ b/dev/endpoint/linux_openvpn_privilege_escalation.yml @@ -68,5 +68,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/openvpn/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_php_privilege_escalation.yml b/dev/endpoint/linux_php_privilege_escalation.yml index 4697b43e02..8bca4dd1ad 100644 --- a/dev/endpoint/linux_php_privilege_escalation.yml +++ b/dev/endpoint/linux_php_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/php/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_pkexec_privilege_escalation.yml b/dev/endpoint/linux_pkexec_privilege_escalation.yml index e8396bf68b..998f5630fd 100644 --- a/dev/endpoint/linux_pkexec_privilege_escalation.yml +++ b/dev/endpoint/linux_pkexec_privilege_escalation.yml @@ -71,4 +71,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1068/pkexec/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml b/dev/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml index d490078810..488622ca90 100644 --- a/dev/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml +++ b/dev/endpoint/linux_possible_access_or_modification_of_sshd_config_file.yml @@ -59,4 +59,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_access_to_credential_files.yml b/dev/endpoint/linux_possible_access_to_credential_files.yml index 2cad481cce..44ad9ca6d8 100644 --- a/dev/endpoint/linux_possible_access_to_credential_files.yml +++ b/dev/endpoint/linux_possible_access_to_credential_files.yml @@ -61,4 +61,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_access_to_sudoers_file.yml b/dev/endpoint/linux_possible_access_to_sudoers_file.yml index 8e761139c2..8c3a2808b3 100644 --- a/dev/endpoint/linux_possible_access_to_sudoers_file.yml +++ b/dev/endpoint/linux_possible_access_to_sudoers_file.yml @@ -57,4 +57,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003.008/copy_file_stdoutpipe/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_append_command_to_at_allow_config_file.yml b/dev/endpoint/linux_possible_append_command_to_at_allow_config_file.yml index 694b56c795..ec7f98aa12 100644 --- a/dev/endpoint/linux_possible_append_command_to_at_allow_config_file.yml +++ b/dev/endpoint/linux_possible_append_command_to_at_allow_config_file.yml @@ -53,4 +53,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/at_execution/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_append_command_to_profile_config_file.yml b/dev/endpoint/linux_possible_append_command_to_profile_config_file.yml index 5edb9b76b0..62cd8bb9cc 100644 --- a/dev/endpoint/linux_possible_append_command_to_profile_config_file.yml +++ b/dev/endpoint/linux_possible_append_command_to_profile_config_file.yml @@ -62,4 +62,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml b/dev/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml index 23439ab989..a6b0b89f94 100644 --- a/dev/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml +++ b/dev/endpoint/linux_possible_append_cronjob_entry_on_existing_cronjob_file.yml @@ -58,4 +58,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_cronjob_modification_with_editor.yml b/dev/endpoint/linux_possible_cronjob_modification_with_editor.yml index c1b68c9cf9..c88b5bd5d1 100644 --- a/dev/endpoint/linux_possible_cronjob_modification_with_editor.yml +++ b/dev/endpoint/linux_possible_cronjob_modification_with_editor.yml @@ -63,4 +63,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/cronjobs_entry/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_possible_ssh_key_file_creation.yml b/dev/endpoint/linux_possible_ssh_key_file_creation.yml index 43b75be536..6b8eadaae4 100644 --- a/dev/endpoint/linux_possible_ssh_key_file_creation.yml +++ b/dev/endpoint/linux_possible_ssh_key_file_creation.yml @@ -53,4 +53,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_preload_hijack_library_calls.yml b/dev/endpoint/linux_preload_hijack_library_calls.yml index 0bf385f1b4..c0b57f5515 100644 --- a/dev/endpoint/linux_preload_hijack_library_calls.yml +++ b/dev/endpoint/linux_preload_hijack_library_calls.yml @@ -51,4 +51,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.006/lib_hijack/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_proxy_socks_curl.yml b/dev/endpoint/linux_proxy_socks_curl.yml index 6f3d7cca7d..542282e84b 100644 --- a/dev/endpoint/linux_proxy_socks_curl.yml +++ b/dev/endpoint/linux_proxy_socks_curl.yml @@ -79,5 +79,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/curl-linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_puppet_privilege_escalation.yml b/dev/endpoint/linux_puppet_privilege_escalation.yml index 23faf701cb..4f905e2f17 100644 --- a/dev/endpoint/linux_puppet_privilege_escalation.yml +++ b/dev/endpoint/linux_puppet_privilege_escalation.yml @@ -68,5 +68,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/puppet/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_rpm_privilege_escalation.yml b/dev/endpoint/linux_rpm_privilege_escalation.yml index 71b1a9e762..c5419adc39 100644 --- a/dev/endpoint/linux_rpm_privilege_escalation.yml +++ b/dev/endpoint/linux_rpm_privilege_escalation.yml @@ -66,5 +66,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/rpm/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_ruby_privilege_escalation.yml b/dev/endpoint/linux_ruby_privilege_escalation.yml index a884619193..62d1f2593c 100644 --- a/dev/endpoint/linux_ruby_privilege_escalation.yml +++ b/dev/endpoint/linux_ruby_privilege_escalation.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/ruby/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_service_file_created_in_systemd_directory.yml b/dev/endpoint/linux_service_file_created_in_systemd_directory.yml index f8a3f8941c..32366a555e 100644 --- a/dev/endpoint/linux_service_file_created_in_systemd_directory.yml +++ b/dev/endpoint/linux_service_file_created_in_systemd_directory.yml @@ -68,4 +68,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_service_restarted.yml b/dev/endpoint/linux_service_restarted.yml index 0f7bc8ab91..71b034318a 100644 --- a/dev/endpoint/linux_service_restarted.yml +++ b/dev/endpoint/linux_service_restarted.yml @@ -67,4 +67,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_service_started_or_enabled.yml b/dev/endpoint/linux_service_started_or_enabled.yml index 17f2e025b0..aebf6a979d 100644 --- a/dev/endpoint/linux_service_started_or_enabled.yml +++ b/dev/endpoint/linux_service_started_or_enabled.yml @@ -66,4 +66,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_setuid_using_setcap_utility.yml b/dev/endpoint/linux_setuid_using_setcap_utility.yml index 92b42ca48b..74ca3e98a1 100644 --- a/dev/endpoint/linux_setuid_using_setcap_utility.yml +++ b/dev/endpoint/linux_setuid_using_setcap_utility.yml @@ -59,4 +59,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_setcap/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_shred_overwrite_command.yml b/dev/endpoint/linux_shred_overwrite_command.yml index 3e13f9b5ca..1502728e3f 100644 --- a/dev/endpoint/linux_shred_overwrite_command.yml +++ b/dev/endpoint/linux_shred_overwrite_command.yml @@ -59,4 +59,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_sqlite3_privilege_escalation.yml b/dev/endpoint/linux_sqlite3_privilege_escalation.yml index 998491018b..3ca3ee937b 100644 --- a/dev/endpoint/linux_sqlite3_privilege_escalation.yml +++ b/dev/endpoint/linux_sqlite3_privilege_escalation.yml @@ -64,5 +64,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/sqlite3/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_ssh_authorized_keys_modification.yml b/dev/endpoint/linux_ssh_authorized_keys_modification.yml index ba92749430..e829fefaad 100644 --- a/dev/endpoint/linux_ssh_authorized_keys_modification.yml +++ b/dev/endpoint/linux_ssh_authorized_keys_modification.yml @@ -66,5 +66,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.004/ssh_authorized_keys/authkey_linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_ssh_remote_services_script_execute.yml b/dev/endpoint/linux_ssh_remote_services_script_execute.yml index fd96a248d1..0260d12c2e 100644 --- a/dev/endpoint/linux_ssh_remote_services_script_execute.yml +++ b/dev/endpoint/linux_ssh_remote_services_script_execute.yml @@ -63,5 +63,5 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1021.004/atomic_red_team/linux-sysmon.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux update_timestamp: true diff --git a/dev/endpoint/linux_stdout_redirection_to_dev_null_file.yml b/dev/endpoint/linux_stdout_redirection_to_dev_null_file.yml index 68408a2461..6a891ee3cc 100644 --- a/dev/endpoint/linux_stdout_redirection_to_dev_null_file.yml +++ b/dev/endpoint/linux_stdout_redirection_to_dev_null_file.yml @@ -52,4 +52,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/cyclopsblink/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_stop_services.yml b/dev/endpoint/linux_stop_services.yml index 44853d0004..74752efd21 100644 --- a/dev/endpoint/linux_stop_services.yml +++ b/dev/endpoint/linux_stop_services.yml @@ -55,4 +55,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_sudo_or_su_execution.yml b/dev/endpoint/linux_sudo_or_su_execution.yml index c985756916..3e101898c0 100644 --- a/dev/endpoint/linux_sudo_or_su_execution.yml +++ b/dev/endpoint/linux_sudo_or_su_execution.yml @@ -60,4 +60,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudo_su/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_sudoers_tmp_file_creation.yml b/dev/endpoint/linux_sudoers_tmp_file_creation.yml index 001c2c3237..4d2f1f80c4 100644 --- a/dev/endpoint/linux_sudoers_tmp_file_creation.yml +++ b/dev/endpoint/linux_sudoers_tmp_file_creation.yml @@ -53,4 +53,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/sudoers_temp/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_system_network_discovery.yml b/dev/endpoint/linux_system_network_discovery.yml index 72b4193400..5118a822f1 100644 --- a/dev/endpoint/linux_system_network_discovery.yml +++ b/dev/endpoint/linux_system_network_discovery.yml @@ -59,4 +59,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1016/atomic_red_team/linux_net_discovery/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/linux_visudo_utility_execution.yml b/dev/endpoint/linux_visudo_utility_execution.yml index 1a514dd3be..3847f71449 100644 --- a/dev/endpoint/linux_visudo_utility_execution.yml +++ b/dev/endpoint/linux_visudo_utility_execution.yml @@ -53,4 +53,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/visudo/sysmon_linux.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev/endpoint/wget_download_and_bash_execution.yml b/dev/endpoint/wget_download_and_bash_execution.yml index 190070ae4b..294f091fd4 100644 --- a/dev/endpoint/wget_download_and_bash_execution.yml +++ b/dev/endpoint/wget_download_and_bash_execution.yml @@ -74,4 +74,4 @@ tests: attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1105/atomic_red_team/linux-sysmon_curlwget.log source: Syslog:Linux-Sysmon/Operational - sourcetype: sysmon_linux + sourcetype: sysmon:linux diff --git a/dev_ssa/endpoint/ssa___executable_file_written_in_administrative_smb_share.yml b/dev_ssa/endpoint/ssa___executable_file_written_in_administrative_smb_share.yml new file mode 100644 index 0000000000..a13ed29671 --- /dev/null +++ b/dev_ssa/endpoint/ssa___executable_file_written_in_administrative_smb_share.yml @@ -0,0 +1,74 @@ +name: Executable File Written in Administrative SMB Share +id: d3bba9cb-c066-4e49-a81e-29eeb8e8506b +version: 1 +date: "2024-05-28" +author: Teoderick Contreras, Mauricio Velazco, Splunk +status: production +type: TTP +description: + The following analytic identifies executable files (.exe or .dll) being + written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents + suspicious behavior as its commonly used by tools like PsExec/PaExec and others + to stage service binaries before creating and starting a Windows service on remote + endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral + movement and remote code execution. The Trickbot malware family also implements + this behavior to try to infect other machines in the infected network. +data_source: + - Windows Event Log Security 5145 +search: + selection1: + file.path|endswith: + - .exe + - .dll + file.type: File + share: + - \\\\*\\C$ + - \\\\*\\IPC$ + - \\\\*\\admin$ + access_mask: 2 + condition: selection1 +how_to_implement: + To successfully implement this search, you need to be ingesting + Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also + required. Also enable the object Audit access success/failure in your group policy. +known_false_positives: + System Administrators may use looks like PsExec for troubleshooting + or administrations tasks. However, this will typically come only from certain users + and certain systems that can be added to an allow list. +references: + - https://attack.mitre.org/techniques/T1021/002/ + - https://www.rapid7.com/blog/post/2013/03/09/psexec-demystified/ + - https://labs.vipre.com/trickbot-and-its-modules/ + - https://whitehat.eu/incident-response-case-study-featuring-ryuk-and-trickbot-part-2/ + - https://thedfirreport.com/2023/05/22/icedid-macro-ends-in-nokoyawa-ransomware/ +tags: + analytic_story: + - Active Directory Lateral Movement + - Prestige Ransomware + - Graceful Wipe Out Attack + - Industroyer2 + - IcedID + - Data Destruction + - Hermetic Wiper + - Trickbot + asset_type: Endpoint + confidence: 100 + impact: 70 + message: + $src_user$ dropped or created an executable file in known sensitive SMB share. Share + name=$ShareName$, Target name=$RelativeTargetName$, and Access mask=$AccessMask$ + mitre_attack_id: + - T1021 + - T1021.002 + observable: [] + product: + - Splunk Behavioral Analytics + required_fields: [] + risk_score: 70 + security_domain: endpoint +tests: + - name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/trickbot/exe_smbshare/windows-xml.log + source: XmlWinEventLog:Security + sourcetype: XmlWinEventLog diff --git a/dist/DA-ESS-ContentUpdate/app.manifest b/dist/DA-ESS-ContentUpdate/app.manifest index 5986dfb981..61d679b922 100644 --- a/dist/DA-ESS-ContentUpdate/app.manifest +++ b/dist/DA-ESS-ContentUpdate/app.manifest @@ -5,7 +5,7 @@ "id": { "group": null, "name": "DA-ESS-ContentUpdate", - "version": "4.33.0" + "version": "4.34.0" }, "author": [ { @@ -14,7 +14,7 @@ "company": "Splunk" } ], - "releaseDate": "2024-06-06", + "releaseDate": "2024-06-26", "description": "Explore the Analytic Stories included with ES Content Updates.", "classification": { "intendedAudience": null, diff --git a/dist/DA-ESS-ContentUpdate/default/analyticstories.conf b/dist/DA-ESS-ContentUpdate/default/analyticstories.conf index e9111c3f31..4ff8475cff 100644 --- a/dist/DA-ESS-ContentUpdate/default/analyticstories.conf +++ b/dist/DA-ESS-ContentUpdate/default/analyticstories.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# @@ -32,7 +32,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic uses a pretrained machine learning text classifier to detect potentially risky commands. The model is trained independently and then the model file is packaged within ESCU for usage. A command is deemed risky based on the presence of certain trigger keywords, along with the context and the role of the user (please see references). The model uses custom features to predict whether a SPL is risky using text classification. The model takes as input the command text, user and search type and outputs a risk score between [0,1]. A high score indicates higher likelihood of a command being risky. This model is on-prem only. +explanation = The following analytic identifies potentially risky SPL commands executed by users. It leverages a pretrained machine learning text classifier that analyzes command text, user, and search type to assign a risk score between 0 and 1. This detection is significant as it helps identify suspicious or unauthorized search activities that could indicate malicious intent or misuse of the Splunk environment. If confirmed malicious, such activity could lead to unauthorized data access, data exfiltration, or further exploitation of the system. how_to_implement = This detection depends on the MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Additionally, you need to be ingesting logs which include Search_Activity.search, Search_Activity.user, Search_Activity.search_type from your endpoints. The risk score threshold should be adjusted based on the environment. The detection uses a custom MLTK model hence we need a few more steps for deployment, as outlined here - https://gist.github.com/ksharad-splunk/be2a62227966049047f5e5c4f2adcabb. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if suspicious behavior is observed, as determined by frequent usage of risky keywords. @@ -84,7 +84,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. Windows updates are typically released monthly and applied shortly thereafter. An endpoint that has not successfully applied an update in this time frame indicates the endpoint is not regularly being patched for some reason. +explanation = The following analytic identifies Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. It leverages the 'Update' data model in Splunk, specifically looking for the latest 'Installed' status events from Microsoft Windows. This activity is significant for a SOC because endpoints that are not regularly patched are vulnerable to known exploits and security vulnerabilities. If confirmed malicious, this could indicate a compromised endpoint that is intentionally being kept unpatched, potentially allowing attackers to exploit unpatched vulnerabilities and gain unauthorized access or control. how_to_implement = To successfully implement this search, it requires that the 'Update' data model is being populated. This can be accomplished by ingesting Windows events or the Windows Update log via a universal forwarder on the Windows endpoints you wish to monitor. The Windows add-on should be also be installed and configured to properly parse Windows events in Splunk. There may be other data sources which can populate this data model, including vulnerability management systems. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = None identified @@ -94,7 +94,7 @@ providing_technologies = null type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies an authentication attempt event against an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +explanation = The following analytic identifies failed authentication attempts during the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication datamodel to detect specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This activity is significant as it may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} known_false_positives = A user may have accidentally entered the wrong credentials during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. Ensure that the user is aware of the MFA process and has the correct credentials. @@ -104,7 +104,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational. +explanation = The following analytic identifies modifications to Okta Identity Provider (IDP) lifecycle events, including creation, activation, deactivation, and deletion of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms. Unauthorized or anomalous changes could indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could manipulate authentication processes, potentially gaining unauthorized access or disrupting identity management systems. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]} known_false_positives = It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior. @@ -114,7 +114,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies patterns within Okta data to determine the amount of successful and failed pushes. Based on that, eval statements determine a finding of whether this is suspicious or not. The events are within a window of time and may be tuned as needed. +explanation = The following analytic detects patterns of successful and failed Okta MFA push attempts to identify potential MFA exhaustion attacks. It leverages Okta event logs, specifically focusing on push verification events, and uses statistical evaluations to determine suspicious activity. This activity is significant as it may indicate an attacker attempting to bypass MFA by overwhelming the user with push notifications. If confirmed malicious, this could lead to unauthorized access, compromising the security of the affected accounts and potentially the entire environment. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]} known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete. @@ -124,16 +124,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic. \ -For each Okta Verify Push challenge, the following two events are recorded in Okta System Log \ -Source of Push (Sign-In) \ -eventType eq \"system.push.send_factor_verify_push\" \ -User Push Response (Okta Verify client) \ -eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" \ -In sequence, the logic for the analytic - \ -* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) \ -* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. * Creates a ratio of successful sign-ins to pushes. \ -* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session. +explanation = The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed. @@ -143,7 +134,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +explanation = The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = Legitimate use case may require for users to disable MFA. Filter lightly and monitor for any unusual activity. @@ -153,7 +144,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts. +explanation = The following analytic detects multiple Okta accounts being locked out within a short period. It uses the user.account.lock event from Okta logs, aggregated over a 5-minute window, to identify this behavior. This activity is significant as it may indicate a brute force or password spraying attack, where an adversary attempts to guess passwords, leading to account lockouts. If confirmed malicious, this could result in potential account takeovers or unauthorized access to sensitive Okta accounts, posing a significant security risk. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]} known_false_positives = Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity. @@ -163,7 +154,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +explanation = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.AE"]} known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity. @@ -173,11 +164,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows: * Retrieves policy evaluation and SSO details in events that contain the Application requested \ -* Formats target fields so we can aggregate specifically on Applications (AppInstances) \ -* Groups by User, Session and IP \ -* Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies \ -* Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps. +explanation = The following analytic detects multiple failed attempts to access applications in Okta, potentially indicating the reuse of a stolen web session cookie. It leverages Okta logs to evaluate policy and SSO events, aggregating data by user, session, and IP. The detection triggers when more than half of the app sign-on attempts are unsuccessful across multiple applications. This activity is significant as it may indicate an attempt to bypass authentication mechanisms. If confirmed malicious, it could lead to unauthorized access to sensitive applications and data, posing a significant security risk. how_to_implement = This analytic is specific to Okta and requires Okta:im2 logs to be ingested. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550.004", "T1538"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on organization size and configuration of Okta. @@ -187,7 +174,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts. +explanation = The following analytic identifies instances where more than 10 unique user accounts have failed to authenticate from a single IP address within a 5-minute window in an Okta tenant. This detection uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to compromise multiple user accounts, potentially leading to unauthorized access to organizational resources and data breaches. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003"], "nist": ["DE.AE"]} known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. @@ -197,7 +184,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts. +explanation = The following analytic detects the creation of a new API token within an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to identify events where the `system.api_token.create` command is executed. This activity is significant because creating a new API token can indicate potential account takeover attempts or unauthorized access, allowing an adversary to maintain persistence. If confirmed malicious, this could enable attackers to execute API calls, access sensitive data, and perform administrative actions within the Okta environment. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.CM"]} known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. @@ -207,7 +194,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts. +explanation = The following analytic identifies when a new device is enrolled on an Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to detect the creation of new device enrollments. This activity is significant as it may indicate a legitimate user setting up a new device or an adversary adding a device to maintain unauthorized access. If confirmed malicious, this could lead to potential account takeover, unauthorized access, and persistent control over the compromised Okta account. Monitoring this behavior is crucial for detecting and mitigating unauthorized access attempts. how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} known_false_positives = It is possible that the user has legitimately added a new device to their account. Please verify this activity. @@ -217,7 +204,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Infrastructure confidence = medium -explanation = The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers. +explanation = The following analytic identifies failed user authentication attempts in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically looking for events where multi-factor authentication (MFA) fails with the reason "FastPass declined phishing attempt." This activity is significant as it indicates that attackers are targeting users with real-time phishing proxies, attempting to capture credentials. If confirmed malicious, this could lead to unauthorized access to user accounts, potentially compromising sensitive information and furthering lateral movement within the organization. how_to_implement = This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1556"], "nist": ["DE.CM"]} known_false_positives = Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed. @@ -227,7 +214,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user. +explanation = The following correlation identifies when a user exceeds a risk threshold based on multiple suspicious Okta activities. It leverages the Risk Framework from Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is significant as it highlights potentially compromised user accounts exhibiting multiple tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed malicious, this activity could indicate a serious security breach, allowing attackers to gain unauthorized access, escalate privileges, or persist within the environment. how_to_implement = This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories are enabled. TTPs may be set to Notables for point detections; anomalies should not be notables but rather risk generators. The correlation relies on risk before generating a notable. Modify the value as needed. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1110"], "nist": ["DE.AE"]} known_false_positives = False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization. @@ -237,7 +224,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search. +explanation = The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment. how_to_implement = This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.AE"]} known_false_positives = Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary. @@ -257,10 +244,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. A detection opportunity arises when an adversary attempts to reuse a stolen web session cookie. \ -* Retrieves policy evaluation events from successful authentication events. \ -* Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window. \ -* It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination. +explanation = The following analytic identifies suspicious use of a session cookie by detecting multiple client values (IP, User Agent, etc.) changing for the same Device Token associated with a specific user. It leverages policy evaluation events from successful authentication logs in Okta. This activity is significant as it may indicate an adversary attempting to reuse a stolen web session cookie, potentially bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized access to user accounts, leading to data breaches or further exploitation within the environment. how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1539"], "nist": ["DE.AE"]} known_false_positives = False positives may occur, depending on the organization's size and the configuration of Okta. @@ -270,7 +254,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Infrastructure confidence = medium -explanation = This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users. +explanation = The following analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on security.threat.detected events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture. how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.AE"]} known_false_positives = False positives may occur. It is recommended to fine-tune Okta settings and the analytic to ensure high fidelity. Adjust the risk score as necessary. @@ -280,7 +264,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment. +explanation = The following analytic identifies attempts by users to access Okta applications that have not been assigned to them. It leverages Okta Identity Management logs, specifically focusing on failed access attempts to unassigned applications. This activity is significant for a SOC as it may indicate potential unauthorized access attempts, which could lead to exposure of sensitive information or disruption of services. If confirmed malicious, such activity could result in data breaches, non-compliance with data protection laws, and overall compromise of the IT environment. how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]} known_false_positives = There is a possibility that a user may accidentally click on the wrong application, which could trigger this event. It is advisable to verify the location from which this activity originates. @@ -290,7 +274,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Okta Tenant confidence = medium -explanation = This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches. +explanation = The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment. how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1586.003"], "nist": ["DE.AE"]} known_false_positives = It is uncommon for a user to log in from multiple cities simultaneously, which may indicate a false positive. @@ -300,7 +284,7 @@ providing_technologies = ["Okta"] type = detection asset_type = Endpoint confidence = medium -explanation = On May 3rd, 2022, Splunk published a security advisory for a Path traversal in search parameter that can potentiall allow SPL injection. An attacker can cause the application to load data from incorrect endpoints, urls leading to outcomes such as running arbitrary SPL queries. +explanation = The following analytic identifies attempts at path traversal in search parameters, which can lead to SPL injection. It detects this activity by searching for specific patterns in the `_internal` index that indicate path traversal attempts (e.g., "../../../../"). This activity is significant for a SOC because it can allow an attacker to manipulate the application to load data from incorrect endpoints, potentially running arbitrary SPL queries. If confirmed malicious, this could lead to unauthorized data access, code execution, or further exploitation of the Splunk environment. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This search will provide search UI requests with path traversal parameter ("../../../../../../../../../") which shows exploitation attempts. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.CM"]} known_false_positives = This search may find additional path traversal exploitation attempts. @@ -310,7 +294,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it. +explanation = The following analytic identifies potential persistent Cross-Site Scripting (XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface views. It leverages audit logs from the `audit_searches` data source to detect actions involving Base64-encoded images in error messages. This activity is significant because it can allow attackers to inject malicious scripts that execute in the context of other users, leading to unauthorized actions or data exposure. If confirmed malicious, this could result in persistent control over the affected Splunk instance, compromising its integrity and confidentiality. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} known_false_positives = This is a hunting search, it will not deobfuscate base64 payload, it provides however it will provide what user added the view artifact and what user opened it. It will require further investigation based on the information presented by this hunting search. @@ -320,7 +304,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Identity confidence = medium -explanation = The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country. +explanation = The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data. how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated by users working out the geographic region where the organizations services or technology is hosted. @@ -330,7 +314,7 @@ providing_technologies = ["Ping ID"] type = detection asset_type = Identity confidence = medium -explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +explanation = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within a PingID environment. It triggers when 10 or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access, as the user might eventually accept the fraudulent request, compromising the security of the account and potentially the entire network. how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1621", "T1078", "T1110"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated by normal provisioning workflows for user device registration. @@ -340,7 +324,7 @@ providing_technologies = ["Ping ID"] type = detection asset_type = Identity confidence = medium -explanation = A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning. +explanation = The following analytic identifies the provisioning of a new MFA device shortly after a password reset. It detects this activity by correlating Windows Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating device pairing. This behavior is significant as it may indicate a social engineering attack where a threat actor impersonates a valid user to reset credentials and add a new MFA device. If confirmed malicious, this activity could allow an attacker to gain persistent access to the compromised account, bypassing traditional security measures. how_to_implement = Target environment must ingest Windows Event Log and PingID(PingOne) data sources. Specifically from logs from Active Directory Domain Controllers and JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated by normal provisioning workflows that generate a password reset followed by a device registration. @@ -370,7 +354,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Splunk drilldown vulnerability disclosure in Dashboard application that can potentially allow exposure of tokens from privilege users. An attacker can create dashboard and share it to privileged user (admin) and detokenize variables using external urls within dashboards drilldown function. +explanation = The following analytic identifies the presence of environment variables in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for specific patterns in the XML data. This activity is significant because it can expose sensitive tokens from privileged users if an attacker shares a malicious dashboard. If confirmed malicious, this could allow an attacker to detokenize variables and potentially gain unauthorized access to sensitive information or escalate privileges within the Splunk environment. how_to_implement = This search uses REST function to query for dashboards with environment variables present in URL options. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]} known_false_positives = This search may reveal non malicious URLs with environment variables used in organizations. @@ -390,7 +374,7 @@ providing_technologies = null type = detection asset_type = Splunk Server confidence = medium -explanation = This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG. +explanation = The following analytic identifies exposed authentication tokens in debug logs within Splunk Enterprise. It leverages logs from the `splunkd` component with a DEBUG log level, specifically searching for event messages that validate tokens. This activity is significant because exposed tokens can be exploited by attackers to gain unauthorized access to the Splunk environment. If confirmed malicious, this exposure could lead to unauthorized data access, privilege escalation, and potential compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability is crucial for maintaining the security and integrity of the Splunk deployment. how_to_implement = Requires access to internal Splunk indexes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1654"], "nist": ["DE.CM"]} known_false_positives = Only applies to affected versions of Splunk Enterprise below 9.2.1, 9.1.4, and 9.0.9 @@ -400,7 +384,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This hunting search provides information about a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can execute arbitrary code via the dashboard pdf generation component. Please review events with file=export in the _internal index for the potential targets of exploitation. +explanation = The following analytic identifies attempts to exploit a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, where an authenticated user can execute arbitrary code via the dashboard PDF generation component. It detects this activity by analyzing events in the _internal index with the file=export parameter. This behavior is significant because it indicates a potential code injection attack, which could lead to remote code execution (RCE). If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary commands, and potentially compromise the entire Splunk environment. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} known_false_positives = Not all exports and downloads are malicious, special attention must be put as well on /en-US/splunkd/__raw/services/pdfgen/render in the context of this search. @@ -410,7 +394,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies the use of the risky command - Delete - that may be utilized in Splunk to delete some or all data queried for. In order to use Delete in Splunk, one must be assigned the role. This is typically not used and should generate an anomaly if it is used. +explanation = The following analytic detects the use of the 'delete' command in Splunk, which can be used to remove queried data. This detection leverages the Splunk Audit data model, specifically monitoring ad-hoc searches containing the 'delete' command by non-system users. This activity is significant because the 'delete' command is rarely used and can indicate potential data tampering or unauthorized data removal. If confirmed malicious, this activity could lead to the loss of critical log data, hindering incident investigations and compromising the integrity of the monitoring environment. how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index. In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if this command is used as a common practice. Filter as needed. @@ -420,7 +404,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The Splunk platform contains built-in search processing language (SPL) safeguards to warn you when you are about to unknowingly run a search that contains commands that might be a security risk. This warning appears when you click a link or type a URL that loads a search that contains risky commands. The warning does not appear when you create ad hoc searches. This warning alerts you to the possibility of unauthorized actions by a malicious user. Unauthorized actions include - Copying or transferring data (data exfiltration), Deleting data and Overwriting data. All risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga. A possible scenario when this might occur is when a malicious actor creates a search that includes commands that exfiltrate or damage data. The malicious actor then sends an unsuspecting user a link to the search. The URL contains a query string (q) and a search identifier (sid), but the sid is not valid. The malicious actor hopes the user will use the link and the search will run. During analysis, pivot based on user name and filter any user or queries not needed. Queries ran from a dashboard are seen as adhoc queries. When a query runs from a dashboard it will not show in audittrail logs the source dashboard name. The query defaults to adhoc and no Splunk system user activity. In addition, modify this query by removing key commands that generate too much noise, or too little, and create separate queries with higher confidence to alert on. +explanation = The following analytic identifies the execution of risky commands within the Splunk platform, such as `runshellscript`, `delete`, and `sendemail`. It leverages the Search_Activity data model to detect ad hoc searches containing these commands, excluding those run by the splunk-system-user. This activity is significant because it may indicate attempts at data exfiltration, deletion, or other unauthorized actions by a malicious user. If confirmed malicious, this could lead to data loss, unauthorized data transfer, or system compromise, severely impacting the organization's security posture. how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index. In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives will be present until properly filtered by Username and search name. @@ -430,7 +414,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = This detection utilizes machine learning model named "risky_command_abuse" trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline". It should be scheduled to run hourly to detect whether a user has run searches containing risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga with abnormally long running time in the past one hour, comparing with his/her past seven days history. This search uses the trained baseline to infer whether a search is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0) +explanation = The following analytic identifies the execution of risky SPL commands with abnormally long run times by leveraging a machine learning model named "risky_command_abuse." It uses the Splunk Audit data model to compare current search activities against a baseline of the past seven days. This activity is significant for a SOC as it can indicate potential misuse or abuse of powerful SPL commands, which could lead to unauthorized data access or system manipulation. If confirmed malicious, this activity could allow an attacker to execute arbitrary scripts, delete data, or exfiltrate sensitive information. how_to_implement = This detection depends on MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Baseline model needs to be built using "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline" before this search can run. Please note that the current search only finds matches exactly one space between separator bar and risky commands. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = If the run time of a search exceeds the boundaries of outlier defined by the fitted density function model, false positives can occur, incorrectly labeling a long running search as potentially risky. @@ -440,7 +424,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability. +explanation = The following analytic identifies attempts to exploit a cross-site request forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client endpoint. It detects GET requests to the vulnerable endpoint using internal index data, focusing on specific URI paths and HTTP methods. This activity is significant because it can allow unauthorized updates to SSG KV store collections, potentially leading to data manipulation or unauthorized access. If confirmed malicious, this could enable attackers to alter critical configurations or exfiltrate sensitive information, compromising the integrity and security of the Splunk environment. how_to_implement = Requires access to internal index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} known_false_positives = This hunting search only applies to the affected versions and setup mentioned in the description of this search, it does not extract payload so it requires manual investigation after executing search. This search will produce false positives. @@ -450,7 +434,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This hunting search allows operator to discover attempts to exfiltrate data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires the attacker to compel a victim to initiate a request within their browser (phishing). The attacker cannot exploit the vulnerability at will. +explanation = The following analytic identifies attempts to exfiltrate data by executing a prepositioned malicious search ID in Splunk's Analytic Workspace. It leverages the `audit_searches` data source to detect suspicious `mstats` commands indicative of injection attempts. This activity is significant as it may indicate a phishing-based attack where an attacker compels a victim to initiate a malicious request, potentially leading to unauthorized data access. If confirmed malicious, this could result in significant data exfiltration, compromising sensitive information and impacting the organization's security posture. how_to_implement = The vulnerability affects only instances with Splunk Web Enabled. After running this search, please run "Splunk Command and Scripting Interpreter Risky SPL MLTK" to gain more insight into potentially risky commands which could lead to data exfiltration. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"]} known_false_positives = This search may produce false positives. This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. Special attention must be paid to "/en-US/app/search/analytics_workspace?sid=[sid]" which is where the malicious code will be inserted to trigger attack at victim. @@ -460,7 +444,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = This search will check the TLS validation is properly configured on the search head it is run from as well as its search peers after Splunk version 9. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +explanation = The following analytic identifies improper TLS validation configuration on Splunk search heads and peers post version 9. It leverages REST API calls to retrieve server information and SSL configuration settings, checking fields like `sslVerifyServerCert` and `sslVerifyServerName`. This activity is significant for a SOC as improper TLS settings can expose the infrastructure to man-in-the-middle attacks and data breaches. If confirmed malicious, attackers could intercept or manipulate data, compromising the integrity and confidentiality of communications within the Splunk environment. how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]} known_false_positives = No known at this time. @@ -470,7 +454,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. In other circumstances, a client may be allowed to publish a forwarder bundle to other clients, which may allow for arbitrary code execution. The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as well. This is a great opportunity to configure TLS across the environment. This search looks for forwarders that are not using TLS and adds risk to those entities. +explanation = The following analytic identifies Splunk forwarder connections that are not using TLS encryption. It leverages data from the `splunkd` logs, specifically looking for connections where the `ssl` field is set to "false". This activity is significant because unencrypted connections can expose sensitive data and allow unauthorized access, posing a security risk. If confirmed malicious, an attacker could exploit this vulnerability to download or publish forwarder bundles, potentially leading to arbitrary code execution and further compromise of the environment. how_to_implement = This anomaly search looks for forwarder connections that are not currently using TLS. It then presents the source IP, the type of forwarder, and the version of the forwarder. You can also remove the "ssl=false" argument from the initial stanza in order to get a full list of all your forwarders that are sending data, and the version of Splunk software they are running, for audit purposes. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]} known_false_positives = None at this time @@ -480,7 +464,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang. +explanation = The following analytic detects a denial of service (DoS) attempt using a malformed SAML request targeting the /saml/acs REST endpoint in Splunk Enterprise versions lower than 9.0.6 and 8.2.12. It leverages `splunkd` logs, specifically looking for error messages containing "xpointer" in the `expr` field. This activity is significant because it can cause the Splunk daemon to crash or hang, disrupting service availability. If confirmed malicious, this attack could lead to prolonged downtime, impacting the organization's ability to monitor and respond to security events. how_to_implement = To run this search, you must have access to the _internal index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.AE"]} known_false_positives = This search will show false positives. The analyst must look for errors and a pointer indicating a malicious file. @@ -500,7 +484,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = On March 24th, 2022, Splunk published a security advisory for a possible Denial of Service stemming from the lack of validation in a specific key-value field in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation in patched versions of Splunk. +explanation = The following analytic identifies attempts to exploit a Denial of Service (DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread" and the message "Invalid _meta atom." This activity is significant as it targets a known vulnerability that could disrupt Splunk services. If confirmed malicious, this could lead to service outages, impacting the availability and reliability of Splunk for monitoring and analysis. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will only find attempted exploitation on versions of Splunk already patched for CVE-2021-3422. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.CM"]} known_false_positives = None. @@ -510,7 +494,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance. +explanation = The following analytic identifies the use of the `printf` SPL function in Splunk searches, which can be exploited for a denial of service (DoS) attack. It detects this activity by querying the `audit_searches` data source for specific patterns involving `makeresults`, `eval`, `fieldformat`, and `printf` functions, excluding searches by the `splunk_system_user`. This activity is significant because it targets a known vulnerability in Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, potentially disrupting the availability of the Splunk instance. If confirmed malicious, this could lead to service outages and impact the monitoring and logging capabilities of the organization. how_to_implement = This search requires the ability to search internal indexes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499.004"], "nist": ["DE.AE"]} known_false_positives = This search may produces false positives, analyst most focuse in the use of printf conversion function of eval to craft an expression that splunkd cannot interpret correctly causing it to crash. @@ -530,7 +514,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search allows operator to identify Splunk search app crashes resulting from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before crash. This search will provide Universal Forwarder errors from uploaded binary files (zip compression) which are used for this attack. If an analyst sees results from this search we suggest you investigate and triage what zip file was uploaded, zip compressed files may have different extensions. +explanation = The following analytic identifies crashes in the Splunk search app caused by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and 8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder error logs for specific messages indicating invalid or binary file issues. This activity is significant because it can disrupt Splunk operations, leading to potential data loss or monitoring gaps. If confirmed malicious, this attack could result in a denial of service, hindering the organization's ability to monitor and respond to other security incidents effectively. how_to_implement = Need to monitor Splunkd data from Universal Forwarders. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} known_false_positives = This search may reveal non malicious zip files causing errors as well. @@ -540,7 +524,7 @@ providing_technologies = null type = detection asset_type = Splunk Server confidence = medium -explanation = In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections. +explanation = The following analytic detects unauthorized attempts to reload Splunk KV Store collections via the REST API. It leverages internal index logs to identify POST requests to the `/servicesNS/nobody/search/admin/collections-conf/_reload` endpoint, focusing on status codes starting with '2'. This activity is significant as it may indicate improper permission handling, potentially leading to unauthorized deletion of KV Store collections. If confirmed malicious, this could result in data loss or unauthorized data manipulation, impacting the integrity and availability of critical Splunk data. how_to_implement = Requires access to internal indexes and REST API enabled instances. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]} known_false_positives = This is a hunting search and will produce false positives. Operator must follow results into instances where curl requests coming from actual users may indicate intent of exploitation. @@ -560,7 +544,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted. +explanation = The following analytic detects the creation of malformed Investigations in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` with error statuses during investigation creation. This activity is significant as it can disrupt the functionality of the Investigations manager, hindering incident response efforts. If confirmed malicious, this could prevent security teams from accessing critical investigation data, severely impacting their ability to manage and respond to security incidents effectively. how_to_implement = This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} known_false_positives = The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event. @@ -570,7 +554,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible. +explanation = The following analytic detects attempts to perform a denial of service (DoS) attack through investigation attachments in Splunk Enterprise Security (ES) versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` for error statuses related to investigation objects. This activity is significant because it can render the Investigation feature inaccessible, disrupting incident response and forensic analysis. If confirmed malicious, this attack could prevent security teams from effectively managing and investigating security incidents, leading to prolonged exposure and potential data breaches. how_to_implement = This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} known_false_positives = This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager. @@ -580,7 +564,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will. +explanation = The following analytic identifies attempts to exploit an HTTP response splitting vulnerability via the rest SPL command in Splunk. It detects this activity by analyzing audit logs for specific search commands that include REST methods like POST, PUT, PATCH, or DELETE. This behavior is significant because it indicates a potential attempt to access restricted REST endpoints, which could lead to unauthorized access to sensitive information. If confirmed malicious, this activity could allow an attacker to access restricted content, such as password files, by injecting commands into HTTP requests. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This search may assist in detecting possible http response splitting exploitation attemptss. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.006"], "nist": ["DE.AE"]} known_false_positives = This search may have produce false positives as malformed or erroneous requests made to this endpoint may be executed willingly or erroneously by operators. @@ -610,7 +594,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search will enumerate all Splunk Accounts with administrative rights on this instance. It deliberately ignores the default admin account since this is assumed to be present. This search may help in a detection the Cross-Site Scripting Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. +explanation = The following analytic identifies nonstandard Splunk accounts with administrative rights on the instance, excluding the default admin account. It uses REST API calls to retrieve user data and filters for accounts with admin capabilities. This activity is significant as unauthorized admin accounts can indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could leverage these accounts to execute commands, escalate privileges, or persist within the environment, posing a significant risk to the integrity and security of the Splunk instance. how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures. If there have been admin account, in addition to the standard admin account, intentionally created on this server, then edit the filter macro to exclude them. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = It is not possible to discern from the user table whether or not users with admin rights have been created intentionally, accidentally, or as a result of exploitation. Each user with these rights should be investigated and, if legitimate, added to the filter macro above. If a user is not believed to be legitimate, then further investigation should take place. @@ -620,7 +604,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance. +explanation = The following analytic identifies low-privilege users attempting to view hashed Splunk passwords by querying the conf-user-seed REST endpoint. It leverages data from the `splunkd_web` logs, specifically monitoring access to the conf-user-seed endpoint. This activity is significant because it can indicate an attempt to escalate privileges by obtaining hashed credentials, potentially leading to admin account takeover. If confirmed malicious, this could allow an attacker to gain administrative control over the Splunk instance, compromising the entire environment's security. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover attempts to access con-user-seed file content. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.AE"]} known_false_positives = This search may produce false positives as accounts with high privileges may access this file. Operator will need to investigate these actions in order to discern exploitation attempts. @@ -630,7 +614,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance. +explanation = The following analytic identifies path traversal attempts in the Splunk App for Lookup File Editing. It detects specially crafted web requests targeting lookup files by analyzing the `uri_query` field in the `_internal` index. This activity is significant because it allows low-privilege users to read and write to restricted areas of the Splunk installation directory, potentially accessing sensitive files like password hashes. If confirmed malicious, this could lead to unauthorized access, data breaches, and further exploitation of the Splunk environment. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.AE"]} known_false_positives = This search may find additional path traversal exploitation attempts or malformed requests. @@ -640,7 +624,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user. The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone. +explanation = The following analytic detects attempts to bypass URL validation in Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13 by targeting the vulnerable bootstrap version 2.3.1. It leverages `splunkd_web` logs, specifically monitoring GET requests to JavaScript files within the vulnerable bootstrap path. This activity is significant as it can allow a low-privileged user to perform path traversal, potentially accessing restricted and confidential information. If confirmed malicious, this could lead to unauthorized data access and compromise of sensitive information, including targeting admin users. how_to_implement = This search does not require additional data to be ingested. This search requires ability to search _internal index. This search helps discover access to vulnerable bootstrap versions. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = This search will produce numerous false positives as it shows ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files occur during normal Splunk usage. To reduce or eliminate false positives, update the a version of Splunk which has addressed the vulnerability. @@ -650,7 +634,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. This hunting search pulls a full list of forwarder bundle downloads where the peer column is the forwarder, the host column is the Deployment Server, and then you have a list of the apps downloaded and the serverclasses in which the peer is a member of. You should look for apps or clients that you do not recognize as being part of your environment. +explanation = The following analytic identifies unauthorized forwarder bundle downloads from Splunk Deployment Servers. It leverages native Splunk logs, specifically the `splunkd` component "PackageDownloadRestHandler," to detect instances where an unauthenticated client may have downloaded forwarder bundles. This activity is significant because it could indicate a potential security breach, allowing unauthorized access to sensitive configurations and applications. If confirmed malicious, an attacker could gain insights into the deployment server's environment, potentially leading to further exploitation or lateral movement within the network. how_to_implement = This hunting search uses native logs produced when a deployment server is within your environment. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]} known_false_positives = None at this time. @@ -660,7 +644,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = On June 14th, 2022, Splunk released a security advisory relating to TLS validation occuring within the httplib and urllib python libraries shipped with Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration settings need to be set. This search will check those configurations on the search head it is run from as well as its search peers. In addition to these settings, the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be enabled as well. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +explanation = The following analytic identifies weak encryption configurations in Splunk related to TLS validation within the httplib and urllib Python libraries. It uses REST API calls to check specific configuration settings on the search head and its peers, ensuring compliance with security advisories. This activity is significant for a SOC as weak encryption can be exploited for protocol impersonation attacks, leading to unauthorized access. If confirmed malicious, attackers could intercept and manipulate data, compromising the integrity and confidentiality of the Splunk environment. how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (The `dispatch_rest_to_indexers` capability). Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1001.003"], "nist": ["DE.AE"]} known_false_positives = While all of the settings on each device returned by this search may appear to be hardened, you will still need to verify the value of PYTHONHTTPSVERIFY in $SPLUNK_HOME/etc/splunk-launch.conf on each device in order to harden the python configuration. @@ -700,7 +684,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use of the 'collect' SPL command which writes a file within the Splunk Enterprise installation. The attacker can then use this file to submit a serialized payload that can result in execution of code within the payload. Please refer to the following URL for additional information on these disclosures - https://advisory.splunk.com +explanation = The following analytic detects the execution of a specially crafted query using the 'collect' SPL command in Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1. It leverages audit logs to identify searches containing both 'makeresults' and 'collect' commands. This activity is significant because it can indicate an attempt to serialize untrusted data, potentially leading to arbitrary code execution. If confirmed malicious, this could allow an attacker to execute code within the Splunk environment, leading to unauthorized access and control over the system. how_to_implement = Requires access to the _audit index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} known_false_positives = There are numerous many uses of the 'makeresults' and 'collect' SPL commands. Please evaluate the results of this search for potential abuse. @@ -710,7 +694,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = This hunting search provides information on possible exploitation attempts against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0, 8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands remotely through the use of specially crafted requests to the mobile alerts feature in the Splunk Secure Gateway app. +explanation = The following analytic identifies potential exploitation attempts against the Splunk Secure Gateway App's Mobile Alerts feature in Splunk versions 9.0, 8.2.x, and 8.1.x. It detects suspicious activity by monitoring requests to the mobile alerts endpoint using specific URI paths and query parameters. This activity is significant because an authenticated user could exploit this vulnerability to execute arbitrary operating system commands remotely. If confirmed malicious, this could lead to unauthorized code execution, compromising the integrity and security of the Splunk environment. how_to_implement = This search only applies if Splunk Mobile Gateway is deployed in the vulnerable Splunk versions. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} known_false_positives = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. Focus of this search is "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" which is the injection point. @@ -740,7 +724,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function. +explanation = The following analytic identifies attempts to exploit a reflected cross-site scripting (XSS) vulnerability on the app search table endpoint in Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12. It detects this activity by analyzing web request logs for specific dataset commands (`makeresults`, `count`, `eval`, `baseSPL`) within the `splunkd_web` index. This activity is significant because successful exploitation can lead to the execution of arbitrary commands on the Splunk platform, potentially compromising the entire instance. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, and manipulate data within the Splunk environment. how_to_implement = Need access to the internal indexes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = This search will produce false positives. It is necessary to also look at uri_query parameter to determine the possible malicious intention of inserting makeresults within the uri string. @@ -760,7 +744,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent cross site scripting via Data Model object name. An authenticated user can inject and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) in the object name Data Model. +explanation = The following analytic identifies attempts to exploit a stored cross-site scripting (XSS) vulnerability in Splunk Enterprise via the Data Model object name field. It detects this activity by analyzing web access logs (`splunkd_webx`) for specific URI patterns and non-null query parameters. This activity is significant because it allows authenticated users to inject and store malicious scripts, leading to persistent XSS attacks. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of other users, potentially leading to data theft, session hijacking, or further compromise of the Splunk environment. how_to_implement = This vulnerability only affects Splunk Web enabled instances. This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = This search may produce false positives and does not cover exploitation attempts via code obfuscation, focus of search is suspicious requests against "/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model" which is the injection point. @@ -770,7 +754,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server. +explanation = The following analytic identifies potential log injection attempts into the Splunk server via specially crafted web URLs. It detects ANSI escape codes within the `uri_path` field of `splunkd_webx` logs. This activity is significant as it can lead to log file manipulation, potentially obfuscating malicious actions or misleading analysts. If confirmed malicious, an attacker could manipulate log files to hide their tracks or execute further attacks, compromising the integrity of the logging system and making incident response more challenging. how_to_implement = This only affects web enabled Splunk instances. The detection does require the ability to search the _internal index. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} known_false_positives = This hunting search will produce false positives if ANSI escape characters are included in URLs either voluntarily or by accident. This search will not detect obfuscated ANSI characters. @@ -780,7 +764,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads. +explanation = The following analytic identifies user activity related to uploading lookup tables with unnecessary filename extensions in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods (POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This behavior is significant because it can indicate attempts to upload potentially malicious files disguised as lookup tables. If confirmed malicious, this activity could allow an attacker to execute unauthorized code or manipulate data within the Splunk environment, leading to potential data breaches or system compromise. how_to_implement = Requires access to internal splunkd_access. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} known_false_positives = This is a hunting search, the search provides information on upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary after executing search. This search will produce false positives as payload cannot be directly discerned. @@ -790,7 +774,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = On May 3rd, 2022, Splunk published a security advisory for username enumeration stemming from verbose login failure messages present on some REST endpoints. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +explanation = The following analytic identifies attempts to enumerate usernames in Splunk by detecting multiple failed authentication attempts from the same source. It leverages data from the `_audit` index, specifically focusing on failed authentication events. This activity is significant for a SOC because it can indicate an attacker trying to discover valid usernames, which is a precursor to more targeted attacks like password spraying or brute force attempts. If confirmed malicious, this activity could lead to unauthorized access, compromising the security of the Splunk environment and potentially exposing sensitive data. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to find password spraying or brute force authorization attempts in addition to someone enumerating usernames. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]} known_false_positives = Automation executing authentication attempts against your Splunk infrastructure with outdated credentials may cause false positives. @@ -800,7 +784,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2. The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment. +explanation = The following analytic identifies potential exploitation of a Cross-Site Scripting (XSS) vulnerability in Splunk Enterprise 9.1.2. It detects suspicious requests to the Splunk web GUI that may execute JavaScript within script tags. This detection leverages logs from the `splunkd_ui` data source, focusing on specific URI paths and HTTP methods. This activity is significant as it can allow attackers to execute arbitrary JavaScript, potentially accessing the API with the logged-in user's permissions. If the user is an admin, the attacker could create an admin account, leading to full control over the Splunk environment. how_to_implement = This search only applies to web-GUI-enabled Splunk instances and operator must have access to internal indexes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = This is a hunting search and will produce false positives as it is not possible to view contents of a request payload. It shows the artifact resulting from a potential exploitation payload (the creation of a user with admin privileges). @@ -810,7 +794,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = On May 3rd, 2022, Splunk published a security advisory for a reflective Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation in the Distributed Monitoring Console app. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +explanation = The following analytic identifies attempts to exploit a reflective Cross-Site Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app. It detects GET requests with suspicious query parameters by analyzing `splunkd_web` logs in the _internal index. This activity is significant because it targets a known vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts in the context of the user's browser. If confirmed malicious, this could lead to unauthorized actions, data theft, or further compromise of the Splunk environment. how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will find attempted exploitation of CVE-2022-27183. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} known_false_positives = Use of the monitoring console where the less-than sign (<) is the first character in the description field. @@ -820,7 +804,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = This is a hunting search to find persistent cross-site scripting XSS code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise (8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code that can lead to persistent cross site scripting. +explanation = The following analytic identifies persistent cross-site scripting (XSS) attempts in the 'Save Table' dialog on the Splunk search page. It detects POST requests to the endpoint `/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model` containing potential XSS payloads. This activity is significant because it can allow a remote user with the "power" role to inject malicious scripts, leading to persistent XSS vulnerabilities. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of the affected user, potentially leading to data theft, session hijacking, or further exploitation within the Splunk environment. how_to_implement = Watch for POST requests combined with XSS script strings or obfuscation against the injection point /en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = If host is vulnerable and XSS script strings are inputted they will show up in search. Not all Post requests are malicious as they will show when users create and save dashboards. This search may produce several results with non malicious POST requests. Only affects Splunk Web enabled instances. @@ -830,7 +814,7 @@ providing_technologies = ["Splunk Internal Logs"] type = detection asset_type = Endpoint confidence = medium -explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. This hunting search shows users action, application and role used for creating views related to this vulnerability. +explanation = The following analytic identifies potential Cross-Site Scripting (XSS) attempts via the 'layoutPanel' attribute in the 'module' tag within XML Views in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It leverages internal logs from "splunk_web_service" and "splunk_python" sourcetypes, focusing on messages containing "loadParams." This activity is significant as it can lead to unauthorized script execution within the Splunk Web interface, potentially compromising the security of the instance. If confirmed malicious, attackers could execute arbitrary scripts, leading to data theft, session hijacking, or further exploitation of the Splunk environment. how_to_implement = This data is collected by default in Splunk. Upon first enabling this rule, a number of errors may be observed. Those that are due to improperly formatted, but non-nefarious, XML views should be be remedied in the corresponding view. Please take care investigating potential XSS as accessing an affected page could retrigger the exploit. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} known_false_positives = The error detected above can be generated for a wide variety of improperly formatted XML views. There will be false positives as the search cannot extract the malicious payload and the view should be manually investigated. @@ -840,7 +824,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack. +explanation = The following analytic detects emails containing attachments with suspicious file extensions. It leverages the Email data model in Splunk, using the tstats command to identify emails where the attachment filename is not empty. This detection is significant for SOC analysts as it highlights potential phishing or malware delivery attempts, which are common vectors for data breaches and malware infections. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, system compromise, or data exfiltration. Immediate review and analysis of the identified emails and attachments are crucial to mitigate these risks. how_to_implement = You need to ingest data from emails. Specifically, the sender's address and the file names of any attachments must be mapped to the Email data model. \ **Splunk Phantom Playbook Integration** \ If Splunk Phantom is also configured in your environment, a Playbook called "Suspicious Email Attachment Investigate and Delete" can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, and add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search. The notable event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox.' @@ -862,7 +846,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack. +explanation = The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.CM"]} known_false_positives = Some of these processes may be used legitimately on web servers during maintenance or other administrative tasks. @@ -882,7 +866,7 @@ providing_technologies = null type = detection asset_type = Cloud Instance confidence = medium -explanation = This search finds for the number successfully destroyed cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +explanation = The following analytic identifies an abnormally high number of cloud instances being destroyed within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to detect outliers. This activity is significant for a SOC because a sudden spike in destroyed instances could indicate malicious activity, such as an insider threat or a compromised account attempting to disrupt services. If confirmed malicious, this could lead to significant operational disruptions, data loss, and potential financial impact due to the destruction of critical cloud resources. how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Destroyed` to create the probability density function. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]} known_false_positives = Many service accounts configured within a cloud infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user. @@ -892,7 +876,7 @@ providing_technologies = null type = detection asset_type = Cloud Instance confidence = medium -explanation = This search finds for the number successfully created cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +explanation = The following analytic detects an abnormally high number of cloud instances launched within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to identify outliers based on historical data. This activity is significant for a SOC because a sudden spike in instance creation could indicate unauthorized access or misuse of cloud resources. If confirmed malicious, this behavior could lead to resource exhaustion, increased costs, or provide attackers with additional compute resources to further their objectives. how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Launched` to create the probability density function. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]} known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user. @@ -922,7 +906,7 @@ providing_technologies = null type = detection asset_type = Amazon EKS Kubernetes cluster Pod confidence = medium -explanation = The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action. Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts. +explanation = The following analytic detects unauthenticated requests made against the Kubernetes Pods API, indicating potential unauthorized access attempts. It leverages the `aws_cloudwatchlogs_eks` data source, filtering for events where `user.username` is "system:anonymous", `verb` is "list", and `objectRef.resource` is "pods", with `requestURI` set to "/api/v1/pods". This activity is significant as it may signal attempts to access sensitive resources or execute unauthorized commands within the Kubernetes environment. If confirmed malicious, such access could lead to data compromise, unauthorized command execution, or lateral movement within the cluster. how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on forAWS (version 4.4.0 or later), then configure your AWS CloudWatch EKS Logs.Please also customize the `kubernetes_pods_aws_scan_fingerprint_detection` macro to filter out the false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]} known_false_positives = Not all unauthenticated requests are malicious, but frequency, UA and source IPs and direct request to API provide context. @@ -932,7 +916,7 @@ providing_technologies = null type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +explanation = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute span. This detection leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` API call, to identify multiple IP addresses associated with the same user session. This behavior is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this activity could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.AE"]} known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -942,7 +926,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks, making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts. +explanation = The following analytic detects AWS `DeleteTrail` events within CloudTrail logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema Framework (OCSF) format to identify when a CloudTrail is deleted. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate with stealth. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and investigate other potential compromises within the AWS environment. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity. @@ -952,7 +936,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs. This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch. By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities, hindering incident response and forensics efforts. +explanation = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant because attackers may delete log groups to evade detection and disrupt logging capabilities, hindering incident response efforts. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to undetected data breaches or further malicious actions within the compromised AWS environment. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity. @@ -962,7 +946,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects the deletion of critical AWS Security Services configurations through specific API calls to services like CloudWatch, GuardDuty, and Web Application Firewalls. By monitoring for these deletion actions, the analytic aims to identify attempts by adversaries to undermine security defenses, such as erasing logging configurations or removing detection mechanisms. This behavior is crucial for a Security Operations Center (SOC) to identify as it can indicate an attacker's intent to operate undetected by eliminating evidence of their presence and activities. The impact of such attacks is significant, potentially leaving the environment vulnerable to further exploitation without any traceable logs or alerts. +explanation = The following analytic detects the deletion of critical AWS Security Services configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages Amazon Security Lake logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because adversaries often use these actions to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, leading to potential data breaches, unauthorized access, and prolonged persistence within the AWS environment. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. @@ -1012,7 +996,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects the deletion of an AWS policy, a critical action that could indicate an attempt to alter permissions or reduce security controls. By monitoring AWS logs for `DeletePolicy` events, this analytic identifies both successful and attempted deletions, providing insights into potentially malicious activities. Identifying such behavior is crucial for a Security Operations Center (SOC) as it may signal an adversary's effort to escalate privileges or evade detection. The impact of unauthorized policy deletion is significant, potentially leading to compromised accounts or data exposure. +explanation = The following analytic identifies when a policy is deleted in AWS. It leverages Amazon Security Lake logs to detect the DeletePolicy API operation. Monitoring policy deletions is crucial as it can indicate unauthorized attempts to weaken security controls. If confirmed malicious, this activity could allow an attacker to remove critical security policies, potentially leading to privilege escalation or unauthorized access to sensitive resources. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only. @@ -1042,7 +1026,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with less risk of detection, facilitating further malicious activities. +explanation = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. This activity is significant as disabling MFA can indicate an adversary attempting to weaken account security to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, potentially leading to unauthorized access to sensitive resources and prolonged compromise. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company @@ -1052,7 +1036,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects when a new Multi-Factor Authentication (MFA) method is registered for an AWS account, as logged through Amazon Security Lake (ASL). This behavior is detected by monitoring ASL logs for specific API calls associated with MFA registration. Identifying this activity is crucial for a Security Operations Center (SOC) because unauthorized registration of a new MFA method can indicate an adversary's attempt to establish or maintain access to a compromised account. The impact of such an attack is significant as it can enable persistent access for the attacker, potentially leading to further compromise and exploitation of cloud resources. +explanation = The following analytic identifies the registration of a new Multi-Factor Authentication (MFA) method for an AWS account, as logged through Amazon Security Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` API operation within ASL logs. This behavior is significant because adversaries who gain unauthorized access to an AWS account may register a new MFA method to maintain persistence. If confirmed malicious, this activity could allow attackers to secure their access, making it harder to detect and remove their presence from the compromised environment. how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. @@ -1062,7 +1046,7 @@ providing_technologies = ["Amazon Security Lake"] type = detection asset_type = EC2 Snapshot confidence = medium -explanation = This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs. +explanation = The following analytic detects suspicious modifications to AWS AMI attributes, such as sharing an AMI with another AWS account or making it publicly accessible. It leverages AWS CloudTrail logs to identify these changes by monitoring specific API calls. This activity is significant because adversaries can exploit these modifications to exfiltrate sensitive data stored in AWS resources. If confirmed malicious, this could lead to unauthorized access and potential data breaches, compromising the confidentiality and integrity of organizational information. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with others for a specific purpose. @@ -1072,7 +1056,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +explanation = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute window. It leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` event, to detect this behavior. This activity is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation within the AWS environment. how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -1082,7 +1066,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an authentication attempt event against an AWS Console that fails during the Multi Factor Authentication challenge. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +explanation = The following analytic identifies failed authentication attempts to the AWS Console during the Multi-Factor Authentication (MFA) challenge. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect when MFA was used but the login attempt still failed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials but being thwarted by MFA. If confirmed malicious, this could suggest an ongoing attempt to breach the account, potentially leading to unauthorized access and further attacks if MFA is bypassed. how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.CM"]} known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. @@ -1092,7 +1076,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account. +explanation = The following analytic identifies the creation of a new AWS IAM policy version that allows access to all resources. It detects this activity by analyzing AWS CloudTrail logs for the CreatePolicyVersion event with a policy document that grants broad permissions. This behavior is significant because it violates the principle of least privilege, potentially exposing the environment to misuse or abuse. If confirmed malicious, an attacker could gain extensive access to AWS resources, leading to unauthorized actions, data exfiltration, or further compromise of the AWS environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources and you must verify this activity. @@ -1102,7 +1086,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed manual during threat hunting. +explanation = The following analytic identifies the creation of AWS IAM access keys by a user for another user, which can indicate privilege escalation. It leverages AWS CloudTrail logs to detect instances where the user creating the access key is different from the user for whom the key is created. This activity is significant because unauthorized access key creation can allow attackers to establish persistence or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized access to AWS services, data exfiltration, and long-term persistence in the environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user. @@ -1112,7 +1096,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip +explanation = The following analytic identifies the creation of a login profile for one AWS user by another, followed by a console login from the same source IP. It uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` events based on the source IP and user identity. This activity is significant as it may indicate privilege escalation, where an attacker creates a new login profile to gain unauthorized access. If confirmed malicious, this could allow the attacker to escalate privileges and maintain persistent access to the AWS environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a login profile for another user. @@ -1122,7 +1106,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = It shows that there have been an unsuccessful attempt to log in using the user identity to the AWS management console. Since the user identity has access to AWS account services and resources, an attacker might try to brute force the password for that identity. +explanation = The following analytic identifies unsuccessful login attempts to the AWS Management Console using a specific user identity. It leverages AWS CloudTrail logs to detect failed authentication events associated with the AWS ConsoleLogin action. This activity is significant for a SOC because repeated failed login attempts may indicate a brute force attack or unauthorized access attempts. If confirmed malicious, an attacker could potentially gain access to AWS account services and resources, leading to data breaches, resource manipulation, or further exploitation within the AWS environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.001"], "nist": ["DE.CM"]} known_false_positives = Users may genuinely mistype or forget the password. @@ -1142,7 +1126,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like Credit card information, PII, Health care Data. This event should be investigated further. +explanation = The following analytic detects the resetting of the master user password for an Amazon RDS DB instance. It leverages AWS CloudTrail logs to identify events where the `ModifyDBInstance` API call includes a new `masterUserPassword` parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, such as credit card information, PII, and healthcare data. If confirmed malicious, this could lead to data breaches, regulatory non-compliance, and significant reputational damage. Immediate investigation is required to determine the legitimacy of the password reset. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = Users may genuinely reset the RDS password. @@ -1162,7 +1146,7 @@ providing_technologies = null type = detection asset_type = AWS Account confidence = medium -explanation = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment. +explanation = The following analytic detects the deletion of AWS CloudTrail logs by identifying `DeleteTrail` events within CloudTrail logs. This detection leverages CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those initiated from the AWS console. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to prolonged unauthorized access and further exploitation. how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity. @@ -1172,7 +1156,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment. +explanation = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This detection leverages CloudTrail data to monitor for successful log group deletions, excluding console-based actions. This activity is significant as it indicates potential attempts to evade logging and monitoring, which is crucial for maintaining visibility into AWS activities. If confirmed malicious, this could allow attackers to hide their tracks, making it difficult to detect further malicious actions or investigate incidents within the compromised AWS environment. how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity. @@ -1182,7 +1166,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic looks for several delete specific API calls made to AWS Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These API calls are often leveraged by adversaries to weaken existing security defenses by deleting logging configurations in the CloudWatch alarm, delete a set of detectors from your Guardduty environment or simply delete a bunch of CloudWatch alarms to remain stealthy and avoid detection. +explanation = The following analytic detects attempts to delete critical AWS security service configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages CloudTrail logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because it indicates potential efforts to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, escalate privileges, or exfiltrate data without triggering security alerts, severely compromising the security posture of the AWS environment. how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. @@ -1192,7 +1176,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic identifies `PutBucketLifecycle` events in CloudTrail logs where a user has created a new lifecycle rule for an S3 bucket with a short expiration period. Attackers may use this API call to impair the CloudTrail logging by removing logs from the S3 bucket by changing the object expiration day to 1 day, in which case the CloudTrail logs will be deleted. +explanation = The following analytic detects `PutBucketLifecycle` events in AWS CloudTrail logs where a user sets a lifecycle rule for an S3 bucket with an expiration period of fewer than three days. This detection leverages CloudTrail logs to identify suspicious lifecycle configurations. This activity is significant because attackers may use it to delete CloudTrail logs quickly, thereby evading detection and impairing forensic investigations. If confirmed malicious, this could allow attackers to cover their tracks, making it difficult to trace their actions and respond to the breach effectively. how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. We recommend our users to set the expiration days value according to your company's log retention policies. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. @@ -1202,7 +1186,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their macliious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may easily stop logging. +explanation = The following analytic detects `StopLogging` events in AWS CloudTrail logs. It leverages CloudTrail event data to identify when logging is intentionally stopped, excluding console-based actions and focusing on successful attempts. This activity is significant because adversaries may stop logging to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to perform further activities without being logged, hindering incident response and forensic investigations, and potentially leading to unauthorized access or data exfiltration. how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudtrail logging. Please investigate this activity. @@ -1212,7 +1196,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers may evade the logging capability by updating the settings and impairing them with wrong parameters. For example, Attackers may change the multi-regional log into a single region logs, which evades the logging for other regions. When the adversary has the right type of permissions in the compromised AWS environment, they may update the CloudTrail settings that is logging activities in your environment. +explanation = The following analytic detects `UpdateTrail` events in AWS CloudTrail logs. It identifies attempts to modify CloudTrail settings, potentially to evade logging. The detection leverages CloudTrail logs, focusing on `UpdateTrail` events where the user agent is not the AWS console and the operation is successful. This activity is significant because altering CloudTrail settings can disable or limit logging, hindering visibility into AWS account activities. If confirmed malicious, this could allow attackers to operate undetected, compromising the integrity and security of the AWS environment. how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has updated cloudtrail logging. Please investigate this activity. @@ -1242,7 +1226,7 @@ providing_technologies = null type = detection asset_type = AWS Account confidence = medium -explanation = This search provides detection of role creation by IAM users. Role creation is an event by itself if user is creating a new role with trust policies different than the available in AWS and it can be used for lateral movement and escalation of privileges. +explanation = The following analytic identifies the creation of new IAM roles by users in AWS. It leverages CloudWatch logs to detect events where the `CreateRole` action is performed, focusing on roles with specific trust policies. This activity is significant as unauthorized role creation can facilitate lateral movement and privilege escalation within the AWS environment. If confirmed malicious, attackers could gain elevated permissions, potentially compromising sensitive resources and data. how_to_implement = You must install splunk AWS add-on and Splunk App for AWS. This search works with cloudwatch logs annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = CreateRole is not very common in common users. This search can be adjusted to provide specific values to identify cases of abuse. In general AWS provides plenty of trust policies that fit most use cases. @@ -1272,7 +1256,7 @@ providing_technologies = null type = detection asset_type = AWS Account confidence = medium -explanation = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company. +explanation = The following analytic detects the creation of AWS KMS keys with an encryption policy accessible to everyone, including external entities. It leverages AWS CloudTrail logs to identify `CreateKey` or `PutKeyPolicy` events where the `kms:Encrypt` action is granted to all principals. This activity is significant as it may indicate a compromised account, allowing an attacker to misuse the encryption key to target other organizations. If confirmed malicious, this could lead to unauthorized data encryption, potentially disrupting operations and compromising sensitive information across multiple entities. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -1292,7 +1276,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic detects AWS CloudTrail events where bucket versioning is suspended by a user. Versioning allows the AWS Administrators to maintain different version of the S3 bucket which can be used to recover deleted data. Adversaries have leveraged this technique in the wild during a ransomware incident to disable versioning so the client cannot recover the data. +explanation = The following analytic detects when AWS S3 bucket versioning is suspended by a user. It leverages AWS CloudTrail logs to identify `PutBucketVersioning` events with the `VersioningConfiguration.Status` set to `Suspended`. This activity is significant because disabling versioning can prevent recovery of deleted or modified data, which is a common tactic in ransomware attacks. If confirmed malicious, this action could lead to data loss and hinder recovery efforts, severely impacting data integrity and availability. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.AE"]} known_false_positives = It is possible that an AWS Administrator has legitimately disabled versioning on certain buckets to avoid costs. @@ -1342,7 +1326,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done during business hours. When done outside business hours, we want to take a look into it. +explanation = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) outside of standard business hours. It leverages AWS CloudTrail logs to identify `PutImage` events occurring between 8 PM and 8 AM or on weekends. This activity is significant because container uploads outside business hours can indicate unauthorized or suspicious activity, potentially pointing to a compromised account or insider threat. If confirmed malicious, this could allow an attacker to deploy unauthorized or malicious containers, leading to potential data breaches or service disruptions. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} known_false_positives = When your development is spreaded in different time zones, applying this rule can be difficult. @@ -1352,7 +1336,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done from only a few known users. When the user was never seen before, we should have a closer look into the event. +explanation = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) by an unknown user. It leverages AWS CloudTrail logs to identify `PutImage` events from the ECR service, filtering out known users. This activity is significant because container uploads should typically be performed by a limited set of authorized users. If confirmed malicious, this could indicate unauthorized access, potentially leading to the deployment of malicious containers, data exfiltration, or further compromise of the AWS environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -1372,7 +1356,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search uses built in Splunk command `| anomalydetection` to detect anomalies with respect to users making high number of GetObject API calls to download objects from S3 in a 10 minute time window. The field `probable_cause` is the name of the field that best explains why the event is anomalous. This command identifies anomalous events by computing a probability for each GetObject event by "count" "user_type" "user_arn" and detects anomaly based on the frequencies. +explanation = The following analytic identifies anomalous GetObject API activity in AWS, indicating potential data exfiltration attempts. It leverages AWS CloudTrail logs and uses the `anomalydetection` command to detect unusual patterns in the frequency of GetObject API calls by analyzing fields such as "count," "user_type," and "user_arn" within a 10-minute window. This activity is significant as it may indicate unauthorized data access or exfiltration from S3 buckets. If confirmed malicious, attackers could exfiltrate sensitive data, leading to data breaches and compliance violations. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.AE"]} known_false_positives = It is possible that a user downloaded these files to use them locally and there are AWS services in configured that perform these activities for a legitimate reason. Filter is needed. @@ -1382,7 +1366,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job. +explanation = The following analytic identifies the creation of AWS Batch jobs that could potentially abuse the AWS Bucket Replication feature on S3 buckets. It leverages AWS CloudTrail logs to detect the `JobCreated` event, analyzing job details and their status. This activity is significant because attackers can exploit this feature to exfiltrate data by creating malicious batch jobs. If confirmed malicious, this could lead to unauthorized data transfer between S3 buckets, resulting in data breaches and loss of sensitive information. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]} known_false_positives = It is possible that an AWS Administrator or a user has legitimately created this job for some tasks. @@ -1392,8 +1376,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = EC2 Snapshot confidence = medium -explanation = The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region. \ -S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account. +explanation = The following analytic detects API calls to enable S3 bucket replication services. It leverages AWS CloudTrail logs to identify `PutBucketReplication` events, focusing on fields like `bucketName`, `ReplicationConfiguration.Rule.Destination.Bucket`, and user details. This activity is significant as it can indicate unauthorized data replication, potentially leading to data exfiltration. If confirmed malicious, attackers could replicate sensitive data to external accounts, leading to data breaches and compliance violations. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} known_false_positives = It is possible that an AWS admin has legitimately implemented data replication to ensure data availability and improve data protection/backup strategies. @@ -1403,7 +1386,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data. +explanation = The following analytic detects the creation of an AWS DataSync task, which could indicate potential data exfiltration. It leverages AWS CloudTrail logs to identify the `CreateTask` event from the DataSync service. This activity is significant because attackers can misuse DataSync to transfer sensitive data from a private AWS location to a public one, leading to data compromise. If confirmed malicious, this could result in unauthorized access to sensitive information, causing severe data breaches and compliance violations. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]} known_false_positives = It is possible that an AWS Administrator has legitimately created this task for creating backup. Please check the `sourceLocationArn` and `destinationLocationArn` of this task @@ -1413,7 +1396,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = EC2 Snapshot confidence = medium -explanation = This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information. +explanation = The following analytic detects a series of AWS API calls related to EC2 snapshots within a short time window, indicating potential exfiltration via EC2 Snapshot modifications. It leverages AWS CloudTrail logs to identify actions such as creating, describing, and modifying snapshot attributes. This activity is significant as it may indicate an attacker attempting to exfiltrate data by sharing EC2 snapshots externally. If confirmed malicious, the attacker could gain access to sensitive information stored in the snapshots, leading to data breaches and potential compliance violations. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. We have intentionally removed `guardduty.amazonaws.com` from src_ip to remove false positives caused by guard duty. We recommend you adjust the time window as per your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with an other account for a specific purpose. Please check any recent change requests filed in your organization. @@ -1423,7 +1406,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an AWS account with more than 20 failed authentication events in the span of 5 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +explanation = The following analytic detects an AWS account experiencing more than 20 failed authentication attempts within a 5-minute window. It leverages AWS CloudTrail logs to identify multiple failed ConsoleLogin events. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, the attacker could potentially gain unauthorized access, leading to data breaches or further exploitation of the AWS environment. Security teams should consider adjusting the threshold based on their specific environment to reduce false positives. how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. @@ -1433,7 +1416,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an IP address failing to authenticate 20 or more times to the AWS Web Console in the span of 5 minutes. This behavior could represent a brute force attack against an AWS tenant to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +explanation = The following analytic detects an IP address with 20 or more failed authentication attempts to the AWS Web Console within a 5-minute window. This detection leverages CloudTrail logs, aggregating failed login events by IP address and time span. This activity is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges within an AWS environment. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation of AWS resources. how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. @@ -1443,7 +1426,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following detection identifies excessive AccessDenied events within an hour timeframe. It is possible that an access key to AWS may have been stolen and is being misused to perform discovery events. In these instances, the access is not available with the key stolen therefore these events will be generated. +explanation = The following analytic identifies excessive AccessDenied events within an hour timeframe for IAM users in AWS. It leverages AWS CloudTrail logs to detect multiple failed access attempts from the same source IP and user identity. This activity is significant as it may indicate that an access key has been compromised and is being misused for unauthorized discovery actions. If confirmed malicious, this could allow attackers to gather information about the AWS environment, potentially leading to further exploitation or privilege escalation. how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580"], "nist": ["DE.AE"]} known_false_positives = It is possible to start this detection will need to be tuned by source IP or user. In addition, change the count values to an upper threshold to restrict false positives. @@ -1453,7 +1436,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing. +explanation = The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services. how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. Set the `where count` greater than a value to identify suspicious activity in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580", "T1110"], "nist": ["DE.CM"]} known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. @@ -1463,7 +1446,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following detection identifies when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy. +explanation = The following analytic detects the deletion of an IAM policy in AWS. It leverages AWS CloudTrail logs to identify `DeletePolicy` events, excluding those from AWS internal services. This activity is significant as unauthorized policy deletions can disrupt access controls and weaken security postures. If confirmed malicious, an attacker could remove critical security policies, potentially leading to privilege escalation, unauthorized access, or data exfiltration. Monitoring this behavior helps ensure that only authorized changes are made to IAM policies, maintaining the integrity and security of the AWS environment. how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only. @@ -1473,7 +1456,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This detection identifies failure attempts to delete groups. We want to identify when a group is attempting to be deleted, but either access is denied, there is a conflict or there is no group. This is indicative of administrators performing an action, but also could be suspicious behavior occurring. Review parallel IAM events - recently added users, new groups and so forth. +explanation = The following analytic identifies failed attempts to delete AWS IAM groups. It leverages AWS CloudTrail logs to detect events where the DeleteGroup action fails due to errors like NoSuchEntityException, DeleteConflictException, or AccessDenied. This activity is significant as it may indicate unauthorized attempts to modify IAM group configurations, which could be a precursor to privilege escalation or other malicious actions. If confirmed malicious, this could allow an attacker to disrupt IAM policies, potentially leading to unauthorized access or denial of service within the AWS environment. how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege). @@ -1483,7 +1466,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following query uses IAM events to track the success of a group being deleted on AWS. This is typically not indicative of malicious behavior, but a precurser to additional events thay may unfold. Review parallel IAM events - recently added users, new groups and so forth. Inversely, review failed attempts in a similar manner. +explanation = The following analytic identifies the successful deletion of an IAM group in AWS. It leverages CloudTrail logs to detect `DeleteGroup` events with a success status. This activity is significant as it could indicate potential changes in user permissions or access controls, which may be a precursor to further unauthorized actions. If confirmed malicious, an attacker could disrupt access management, potentially leading to privilege escalation or unauthorized access to sensitive resources. Analysts should review related IAM events, such as recent user additions or new group creations, to assess the broader context. how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1069.003", "T1098", "T1069"], "nist": ["DE.AE"]} known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege). @@ -1493,7 +1476,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This analytic is designed to detect IAM users attempting to update/modify AWS lambda code via the AWS CLI to gain persistence, futher access into your AWS environment and to facilitate planting backdoors. In this instance, an attacker may upload malicious code/binary to a lambda function which will be executed automatically when the funnction is triggered. +explanation = The following analytic identifies IAM users attempting to update or modify AWS Lambda code via the AWS CLI. It leverages CloudTrail logs to detect successful `UpdateFunctionCode` events initiated by IAM users. This activity is significant as it may indicate an attempt to gain persistence, further access, or plant backdoors within your AWS environment. If confirmed malicious, an attacker could upload and execute malicious code automatically when the Lambda function is triggered, potentially compromising the integrity and security of your AWS infrastructure. how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin or an autorized IAM user has updated the lambda fuction code legitimately. @@ -1503,7 +1486,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +explanation = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages AWS CloudTrail logs to identify events where MFA devices are deleted or deactivated. This activity is significant because disabling MFA can indicate an adversary attempting to weaken account security, potentially to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, posing a significant risk to the security and integrity of the cloud infrastructure. how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company @@ -1513,7 +1496,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies multiple failed multi-factor authentication requests to an AWS Console for a single user. AWS CloudTrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. AWS Environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +explanation = The following analytic identifies multiple failed multi-factor authentication (MFA) requests to an AWS Console for a single user. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect more than 10 failed MFA prompts within 5 minutes. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access to the AWS environment, potentially compromising sensitive data and resources. how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.AE"]} known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. @@ -1523,7 +1506,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies one source Ip failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment tenant to obtain initial access or elevate privileges. +explanation = The following analytic identifies a single source IP failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. It leverages CloudTrail logs to detect multiple failed login attempts from the same IP address. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain unauthorized access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = No known false postives for this detection. Please review this alert @@ -1543,7 +1526,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Instance confidence = medium -explanation = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the AWS console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the AWS CloudTrail logs to detect users deleting network ACLs. +explanation = The following analytic detects the deletion of AWS Network Access Control Lists (ACLs). It leverages AWS CloudTrail logs to identify events where a user deletes a network ACL entry. This activity is significant because deleting a network ACL can remove critical access restrictions, potentially allowing unauthorized access to cloud instances. If confirmed malicious, this action could enable attackers to bypass network security controls, leading to unauthorized access, data exfiltration, or further compromise of the cloud environment. how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.AE"]} known_false_positives = It's possible that a user has legitimately deleted a network ACL. @@ -1563,7 +1546,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events where a user is making successful API calls to view/update/delete the existing password policy in an AWS organization. It is unlikely for a regular user to conduct this operation. These events may potentially be malicious, adversaries often use this information to gain more understanding of the password defenses in place and exploit them to increase their attack surface when a user account is compromised. +explanation = The following analytic detects successful API calls to view, update, or delete the password policy in an AWS organization. It leverages AWS CloudTrail logs to identify events such as "UpdateAccountPasswordPolicy," "GetAccountPasswordPolicy," and "DeleteAccountPasswordPolicy." This activity is significant because it is uncommon for regular users to perform these actions, and such changes can indicate an adversary attempting to understand or weaken password defenses. If confirmed malicious, this could lead to compromised accounts and increased attack surface, potentially allowing unauthorized access and control over AWS resources. how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately triggered an AWS audit tool activity which may trigger this event. @@ -1573,7 +1556,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. +explanation = The following analytic identifies potential AWS S3 exfiltration behavior by correlating multiple risk events related to Collection and Exfiltration techniques. It leverages risk events from AWS sources, focusing on instances where two or more unique analytics and distinct MITRE ATT&CK IDs are triggered for a specific risk object. This activity is significant as it may indicate an ongoing data exfiltration attempt, which is critical for security teams to monitor. If confirmed malicious, this could lead to unauthorized access and theft of sensitive information, compromising the organization's data integrity and confidentiality. how_to_implement = You must enable all the detection searches in the Data Exfiltration Analytic story to create risk events in Enterprise Security. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"]} known_false_positives = alse positives may be present based on automated tooling or system administrators. Filter as needed. @@ -1583,7 +1566,7 @@ providing_technologies = null type = detection asset_type = AWS Federated Account confidence = medium -explanation = This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider. +explanation = The following analytic identifies specific SAML access events by a service provider, user, and targeted principal within AWS. It leverages AWS CloudTrail logs to detect the `AssumeRoleWithSAML` event, analyzing fields such as `principalArn`, `roleArn`, and `roleSessionName`. This activity is significant as it can indicate abnormal access patterns or potential credential hijacking, especially in federated environments using the SAML protocol. If confirmed malicious, this could allow attackers to assume roles and gain unauthorized access to sensitive AWS resources, leading to data breaches or further exploitation. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = Attacks using a Golden SAML or SAML assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source IP sourceIPAddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks. @@ -1593,7 +1576,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Federated Account confidence = medium -explanation = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker. +explanation = The following analytic detects updates to the SAML provider in AWS. It leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. Monitoring updates to the SAML provider is crucial as it may indicate a perimeter compromise of federated credentials or unauthorized backdoor access set by an attacker. If confirmed malicious, this activity could allow attackers to manipulate identity federation, potentially leading to unauthorized access to cloud resources and sensitive data. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]} known_false_positives = Updating a SAML provider or creating a new one may not necessarily be malicious however it needs to be closely monitored. @@ -1603,7 +1586,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy +explanation = The following analytic detects when a user sets a default policy version in AWS. It leverages AWS CloudTrail logs to identify the `SetDefaultPolicyVersion` event from the IAM service. This activity is significant because attackers may exploit this technique for privilege escalation, especially if previous policy versions grant more extensive permissions than the current one. If confirmed malicious, this could allow an attacker to gain elevated access to AWS resources, potentially leading to unauthorized actions and data breaches. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately set a default policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources @@ -1613,7 +1596,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies an AWS account successfully authenticating from more than one unique Ip address in the span of 5 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +explanation = The following analytic detects an AWS account successfully authenticating from multiple unique IP addresses within a 5-minute window. It leverages AWS CloudTrail logs, specifically monitoring `ConsoleLogin` events and counting distinct source IPs. This behavior is significant as it may indicate compromised credentials, potentially from a phishing attack, being used concurrently by an adversary and a legitimate user. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the AWS environment. how_to_implement = You must install Splunk AWS add on and Splunk App for AWS. This search works when AWS CloudTrail events are normalized use the Authentication datamodel. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1535"], "nist": ["DE.AE"]} known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -1623,7 +1606,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies a successful Console Login authentication event against an AWS IAM user for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account take over attempt that should be investigated +explanation = The following analytic identifies a successful Console Login authentication event for an AWS IAM user account without Multi-Factor Authentication (MFA) enabled. It leverages AWS CloudTrail logs to detect instances where MFA was not used during login. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the AWS environment, potentially leading to data exfiltration, resource manipulation, or further privilege escalation. how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = It is possible that some accounts do not have MFA enabled for the AWS account however its agaisnt the best practices of securing AWS. @@ -1633,7 +1616,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = The following analytic identifies one source IP failing to authenticate into the AWS Console with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `AWS Multiple Users Failing To Authenticate From Ip`. +explanation = The following analytic identifies a single source IP failing to authenticate into the AWS Console with multiple valid users. It uses CloudTrail logs and calculates the standard deviation for source IP, leveraging the 3-sigma rule to detect unusual numbers of failed authentication attempts. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the calculation of the upperBound field to tune this search according to their environment annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = No known false postives for this detection. Please review this alert @@ -1643,7 +1626,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = AWS Account confidence = medium -explanation = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B) +explanation = The following analytic detects an AWS CloudTrail event where a user with permissions updates the login profile of another user. It leverages CloudTrail logs to identify instances where the user making the change is different from the user whose profile is being updated. This activity is significant because it can indicate privilege escalation attempts, where an attacker uses a compromised account to gain higher privileges. If confirmed malicious, this could allow the attacker to escalate their privileges, potentially leading to unauthorized access and control over sensitive resources within the AWS environment. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user. @@ -1653,7 +1636,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic triggers on a high risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them in three categories high, medium and low. +explanation = The following analytic detects high-risk sign-in attempts against Azure Active Directory, identified by Azure Identity Protection. It leverages the RiskyUsers and UserRiskEvents log categories from Azure AD events ingested via EventHub. This activity is significant as it indicates potentially compromised accounts, flagged by heuristics and machine learning. If confirmed malicious, attackers could gain unauthorized access to sensitive resources, leading to data breaches or further exploitation within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category in the azure:monitor:aad sourcetype. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003"], "nist": ["DE.CM"]} known_false_positives = Details for the risk calculation algorithm used by Identity Protection are unknown and may be prone to false positives. @@ -1663,7 +1646,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight. +explanation = The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. @@ -1673,7 +1656,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant. +explanation = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. It leverages Azure Active Directory events, specifically monitoring the "Add member to role" operation. This activity is significant because users in this role can manage all aspects of enterprise applications, including credentials, which can be used to impersonate application identities. If confirmed malicious, an attacker could escalate privileges, manage application settings, and potentially access sensitive resources by impersonating application identities, posing a significant security risk to the Azure AD tenant. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately assign the Application Administrator role to a user. Filter as needed. @@ -1683,7 +1666,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies an authentication attempt event against an Azure AD tenant that fails during the Multi Factor Authentication challenge. Error Code 500121 represents a failed attempt to authenticate using a second factor. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +explanation = The following analytic identifies failed authentication attempts against an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically flagged by error code 500121. It leverages Azure AD SignInLogs to detect these events. This activity is significant as it may indicate an adversary attempting to authenticate using compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing effort to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. @@ -1693,7 +1676,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization +explanation = The following analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats by allowing users to grant consent to potentially malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]} known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization @@ -1703,7 +1686,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies an Azure AD account with concurrent sessions coming from more than one unique Ip address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +explanation = The following analytic detects an Azure AD account with concurrent sessions originating from multiple unique IP addresses within a 5-minute window. It leverages Azure Active Directory NonInteractiveUserSignInLogs to identify this behavior by analyzing successful authentication events and counting distinct source IPs per user. This activity is significant as it may indicate session hijacking, where an attacker uses stolen session cookies to access corporate resources from a different location. If confirmed malicious, this could lead to unauthorized access to sensitive information and potential data breaches. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -1713,7 +1696,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies the execution of the Azure Device Code Phishing attack, which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically focusing on authentication requests to identify the attack. This technique involves creating malicious infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. +explanation = The following analytic identifies Azure Device Code Phishing attacks, which can lead to Azure Account Take-Over (ATO). It leverages Azure AD SignInLogs to detect suspicious authentication requests using the device code authentication protocol. This activity is significant as it indicates potential bypassing of Multi-Factor Authentication (MFA) and Conditional Access Policies (CAPs) through phishing emails. If confirmed malicious, attackers could gain unauthorized access to Azure AD, Exchange mailboxes, and Outlook Web Application (OWA), leading to potential data breaches and unauthorized data access. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1528", "T1566", "T1566.002"], "nist": ["DE.CM"]} known_false_positives = In most organizations, device code authentication will be used to access common Microsoft service but it may be legitimate for others. Filter as needed. @@ -1723,7 +1706,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the invitation of an external guest user within Azure AD. With Azure AD B2B collaboration, users and administrators can invite external users to collaborate with internal users. External guest account invitations should be monitored by security teams as they could potentially lead to unauthorized access. An example of this attack vector was described at BlackHat 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking Azure AD Accounts by Abusing External Identities` +explanation = The following analytic detects the invitation of an external guest user within Azure AD. It leverages Azure AD AuditLogs to identify events where an external user is invited, using fields such as operationName and initiatedBy. Monitoring these invitations is crucial as they can lead to unauthorized access if abused. If confirmed malicious, this activity could allow attackers to gain access to internal resources, potentially leading to data breaches or further exploitation of the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]} known_false_positives = Administrator may legitimately invite external guest users. Filter as needed. @@ -1733,7 +1716,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited. +explanation = The following analytic detects the assignment of the 'full_access_as_app' permission to an application within Office 365 Exchange Online. This is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. The detection leverages the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This activity is significant as it grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. If malicious, this could lead to unauthorized access and data exfiltration. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. @@ -1743,7 +1726,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of the Azure AD Global Administrator role to an Azure AD user. The Global Administrator role is the most powerful administrator role in Azure AD and provides almost unlimited access to data, resources and settings. It is equivalent to the Domain Administrator group in an Active Directory environment. While Azure AD roles do not grant access to Azure services and resources, it is possible for a Global Administrator account to gain control of Azure resources. Adversaries and red teams alike may assign this role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment. +explanation = The following analytic detects the assignment of the Azure AD Global Administrator role to a user. It leverages Azure Active Directory AuditLogs to identify when the "Add member to role" operation includes the "Global Administrator" role. This activity is significant because the Global Administrator role grants extensive access to data, resources, and settings, similar to a Domain Administrator in traditional AD environments. If confirmed malicious, this could allow an attacker to establish persistence, escalate privileges, and potentially gain control over Azure resources, posing a severe security risk. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately assign the Global Administrator role to a user. Filter as needed. @@ -1753,7 +1736,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies an Azure AD account with more than 20 failed authentication events in the span of 10 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +explanation = The following analytic identifies an Azure AD account experiencing more than 20 failed authentication attempts within a 10-minute window. This detection leverages Azure SignInLogs data, specifically monitoring for error code 50126 and unsuccessful authentication attempts. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, an attacker could potentially gain unauthorized access, leading to data breaches or further exploitation within the environment. Security teams should adjust the threshold based on their specific environment to reduce false positives. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]} known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. @@ -1763,7 +1746,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies an Ip address failing to authenticate 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could represent a brute force attack againstan Azure AD to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +explanation = The following analytic detects an IP address with 20 or more failed authentication attempts to an Azure AD tenant within 10 minutes. It leverages Azure AD SignInLogs to identify repeated failed logins from the same IP. This behavior is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges. If confirmed malicious, the attacker could potentially compromise user accounts, leading to unauthorized access to sensitive information and resources within the Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]} known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 10 minutes may also be triggered by a broken application. @@ -1773,7 +1756,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies an attempt to disable multi-factor authentication for an Azure AD user. An adversary who has obtained access to an Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +explanation = The following analytic detects attempts to disable multi-factor authentication (MFA) for an Azure AD user. It leverages Azure Active Directory AuditLogs to identify the "Disable Strong Authentication" operation. This activity is significant because disabling MFA can allow adversaries to maintain persistence using compromised accounts without raising suspicion. If confirmed malicious, this action could enable attackers to bypass an essential security control, potentially leading to unauthorized access and prolonged undetected presence in the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed. @@ -1783,7 +1766,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure. +explanation = The following analytic detects potential distributed password spraying attacks in an Azure AD environment. It identifies a spike in failed authentication attempts across various user-and-IP combinations from multiple source IPs and countries, using different user agents. This detection leverages Azure AD SignInLogs, focusing on error code 50126 for failed authentications. This activity is significant as it indicates an adversary's attempt to bypass security controls by distributing login attempts. If confirmed malicious, this could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization's infrastructure. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. @@ -1793,7 +1776,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +explanation = The following analytic detects unusual authentication activity in Azure AD, specifically when a single user account has over 8 authentication attempts using 3+ unique application IDs and 5+ unique user agents within a short period. It leverages Azure AD audit logs, focusing on authentication events and using statistical thresholds. This behavior is significant as it may indicate an adversary probing for MFA requirements. If confirmed malicious, it suggests a compromised account, potentially leading to further exploitation, lateral movement, and data exfiltration. Early detection is crucial to prevent substantial harm. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. @@ -1803,7 +1786,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +explanation = The following analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. It leverages Azure Active Directory (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 and additional details indicating "MFA denied; user declined the authentication." This behavior is significant as it may indicate a targeted attack or account compromise attempt, with the user actively declining unauthorized access. If confirmed malicious, it could lead to data exfiltration, lateral movement, or further malicious activities. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} known_false_positives = Multiple denifed MFA requests in a short period of span may also be a sign of authentication errors. Investigate and filter as needed. @@ -1813,7 +1796,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +explanation = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Azure AD tenant. It leverages Azure AD Sign-in Logs, specifically error code 500121, to detect more than 10 failed MFA attempts within 10 minutes. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication prompts. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise user accounts and potentially escalate their privileges within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. @@ -1823,7 +1806,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = This detection identifies when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span, potentially signaling malicious activity. It monitors the 'Add service principal' operation, focusing on the activity of service principals rather than individual users. By aggregating the creation events over a 10-minute period, the analytic tracks how many distinct OAuth applications are created by each service principal. This is key for SOC teams to pinpoint potential attack staging, where an attacker might use a compromised or malicious service principal to rapidly establish multiple service principals, facilitating network infiltration or expansion. While the default threshold is set to trigger on more than three applications, security teams should adjust this to fit their specific environment's norm +explanation = The following analytic detects when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span. It leverages Azure AD audit logs, specifically monitoring the 'Add service principal' operation initiated by service principals. This behavior is significant as it may indicate an attacker using a compromised or malicious service principal to rapidly establish multiple service principals, potentially staging an attack. If confirmed malicious, this activity could facilitate network infiltration or expansion, allowing the attacker to gain unauthorized access and persist within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. @@ -1833,7 +1816,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = This detection focuses on identifying instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD, a potential indicator of malicious activity. By monitoring the 'Add service principal' operation and aggregating the data with a 10-minute bucket span, it tracks the number of distinct OAuth applications created by each user. This analytic is crucial for SOC teams to detect possible staging of attacks, where an adversary might rapidly create multiple service principals as part of their infiltration or expansion strategy within the network. The threshold of three applications is set to flag unusual behavior, but security teams are advised to adjust this value to suit the normal operational patterns of their environment +explanation = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD. It detects this activity by monitoring the 'Add service principal' operation and aggregating data in 10-minute intervals. This behavior is significant as it may indicate an adversary rapidly creating multiple service principals to stage an attack or expand their foothold within the network. If confirmed malicious, this activity could allow attackers to establish persistence, escalate privileges, or access sensitive information within the Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. @@ -1843,8 +1826,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies one source Ip failing to authenticate with 30 unique valid users within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -Azure AD tenants can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold if needed. +explanation = The following analytic detects a single source IP failing to authenticate with 30 unique valid users within 5 minutes in Azure Active Directory. It leverages Azure AD SignInLogs with error code 50126, indicating invalid passwords. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or privilege escalation within the Azure AD environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. @@ -1854,7 +1836,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the addition of a new custom domain within an Azure Active Directory tenant. Adding a custom domain is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +explanation = The following analytic detects the addition of a new custom domain within an Azure Active Directory (AD) tenant. It leverages Azure AD AuditLogs to identify successful "Add unverified domain" operations. This activity is significant as it may indicate an adversary attempting to establish persistence by setting up identity federation backdoors, allowing them to impersonate users and bypass authentication mechanisms. If confirmed malicious, this could enable attackers to gain unauthorized access, escalate privileges, and maintain long-term access to the Azure AD environment, posing a severe security risk. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]} known_false_positives = In most organizations, new customm domains will be updated infrequently. Filter as needed. @@ -1864,7 +1846,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the addition of a new federated domain within an Azure Active Directory tenant. This event could represent the execution of the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +explanation = The following analytic detects the addition of a new federated domain within an Azure Active Directory tenant. It leverages Azure AD AuditLogs to identify successful "Set domain authentication" operations. This activity is significant as it may indicate the use of the Azure AD identity federation backdoor technique, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, potentially leading to unauthorized access and control over the Azure AD environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]} known_false_positives = In most organizations, domain federation settings will be updated infrequently. Filter as needed. @@ -1874,7 +1856,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +explanation = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account in Azure Active Directory. It leverages Azure AD audit logs to identify changes in MFA configurations. This activity is significant because adding a new MFA method can indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges, access sensitive data, or make unauthorized changes. Immediate verification and remediation are required to secure the affected account. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed. @@ -1884,7 +1866,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the registration of a new Multi Factor authentication method for an Azure AD account. Adversaries who have obtained unauthorized access to an Azure AD account may register a new MFA method to maintain persistence. +explanation = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs to identify when a user registers new security information. This activity is significant because adversaries who gain unauthorized access to an account may add their own MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security controls, maintain long-term access, and potentially escalate their privileges within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. @@ -1894,7 +1876,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. +explanation = The following analytic detects when a user in an Azure AD environment grants consent to an OAuth application. It leverages Azure AD audit logs to identify events where users approve application consents. This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access. If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = False positives may occur if users are granting consents as part of legitimate application integrations or setups. It is crucial to review the application and the permissions it requests to ensure they align with organizational policies and security best practices. @@ -1904,7 +1886,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +explanation = The following analytic detects the assignment of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user is added as an eligible member to a PIM role. This activity is significant because PIM roles grant elevated privileges, and their assignment should be closely monitored to prevent unauthorized access. If confirmed malicious, an attacker could exploit this to gain privileged access, potentially leading to unauthorized actions, data breaches, or further compromise of the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = As part of legitimate administrative behavior, users may be assigned PIM roles. Filter as needed @@ -1914,7 +1896,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +explanation = The following analytic detects the activation of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user activates a PIM role assignment, indicated by the "Add member to role completed (PIM activation)" operation. Monitoring this activity is crucial as PIM roles grant elevated privileges, and unauthorized activation could indicate an adversary attempting to gain privileged access. If confirmed malicious, this could lead to unauthorized administrative actions, data breaches, or further compromise of the Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed @@ -1924,7 +1906,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. Red teams and adversaries alike may abuse this role to escalate their privileges. +explanation = The following analytic detects the assignment of the Privileged Authentication Administrator role to an Azure AD user. It leverages Azure Active Directory audit logs to identify when this specific role is assigned. This activity is significant because users in this role can set or reset authentication methods for any user, including those in privileged roles like Global Administrators. If confirmed malicious, an attacker could change credentials and assume the identity and permissions of high-privilege users, potentially leading to unauthorized access to sensitive information and critical configurations. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately assign the Privileged Authentication Administrator role as part of administrative tasks. Filter as needed. @@ -1934,7 +1916,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches. +explanation = The following analytic detects the assignment of high-risk Graph API permissions in Azure AD, specifically Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. It uses azure_monitor_aad data to scan AuditLogs for 'Update application' operations, identifying when these permissions are assigned. This activity is significant as it grants broad control over Azure AD, including application and directory settings. If confirmed malicious, it could lead to unauthorized modifications and potential security breaches, compromising the integrity and security of the Azure AD environment. Immediate investigation is required. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. @@ -1944,7 +1926,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment. +explanation = The following analytic detects the assignment of privileged Azure Active Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring the "Add member to role" operation. This activity is significant as adversaries may assign privileged roles to compromised accounts to maintain persistence within the Azure AD environment. If confirmed malicious, this could allow attackers to escalate privileges, access sensitive information, and maintain long-term control over the Azure AD infrastructure. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Administrators will legitimately assign the privileged roles users as part of administrative tasks. Filter as needed. @@ -1954,7 +1936,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. +explanation = The following analytic detects the assignment of privileged roles to service principals in Azure Active Directory (AD). It leverages the AuditLogs log category from ingested Azure AD events. This activity is significant because assigning elevated permissions to non-human entities can lead to unauthorized access or malicious activities. If confirmed malicious, attackers could exploit these service principals to gain elevated access to Azure resources, potentially compromising sensitive data and critical infrastructure. Monitoring this behavior helps prevent privilege escalation and ensures the security of Azure environments. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately assign the privileged roles to Service Principals as part of administrative tasks. Filter as needed. @@ -1964,7 +1946,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities. +explanation = The following analytic identifies authentication events of service principals in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring these events is significant for SOC teams to distinguish between normal application authentication and potential anomalies, which could indicate compromised credentials or malicious activities. If confirmed malicious, attackers could gain unauthorized access to resources, leading to data breaches or further exploitation within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.CM"]} known_false_positives = Service Principals will legitimally authenticate remotely to your tenant. Implementing this detection after establishing a baseline enables a more accurate identification of security threats, ensuring proactive and informed responses to safeguard the Azure AD environment. source ips. @@ -1974,7 +1956,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the creation of a Service Principal in an Azure AD environment. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may create a Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. +explanation = The following analytic detects the creation of a Service Principal in an Azure AD environment. It leverages Azure Active Directory events ingested through EventHub, specifically monitoring the "Add service principal" operation. This activity is significant because Service Principals can be used by adversaries to establish persistence and bypass multi-factor authentication and conditional access policies. If confirmed malicious, this could allow attackers to maintain single-factor access to the Azure AD environment, potentially leading to unauthorized access to resources and prolonged undetected activity. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment thorough an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]} known_false_positives = Administrator may legitimately create Service Principal. Filter as needed. @@ -1984,7 +1966,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the addition of new credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 certificates and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries and red teams alike who have obtained privileged access to Azure AD may add credentials to Service Principals to maintain persistent access to victim accounts and other instances within the Azure environment. By compromising an account who is an Owner of an application with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and logging in as the service principal. +explanation = The following analytic detects the addition of new credentials to Service Principals and Applications in Azure AD. It leverages Azure AD AuditLogs, specifically monitoring the "Update application*Certificates and secrets management" operation. This activity is significant as it may indicate an adversary attempting to maintain persistent access or escalate privileges within the Azure environment. If confirmed malicious, attackers could use these new credentials to log in as the service principal, potentially compromising sensitive accounts and resources, leading to unauthorized access and control over the Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]} known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. @@ -1994,7 +1976,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the addition of a new owner for a Service Principal within an Azure AD tenant. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may add a new owner for an existing Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. Attackers who are looking to escalate their privileges by leveraging a Service Principals permissions may also add a new owner. +explanation = The following analytic detects the addition of a new owner to a Service Principal within an Azure AD tenant. It leverages Azure Active Directory events from the AuditLog log category to identify this activity. This behavior is significant because Service Principals do not support multi-factor authentication or conditional access policies, making them a target for adversaries seeking persistence or privilege escalation. If confirmed malicious, this activity could allow attackers to maintain access to the Azure AD environment with single-factor authentication, potentially leading to unauthorized access and control over critical resources. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = Administrator may legitimately add new owners for Service Principals. Filter as needed. @@ -2004,7 +1986,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies an Azure AD account successfully authenticating from more than one unique Ip address in the span of 30 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +explanation = The following analytic detects an Azure AD account successfully authenticating from multiple unique IP addresses within a 30-minute window. It leverages Azure AD SignInLogs to identify instances where the same user logs in from different IPs in a short time frame. This behavior is significant as it may indicate compromised credentials being used by an adversary, potentially following a phishing attack. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the network. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]} known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. @@ -2014,7 +1996,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell commandlets. This behavior is not common for regular, non administrative users. After compromising an account in Azure AD, attackers and red teams alike will perform enumeration and discovery techniques. One method of executing these techniques is leveraging the native PowerShell modules. +explanation = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell cmdlets. This detection leverages Azure AD SignInLogs to identify successful logins where the appDisplayName is "Microsoft Azure PowerShell." This activity is significant because it is uncommon for regular, non-administrative users to authenticate using PowerShell, and it may indicate enumeration and discovery techniques by an attacker. If confirmed malicious, this activity could allow attackers to perform extensive reconnaissance, potentially leading to privilege escalation or further exploitation within the Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Administrative users will likely use PowerShell commandlets to troubleshoot and maintain the environment. Filter as needed. @@ -2024,7 +2006,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies a successful authentication event against Azure Active Directory for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +explanation = The following analytic identifies a successful single-factor authentication event against Azure Active Directory. It leverages Azure SignInLogs data, specifically focusing on events where single-factor authentication succeeded. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches, privilege escalation, or further exploitation within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed @@ -2034,7 +2016,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to sensitive data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed. @@ -2044,9 +2026,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies one source Ip failing to authenticate with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. \ -The detection calculates the standard deviation for source Ip and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `Azure AD Multiple Users Failing To Authenticate From Ip`. +explanation = The following analytic identifies a single source IP failing to authenticate with multiple valid users, potentially indicating a Password Spraying attack against an Azure Active Directory tenant. It uses Azure SignInLogs data and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual numbers of failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. @@ -2056,7 +2036,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +explanation = The following analytic detects instances where Azure AD has blocked a user's attempt to grant consent to a risky or potentially malicious application. This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = UPDATE_KNOWN_FALSE_POSITIVES @@ -2066,7 +2046,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +explanation = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Azure AD environment. This detection leverages Azure AD's audit logs, specifically focusing on user consent actions with error code 65004. Monitoring denied consent actions is significant as it can indicate users recognizing potentially suspicious or untrusted applications. If confirmed malicious, this activity could suggest attempts by unauthorized applications to gain access, potentially leading to data breaches or unauthorized actions within the environment. Understanding these denials helps refine security policies and enhance user awareness. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = Users may deny consent for legitimate applications by mistake, filter as needed. @@ -2076,7 +2056,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This behavior could represent an adversary who has obtained administrative access and is trying to establish a backdoor identity within an Azure AD tenant. +explanation = The following analytic detects an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. It uses Azure Active Directory events to identify this sequence of actions. This activity is significant because it may indicate an adversary with administrative access attempting to establish a backdoor identity within the Azure AD tenant. If confirmed malicious, this could allow the attacker to maintain persistent access, escalate privileges, and potentially exfiltrate sensitive information from the environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = While not common, Administrators may enable accounts and reset their passwords for legitimate reasons. Filter as needed. @@ -2086,7 +2066,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Active Directory confidence = medium -explanation = The following analytic identifies the modification of the SourceAnchor (also called ImmutableId) attribute for an Azure Active Directory user. Updating this attribute is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +explanation = The following analytic identifies the modification of the SourceAnchor (ImmutableId) attribute for an Azure Active Directory user. This detection leverages Azure AD audit logs, specifically monitoring the "Update user" operation and changes to the SourceAnchor attribute. This activity is significant as it is a step in setting up an Azure AD identity federation backdoor, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, leading to unauthorized access and potential data breaches. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = The SourceAnchor (also called ImmutableId) Azure AD attribute has legitimate uses for directory synchronization. Investigate and filter as needed. @@ -2096,7 +2076,7 @@ providing_technologies = ["Azure AD", "Entra ID"] type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies the creation of a new Azure Automation account within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure using PowerShell and Python. Azure Automation can also be configured to automate tasks on on premise infrastructure using a component called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate Automation resources, runbooks, assets, and configurations from the resources of other accounts. They allow administrators to separate resources into logical environments or delegated responsibilities. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation account with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +explanation = The following analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately create Azure Automation accounts. Filter as needed. @@ -2106,7 +2086,7 @@ providing_technologies = null type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies the creation of a new Azure Automation Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation Runbook that runs with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +explanation = The following analytic detects the creation of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when a new Runbook is created or updated. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately create Azure Automation Runbooks. Filter as needed. @@ -2116,7 +2096,7 @@ providing_technologies = null type = detection asset_type = Azure Tenant confidence = medium -explanation = The following analytic identifies the creation of a new Automation Runbook Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. One of the ways administrators can configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom unauthenticated URLs that are exposed to the Internet. An adversary who has obtained privileged access to an Azure tenant may create a Webhook to trigger the execution of an Automation Runbook with malicious code that can create users or execute code on a VM. This provides a persistent foothold on the environment. +explanation = The following analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources. how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Administrators may legitimately create Azure Runbook Webhooks. Filter as needed. @@ -2126,7 +2106,7 @@ providing_technologies = null type = detection asset_type = CircleCI confidence = medium -explanation = This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage. False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection. +explanation = The following analytic detects the disabling of security jobs in CircleCI pipelines. It leverages CircleCI log data, renaming and extracting fields such as job names, workflow IDs, user information, commit messages, URLs, and branches. The detection identifies mandatory jobs for each workflow and checks if they were executed. This activity is significant because disabling security jobs can allow malicious code to bypass security checks, leading to potential data breaches, system downtime, and reputational damage. If confirmed malicious, this could result in unauthorized code execution and compromised pipeline integrity. how_to_implement = You must index CircleCI logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2136,7 +2116,7 @@ providing_technologies = null type = detection asset_type = CircleCI confidence = medium -explanation = The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs. The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change. +explanation = The following analytic detects the disablement of security steps in a CircleCI pipeline. It leverages CircleCI logs, using field renaming, joining, and statistical analysis to identify instances where mandatory security steps are not executed. This activity is significant because disabling security steps can introduce vulnerabilities, unauthorized changes, or malicious code into the pipeline. If confirmed malicious, this could lead to potential attacks, data breaches, or compromised infrastructure. Investigate by reviewing job names, commit details, and user information associated with the disablement, and examine any relevant artifacts and concurrent processes. how_to_implement = You must index CircleCI logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2146,7 +2126,7 @@ providing_technologies = null type = detection asset_type = AWS Instance confidence = medium -explanation = The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes. +explanation = The following analytic detects cloud API calls executed by user roles that have not previously run these commands. It leverages the Change data model in Splunk to identify commands executed by users with the user_type of AssumedRole and a status of success. This activity is significant because new commands from different user roles can indicate potential malicious activity or unauthorized actions. If confirmed malicious, this behavior could lead to unauthorized access, data breaches, or other damaging outcomes by exploiting new or unmonitored commands within the cloud environment. how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud API Calls Per User Role - Initial` to build the initial table of user roles, commands, and times. You must also enable the second baseline search `Previously Seen Cloud API Calls Per User Role - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `cloud_api_calls_from_previously_unseen_user_roles_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_api_calls_from_previously_unseen_user_roles_filter` annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = None. @@ -2176,7 +2156,7 @@ providing_technologies = null type = detection asset_type = Cloud Compute Instance confidence = medium -explanation = The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack. +explanation = The following analytic detects the creation of cloud compute instances using previously unseen image IDs. It leverages cloud infrastructure logs to identify new image IDs that have not been observed before. This activity is significant because it may indicate unauthorized or suspicious activity, such as the deployment of malicious payloads or unauthorized access to sensitive information. If confirmed malicious, this could lead to data breaches, unauthorized access, or further compromise of the cloud environment. Immediate investigation is required to determine the legitimacy of the instance creation and to mitigate potential threats. how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Images - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Images - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_image_filter` macro. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = After a new image is created, the first systems created with that image will cause this alert to fire. Verify that the image being used was created by a legitimate user. @@ -2186,7 +2166,7 @@ providing_technologies = null type = detection asset_type = Cloud Compute Instance confidence = medium -explanation = The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts. +explanation = The following analytic detects the creation of EC2 instances with previously unseen instance types. It leverages Splunk's tstats command to analyze data from the Change data model, identifying instance types that have not been previously recorded. This activity is significant for a SOC because it may indicate unauthorized or suspicious activity, such as an attacker attempting to create instances for malicious purposes. If confirmed malicious, this could lead to unauthorized access, data exfiltration, system compromise, or service disruption. Immediate investigation is required to determine the legitimacy of the instance creation. how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Instance Types - Initial` to build the initial table of instance types observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Instance Types - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_instance_type_filter` macro. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type. @@ -2250,10 +2230,7 @@ providing_technologies = null type = detection asset_type = Cloud Instance confidence = medium -explanation = The following analytic identifies users who are unsually modifying security group in your cloud enriovnment,focusing on actions such as modifications, deletions, or creations performed by users over 30-minute intervals. Analyzing patterns of modifications to security groups can help in identifying anomalous behavior that may indicate a compromised account or an insider threat. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on all user and service accounts that have created/modified/deleted a security group . \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and values of the security objects affected. +explanation = The following analytic identifies unusual modifications to security groups in your cloud environment by users, focusing on actions such as modifications, deletions, or creations over 30-minute intervals. It leverages cloud infrastructure logs and calculates the standard deviation for each user, using the 3-sigma rule to detect anomalies. This activity is significant as it may indicate a compromised account or insider threat. If confirmed malicious, attackers could alter security group configurations, potentially exposing sensitive resources or disrupting services. how_to_implement = This search requries the Cloud infrastructure logs such as AWS Cloudtrail, GCP Pubsub Message logs, Azure Audit logs to be ingested into an accelerated Change datamodel. It is also recommended that users can try different combinations of the `bucket` span time and outlier conditions to better suit with their environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1578.005"], "nist": ["DE.AE"]} known_false_positives = It is possible that legitimate user/admin may modify a number of security groups @@ -2263,7 +2240,7 @@ providing_technologies = null type = detection asset_type = AWS Instance confidence = medium -explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +explanation = The following analytic detects AWS console login events by new users. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users based on ARN values. This detection is significant because a new user logging into the AWS console could indicate the creation of new accounts or potential unauthorized access. If confirmed malicious, this activity could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1552"], "nist": ["DE.AE"]} known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. @@ -2273,7 +2250,7 @@ providing_technologies = null type = detection asset_type = AWS Instance confidence = medium -explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +explanation = The following analytic identifies AWS console login events by users from a new city within the last hour. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen user locations. This activity is significant for a SOC as it may indicate unauthorized access or credential compromise, especially if the login originates from an unusual location. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_city_filter` macro. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. @@ -2283,7 +2260,7 @@ providing_technologies = null type = detection asset_type = AWS Instance confidence = medium -explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +explanation = The following analytic identifies AWS console login events by users from a new country. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users and their login locations. This activity is significant because logins from new countries can indicate potential unauthorized access or compromised accounts. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the AWS environment. how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_country_filter` macro. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. @@ -2293,7 +2270,7 @@ providing_technologies = null type = detection asset_type = AWS Instance confidence = medium -explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +explanation = The following analytic identifies AWS console login attempts by users from a new region. It leverages AWS CloudTrail events and compares current login regions against a baseline of previously seen regions for each user. This activity is significant as it may indicate unauthorized access attempts or compromised credentials. If confirmed malicious, an attacker could gain unauthorized access to AWS resources, potentially leading to data breaches, resource manipulation, or further lateral movement within the cloud environment. how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_region_filter` macro. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. @@ -2393,7 +2370,7 @@ providing_technologies = ["Amazon Web Services - Cloudtrail"] type = detection asset_type = Google Cloud Platform tenant confidence = medium -explanation = The following analytic identifies an authentication attempt event against a Google Cloud Platform tenant that fails during the Multi Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +explanation = The following analytic detects failed authentication attempts during the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) tenant. It uses Google Workspace login failure events to identify instances where MFA methods were challenged but not successfully completed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials despite MFA protection. If confirmed malicious, this could lead to unauthorized access attempts, potentially compromising sensitive data and resources within the GCP environment. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. @@ -2423,7 +2400,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GCP confidence = medium -explanation = The following analytic identifies an attempt to disable multi-factor authentication for a GCP user. An adversary who has obtained access to an GCP tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +explanation = The following analytic detects an attempt to disable multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin log events, specifically the `UNENROLL_USER_FROM_STRONG_AUTH` command. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised account without raising suspicion. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access, data exfiltration, or further exploitation of the compromised account. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the Admin log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]} known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed. @@ -2433,7 +2410,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = Google Cloud Platform tenant confidence = medium -explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a Google Cloud Platform tenant. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google CLoud tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +explanation = The following analytic detects multiple failed multi-factor authentication (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. It triggers when 10 or more MFA prompts fail within a 5-minute window, using Google Workspace login failure events. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise accounts and potentially escalate privileges within the GCP environment. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `mfa_prompts` threshold values according to your environment. Specifically, this analytic leverages the User log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. @@ -2443,7 +2420,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = Google Cloud Platform tenant confidence = medium -explanation = The following analytic identifies one source Ip failing to authenticate into the Google Workspace user accounts with more than 20 unique valid users within 5 minutes. These user accounts may have other privileges with respect to access to other sensitive resources in the Google Cloud Platform. This behavior could represent an adversary performing a Password Spraying attack against an Google Workspace environment to obtain initial access or elevate privileges. +explanation = The following analytic detects a single source IP address failing to authenticate into more than 20 unique Google Workspace user accounts within a 5-minute window. It leverages Google Workspace login failure events to identify potential password spraying attacks. This activity is significant as it may indicate an adversary attempting to gain unauthorized access or elevate privileges within the Google Cloud Platform. If confirmed malicious, this behavior could lead to unauthorized access to sensitive resources, data breaches, or further exploitation within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = No known false postives for this detection. Please review this alert. @@ -2453,7 +2430,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = Google Cloud Platform tenant confidence = medium -explanation = The following analytic identifies a successful authentication event against Google Cloud Platform for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +explanation = The following analytic identifies a successful single-factor authentication event against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication (MFA) enabled. It uses Google Workspace login event data to detect instances where MFA is not utilized. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to GCP resources, potentially leading to data breaches, service disruptions, or further exploitation within the cloud environment. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed @@ -2463,7 +2440,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = Google Cloud Platform tenant confidence = medium -explanation = The following analytic identifies one source IP failing to authenticate into the Google Workspace with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against a Google Workspace enviroment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `GCP Multiple Users Failing To Authenticate From Ip` +explanation = The following analytic identifies a single source IP failing to authenticate into Google Workspace with multiple valid users, potentially indicating a Password Spraying attack. It uses Google Workspace login failure events and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation within the environment. how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = No known false positives for this detection. Please review this alert @@ -2493,7 +2470,7 @@ providing_technologies = null type = detection asset_type = GitHub confidence = medium -explanation = This search is to detect a pushed or commit to master or main branch. This is to avoid unwanted modification to master without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +explanation = The following analytic detects direct commits or pushes to the master or main branch in a GitHub repository. It leverages GitHub logs to identify events where changes are made directly to these critical branches. This activity is significant because direct modifications to the master or main branch bypass the standard review process, potentially introducing unreviewed and harmful changes. If confirmed malicious, this could lead to unauthorized code execution, security vulnerabilities, or compromised project integrity. how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]} known_false_positives = Admin can do changes directly to master branch @@ -2503,7 +2480,7 @@ providing_technologies = null type = detection asset_type = GitHub confidence = medium -explanation = This search is to detect a pushed or commit to develop branch. This is to avoid unwanted modification to develop without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +explanation = The following analytic detects commits pushed directly to the 'develop' or 'main' branches in a GitHub repository. It leverages GitHub logs, focusing on commit metadata such as author details, commit messages, and timestamps. This activity is significant as direct commits to these branches can bypass the review process, potentially introducing unvetted changes. If confirmed malicious, this could lead to unauthorized code modifications, introducing vulnerabilities or backdoors into the codebase, and compromising the integrity of the development lifecycle. how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]} known_false_positives = admin can do changes directly to develop branch @@ -2513,7 +2490,7 @@ providing_technologies = null type = detection asset_type = GitHub confidence = medium -explanation = The following analytic is made by first searching for logs that contain the action "create" and renames certain fields for easier analysis. Then, this analytic uses the "stats" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The "phase" field is set to "code" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the "create" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps. +explanation = The following analytic identifies the creation of GitHub Dependabot alerts, which indicate potential vulnerabilities in the codebase. It detects this activity by searching for logs with the "create" action and analyzing fields such as affected package, severity, and fixed version. This detection is significant for a SOC because it helps identify and address security risks in the codebase proactively. If confirmed malicious, these vulnerabilities could be exploited by attackers to gain unauthorized access or cause breaches, leading to potential data loss or system compromise. how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2523,7 +2500,7 @@ providing_technologies = null type = detection asset_type = GitHub confidence = medium -explanation = The following analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request." +explanation = The following analytic detects pull requests from unknown users on GitHub. It uses a Splunk query to identify pull requests where the user ID is not specified and cross-references these with a known users lookup table. This activity is significant because pull requests from unknown users can introduce malicious code or unauthorized changes to repositories. If confirmed malicious, this could lead to unauthorized code changes, data breaches, or other security incidents. Immediate steps include reviewing the author's name, repository, head reference, and commit message, and investigating any related artifacts and processes. how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2533,7 +2510,7 @@ providing_technologies = null type = detection asset_type = GSuite confidence = medium -explanation = This search is to detect suspicious google drive or google docs files shared outside or externally. This behavior might be a good hunting query to monitor exfitration of data made by an attacker or insider to a targetted machine. +explanation = The following analytic detects Google Drive or Google Docs files shared externally from an internal domain. It leverages GSuite Drive logs, extracting and comparing the source and destination email domains to identify external sharing. This activity is significant as it may indicate potential data exfiltration by an attacker or insider. If confirmed malicious, this could lead to unauthorized access to sensitive information, data leakage, and potential compliance violations. Monitoring this behavior helps in early detection and mitigation of data breaches. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567.002", "T1567"], "nist": ["DE.AE"]} known_false_positives = network admin or normal user may share files to customer and external team. @@ -2543,7 +2520,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GSuite confidence = medium -explanation = This search is to detect a suspicious attachment file extension in Gsuite email that may related to spear phishing attack. This file type is commonly used by malware to lure user to click on it to execute malicious code to compromised targetted machine. But this search can also catch some normal files related to this file type that maybe send by employee or network admin. +explanation = The following analytic detects suspicious attachment file extensions in GSuite emails, potentially indicating a spear-phishing attack. It leverages GSuite Gmail logs to identify emails with attachments having file extensions commonly associated with malware, such as .exe, .bat, and .js. This activity is significant as these file types are often used to deliver malicious payloads, posing a risk of compromising targeted machines. If confirmed malicious, this could lead to unauthorized code execution, data breaches, or further network infiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack. @@ -2553,7 +2530,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GSuite confidence = medium -explanation = This search is to detect a gsuite email contains suspicious subject having known file type used in spear phishing. This technique is a common and effective entry vector of attacker to compromise a network by luring the user to click or execute the suspicious attachment send from external email account because of the effective social engineering of subject related to delivery, bank and so on. On the other hand this detection may catch a normal email traffic related to legitimate transaction so better to check the email sender, spelling and etc. avoid click link or opening the attachment if you are not expecting this type of e-mail. +explanation = The following analytic identifies Gsuite emails with suspicious subjects and attachments commonly used in spear phishing attacks. It leverages Gsuite email logs, focusing on specific keywords in the subject line and known malicious file types in attachments. This activity is significant for a SOC as spear phishing is a prevalent method for initial compromise, often leading to further malicious actions. If confirmed malicious, this activity could result in unauthorized access, data exfiltration, or further malware deployment, posing a significant risk to the organization's security. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search. @@ -2563,7 +2540,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GSuite confidence = medium -explanation = This analytics is to detect a gmail containing a link that are known to be abused by malware or attacker like pastebin, telegram and discord to deliver malicious payload. This event can encounter some normal email traffic within organization and external email that normally using this application and services. +explanation = The following analytic detects emails in Gsuite containing links to known abuse web services such as Pastebin, Telegram, and Discord. It leverages Gsuite Gmail logs to identify emails with these specific domains in their links. This activity is significant because these services are commonly used by attackers to deliver malicious payloads. If confirmed malicious, this could lead to the delivery of malware, phishing attacks, or other harmful activities, potentially compromising sensitive information or systems within the organization. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = normal email contains this link that are known application within the organization or network can be catched by this detection. @@ -2573,7 +2550,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GSuite confidence = medium -explanation = This search is to detect a suspicious outbound e-mail from internal email to external email domain. This can be a good hunting query to monitor insider or outbound email traffic for not common domain e-mail. The idea is to parse the domain of destination email check if there is a minimum outbound traffic < 20 with attachment. +explanation = The following analytic detects outbound emails with attachments sent from an internal email domain to an external domain. It leverages Gsuite Gmail logs, parsing the source and destination email domains, and flags emails with fewer than 20 outbound instances. This activity is significant as it may indicate potential data exfiltration or insider threats. If confirmed malicious, an attacker could use this method to exfiltrate sensitive information, leading to data breaches and compliance violations. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]} known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack. @@ -2593,7 +2570,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = GSuite confidence = medium -explanation = This search is to detect a shared file in google drive with suspicious file name that are commonly used by spear phishing campaign. This technique is very popular to lure the user by running a malicious document or click a malicious link within the shared file that will redirected to malicious website. This detection can also catch some normal email communication between organization and its external customer. +explanation = The following analytic detects shared files in Google Drive with suspicious filenames commonly used in spear phishing campaigns. It leverages GSuite Drive logs to identify documents with titles that include keywords like "dhl," "ups," "invoice," and "shipment." This activity is significant because such filenames are often used to lure users into opening malicious documents or clicking harmful links. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further compromise of the user's system. how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search @@ -2603,7 +2580,7 @@ providing_technologies = ["Google Cloud Platform", "Google Workspace"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. Specifically, it identifies scenarios where there are more than 10 unsuccessful login attempts within a short time frame. The detection leverages Office365 management activity logs, specifically the AzureActiveDirectoryStsLogon records from the AzureActiveDirectory workload. It aggregates these logs in 5-minute intervals to count the number of failed login attempts and associates them with the originating source IP address. Multiple failed login attempts from a single source can be indicative of brute-force attacks, password spraying, or other malicious authentication attempts. Identifying and responding to these patterns promptly can prevent unauthorized access and potential breaches. If this detection represents a true positive, an attacker might be attempting to gain unauthorized access to an Office365 account. Successful compromise could lead to unauthorized access to sensitive data, potential lateral movement within the organization, or further malicious activities using the compromised account. +explanation = The following analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. It leverages Office365 management activity logs, specifically AzureActiveDirectoryStsLogon records, aggregating these logs in 5-minute intervals to count failed login attempts. This activity is significant as it may indicate brute-force attacks or password spraying, which are critical to monitor. If confirmed malicious, an attacker could gain unauthorized access to Office365 accounts, leading to potential data breaches, lateral movement within the organization, or further malicious activities using the compromised account. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. Adjust the threshold value to suit the specific environment, as environments with naturally higher login failures might generate false positives at a lower threshold. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.001", "T1110"], "nist": ["DE.AE"]} known_false_positives = An Ip address with more than 10 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. @@ -2613,7 +2590,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by country. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests by country. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2623,7 +2600,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user agent. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user agents. This activity is significant for a SOC because Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of critical information. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2633,7 +2610,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user group. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests and user groups. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2643,7 +2620,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user name. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user names. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of sensitive information. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2653,7 +2630,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities. The analytic detects this behavior by monitoring Kubernetes audit logs for patterns indicative of scanning, such as repeated failed access attempts or unusual API requests. This behavior is worth identifying for a SOC as it could indicate an attackers preliminary step in an attack, aiming to gather information about the system to find potential vulnerabilities. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities by monitoring Kubernetes audit logs for repeated failed access attempts or unusual API requests. This activity is significant for a SOC as it may indicate an attacker's preliminary reconnaissance to gather information about the system. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, posing a severe security risk. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2663,11 +2640,9 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This detection detects inbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly.This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for destination (receiving) workload process pairs over the last 1 hour, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high inbound network activity. Anomalies in inbound network traffic may suggest that the container is receiving unexpected or unauthorized data, potentially indicative of a breach, a vulnerability exploitation attempt, an attempt to overload the service, or propagation of malware. Successful compromise of a containerised application resulting in the ability to upload data, can result in installation of command and control software or other malware, data integrity damage, container escape, and further compromise of the environment. Additionally this kind of activity may result in resource contention, performance degradation and disruption to the normal operation of the environment. +explanation = The following analytic identifies anomalous inbound network traffic volumes from processes within containerized workloads. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days. This activity is significant as it may indicate unauthorized data reception, potential breaches, vulnerability exploitation, or malware propagation. If confirmed malicious, it could lead to command and control installation, data integrity damage, container escape, and further environment compromise. how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2677,7 +2652,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, financial losses, and reputational damage. +explanation = The following analytic identifies high inbound or outbound network I/O anomalies in Kubernetes containers. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. A lookup table with average and standard deviation values for network I/O is used to detect anomalies persisting over a 1-hour period. This activity is significant as it may indicate data exfiltration, command and control communication, or unauthorized data transfers. If confirmed malicious, it could lead to data breaches, service outages, financial losses, and reputational damage. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2698,7 +2673,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster. +explanation = The following analytic identifies significant changes in network communication behavior within Kubernetes containers by examining the inbound to outbound network IO ratios. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. Anomalies are detected using a lookup table containing average and standard deviation values for network IO, triggering an event if the anomaly persists for over an hour. This activity is significant as it may indicate data exfiltration, command and control communication, or compromised container behavior. If confirmed malicious, it could lead to data breaches, service outages, and unauthorized access within the Kubernetes cluster. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2719,11 +2694,9 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This detection detects outbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for source (transmitting) workload process pairs over the last 1 hout, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high outbound network activity. Anonymously high outbound network traffic from a process running in a container is a potential indication of data exfiltration, or an indication that the process has been modified. Anomalously high outbound network activity from a process running within a container suggests the potential compromise, which may lead to unauthorized data exfiltration, communication with malicious entities, or the propagation of malware to external systems. The compromised container could also serve as a pivot point for further attacks within the containerized environment. +explanation = The following analytic identifies anomalously high outbound network activity from processes running within containerized workloads in a Kubernetes environment. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average metrics over the past 30 days. This activity is significant as it may indicate data exfiltration, process modification, or container compromise. If confirmed malicious, it could lead to unauthorized data exfiltration, communication with malicious entities, or further attacks within the containerized environment. how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2733,11 +2706,9 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This detection detects network traffic volume anomalies between workloads in a microservices hosted application, or between a workload and the outside world if the workload is shown as (unknown). This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics between workloads over the last 1 hour, with the average of those metrics over the last 30 days in order to detect any anonymously high inbound or outbound network activity. Unexpected spikes in network traffic may signify unauthorized data transfers, or abnormal behavior within the microservices ecosystem. Such activity might signify data exfiltration, unauthorized lateral movement, within the microservices environment. If a bad actor is responsible for this traffic they could compromise additional services or extract sensitive data, potentially leading to data breaches. +explanation = The following analytic identifies anomalous network traffic volumes between Kubernetes workloads or between a workload and external sources. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days to identify significant deviations. This activity is significant as unexpected spikes may indicate unauthorized data transfers or lateral movement. If confirmed malicious, it could lead to data exfiltration or compromise of additional services, potentially resulting in data breaches. how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2747,7 +2718,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring for API calls from users who have not provided any token or password in their request. This is a significant behavior to identify for a SOC as it indicates a severe misconfiguration that allows unfettered access to a cluster with no traceability to a user or service. The impact of such an attack could be substantial, potentially granting an attacker access to sensitive data or control over the cluster. This detection rule is crucial for maintaining the security and integrity of your Kubernetes infrastructure. +explanation = The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring API calls from users who have not provided any token or password in their request, using data from `kube_audit` logs. This activity is significant for a SOC as it indicates a severe misconfiguration, allowing unfettered access to the cluster with no traceability. If confirmed malicious, an attacker could gain access to sensitive data or control over the cluster, posing a substantial security risk. how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = Kubectl calls are not malicious by nature. However source IP, verb and Object can reveal potential malicious activity, specially anonymous suspicious IPs and sensitive objects such as configmaps or secrets @@ -2757,7 +2728,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of privileged pods in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation of pods with root privileges. This behavior is worth identifying for a SOC as it could potentially allow an attacker to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +explanation = The following analytic detects the creation or update of privileged pods in Kubernetes. It identifies this activity by monitoring Kubernetes Audit logs for pod configurations that include root privileges. This behavior is significant for a SOC as it could indicate an attempt to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, data breaches, and service disruptions, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2767,7 +2738,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of a Kubernetes cron job, a task scheduled to run automatically at specified intervals. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a cron job. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute malicious tasks repeatedly and automatically, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +explanation = The following analytic detects the creation of a Kubernetes cron job, which is a task scheduled to run automatically at specified intervals. It identifies this activity by monitoring Kubernetes Audit logs for the creation events of cron jobs. This behavior is significant for a SOC as it could allow an attacker to execute malicious tasks repeatedly and automatically, posing a threat to the Kubernetes infrastructure. If confirmed malicious, this activity could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.007"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2777,7 +2748,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. A DaemonSet ensures the presence of a specific pod on every node in the cluster, making it an ideal avenue for persistent access. This behavior is identified by monitoring Kubernetes Audit logs for the creation of a DaemonSet. The identified behavior is worth noting for a SOC as it could potentially allow an attacker to maintain persistent access to the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +explanation = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. This behavior is identified by monitoring Kubernetes Audit logs for the creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, making them a potential vector for persistent access. This activity is significant for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes infrastructure. If confirmed malicious, it could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2787,7 +2758,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects instances where a shell is spawned within a Kubernetes container, a behavior often indicative of an attacker gaining unauthorized access. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment, flagging when a shell is spawned in a container. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +explanation = The following analytic detects instances where a shell is spawned within a Kubernetes container. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment and flags when a shell is spawned. This activity is significant for a SOC as it may indicate unauthorized access, allowing an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges. If confirmed malicious, this could lead to data breaches, service disruptions, or unauthorized access to sensitive information, severely impacting the Kubernetes infrastructure's integrity and security. how_to_implement = The detection is based on data that originates from Falco, a cloud native runtime security tool. Falco is designed to detect anomalous activity in your applications and is a crucial component of this detection rule. To implement this detection rule, you need to install and configure Falco in your Kubernetes environment. Once Falco is set up, it will monitor the system calls in your Kubernetes infrastructure and generate logs for any suspicious activity. These logs are then ingested by Splunk for analysis. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2797,11 +2768,9 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic detects TCP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +explanation = The following analytic identifies newly seen TCP communication between source and destination workload pairs within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares network activity over the last hour with the past 30 days to spot new inter-workload communications. This is significant as new connections can indicate changes in application behavior or potential security threats. If malicious, unauthorized connections could lead to data breaches, privilege escalation, lateral movement, or disruption of critical services, compromising the application's integrity, availability, and confidentiality. how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2811,11 +2780,9 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic detects UDP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +explanation = The following analytic detects UDP communication between a newly seen source and destination workload pair within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. This detection compares network activity over the last hour with the past 30 days to identify new inter-workload communication. Such changes in network behavior can indicate potential security threats or anomalies. If confirmed malicious, unauthorized connections may enable attackers to infiltrate the application ecosystem, leading to data breaches, privilege escalation, lateral movement, or disruption of critical services. how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2845,7 +2812,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of a Kubernetes node port service, an action that exposes a service to the external network. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a Node Port service. This behavior is worth identifying for a SOC as it could potentially allow an attacker to access internal services, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +explanation = The following analytic detects the creation of a Kubernetes NodePort service, which exposes a service to the external network. It identifies this activity by monitoring Kubernetes Audit logs for the creation of NodePort services. This behavior is significant for a SOC as it could allow an attacker to access internal services, posing a threat to the Kubernetes infrastructure's integrity and security. If confirmed malicious, this activity could lead to data breaches, service disruptions, or unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2855,7 +2822,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of pods in the default, kube-system, or kube-public namespaces. It identifies this behavior by monitoring Kubernetes audit logs for pod creation events in these namespaces. This behavior is worth identifying for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Only administrators should typically create pods in the kube-system namespace, and the default and kube-public namespaces should not be used in production. The impact of the attack could be significant, as it may indicate a successful cluster breach and ongoing malicious activity. +explanation = The following analytic detects the creation of Kubernetes pods in the default, kube-system, or kube-public namespaces. It leverages Kubernetes audit logs to identify pod creation events within these specific namespaces. This activity is significant for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Unauthorized pod creation in these namespaces can suggest a successful cluster breach, potentially leading to privilege escalation, persistent access, or further malicious activities within the cluster. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2865,7 +2832,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects the creation of a pod with host network attachment in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation or update of pods with host network configuration. This behavior is worth identifying for a SOC as it could potentially allow an attacker to listen to all network traffic on the node and other compute on the network namespace, capturing secrets passed in arguments or connections to escalate their privileges. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +explanation = The following analytic detects the creation or update of a Kubernetes pod with host network attachment. It leverages Kubernetes Audit logs to identify pods configured with host network settings. This activity is significant for a SOC as it could allow an attacker to monitor all network traffic on the node, potentially capturing sensitive information and escalating privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, and service disruptions, severely impacting the security and integrity of the Kubernetes environment. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -2875,7 +2842,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic identifies containerised workloads that have been created using a previously unseen image. This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster +explanation = The following analytic identifies the creation of containerized workloads using previously unseen images in a Kubernetes cluster. It leverages process metrics from an OTEL collector and Kubernetes cluster receiver, pulled from Splunk Observability Cloud. The detection compares container image names seen in the last hour with those from the previous 30 days. This activity is significant as unfamiliar container images may introduce vulnerabilities, malware, or misconfigurations, posing threats to the cluster's integrity. If confirmed malicious, compromised images can lead to data breaches, service disruptions, unauthorized access, and potential lateral movement within the cluster. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2896,7 +2863,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and anomalies that could be related to unauthorized activity. New processes may be introduced in an attempt to compromise the node or gain control of the Kubernetes cluster. By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk. The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity. +explanation = The following analytic detects previously unseen processes within the Kubernetes environment on master or worker nodes. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud. This detection compares processes observed in the last hour against those seen in the previous 30 days. Identifying new processes is crucial as they may indicate unauthorized activity or attempts to compromise the node. If confirmed malicious, these processes could lead to data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware, posing significant risks to the Kubernetes cluster. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2917,7 +2884,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software. If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster. +explanation = The following analytic identifies processes running from newly seen paths within a Kubernetes environment. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud using the Splunk Infrastructure Monitoring Add-on. This detection compares processes observed in the last hour with those seen over the previous 30 days. This activity is significant as it may indicate unauthorized changes, compromised nodes, or the introduction of malicious software. If confirmed malicious, it could lead to unauthorized process execution, control over critical resources, data exfiltration, privilege escalation, or malware introduction within the Kubernetes cluster. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2938,7 +2905,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. +explanation = The following analytic identifies high resource utilization anomalies in Kubernetes processes. It leverages process metrics from an OTEL collector and hostmetrics receiver, fetched via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values to spot anomalies. This activity is significant as high resource utilization can indicate security threats like cryptojacking, unauthorized data exfiltration, or compromised containers. If confirmed malicious, such anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2959,7 +2926,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios. This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load. Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container. +explanation = The following analytic detects anomalous changes in resource utilization ratios for processes running on a Kubernetes node. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, analyzed through Splunk Observability Cloud. The detection uses a lookup table containing average and standard deviation values for various resource ratios (e.g., CPU:memory, CPU:disk operations). Significant deviations from these baselines may indicate compromised processes, malicious activity, or misconfigurations. If confirmed malicious, this could signify a security breach, allowing attackers to manipulate workloads, potentially leading to data exfiltration or service disruption. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -2990,7 +2957,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This detection rule is designed to identify potential scanning activities within a Kubernetes environment. Scanning is a common preliminary step in an attack, where the attacker tries to gather information about the system to find potential vulnerabilities. In the context of Kubernetes, scanning could involve activities like unauthorized access attempts, probing public APIs, or trying to exploit known vulnerabilities. This rule triggers an alert when such suspicious activities are detected, helping to ensure the security of your Kubernetes infrastructure. +explanation = The following analytic identifies potential scanning activities within a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) from the same source IP. This activity is significant as it may indicate an attacker probing for vulnerabilities or attempting to exploit known issues. If confirmed malicious, such scanning could lead to unauthorized access, data breaches, or further exploitation of the Kubernetes infrastructure, compromising the security and integrity of the environment. how_to_implement = You must ingest Kubernetes audit logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -3000,7 +2967,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data. +explanation = The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It leverages process metrics from an OTEL collector hostmetrics receiver, specifically process.cpu.utilization and process.memory.utilization, pulled from Splunk Observability Cloud. This activity is significant as unauthorized shell processes can indicate potential security threats, providing attackers an entry point to compromise the node and the entire Kubernetes cluster. If confirmed malicious, this activity could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks, severely compromising the cluster's security and integrity. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -3021,7 +2988,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach. +explanation = The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node, specifically when shell processes are consuming CPU resources. It leverages process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability Cloud via the Splunk Infrastructure Monitoring Add-on, focusing on process.cpu.utilization and process.memory.utilization. This activity is significant as unauthorized shell processes can indicate a security threat, potentially compromising the node and the entire Kubernetes cluster. If confirmed malicious, attackers could gain full control over the host's resources, leading to data theft, service disruption, privilege escalation, and further attacks within the cluster. how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -3042,7 +3009,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects instances of suspicious image pulling in Kubernetes. It identifies this behavior by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to deploy malicious software or infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects suspicious image pulling in Kubernetes environments. It identifies this activity by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is significant for a SOC as it may indicate an attacker attempting to deploy malicious software or infiltrate the system. If confirmed malicious, the impact could be severe, potentially leading to unauthorized access to sensitive systems or data, and enabling further malicious activities within the cluster. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -3052,7 +3019,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = Kubernetes confidence = medium -explanation = The following analytic detects unauthorized access to Kubernetes by monitoring Kubernetes audit logs. It identifies anomalies in access patterns by segmenting and analyzing the source of requests. Unauthorized access is worth identifying for a SOC as it could indicate an attacker attempting to infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +explanation = The following analytic detects unauthorized access attempts to Kubernetes by analyzing Kubernetes audit logs. It identifies anomalies in access patterns by examining the source of requests and their response statuses. This activity is significant for a SOC as it may indicate an attacker attempting to infiltrate the Kubernetes environment. If confirmed malicious, such access could lead to unauthorized control over Kubernetes resources, potentially compromising sensitive systems or data within the cluster. how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -3062,7 +3029,7 @@ providing_technologies = ["Kubernetes"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, providing an additional layer of security for your environment. +explanation = The following analytic detects the addition of an application role assignment grant to a user in Office 365. It leverages data from the `o365_management_activity` dataset, specifically monitoring the "Add app role assignment grant to user" operation. This activity is significant as it can indicate unauthorized privilege escalation or the assignment of sensitive roles to users. If confirmed malicious, this could allow an attacker to gain elevated permissions, potentially leading to unauthorized access to critical resources and data within the Office 365 environment. how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} known_false_positives = The creation of a new Federation is not necessarily malicious, however this events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider. @@ -3072,7 +3039,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization. +explanation = The following analytic detects the addition of new service principal accounts in O365 tenants. It leverages data from the `o365_management_activity` dataset, specifically monitoring for operations related to adding or creating service principals. This activity is significant because attackers can exploit service principals to gain unauthorized access and perform malicious actions within an organization's environment. If confirmed malicious, this could allow attackers to interact with APIs, access resources, and execute operations on behalf of the organization, potentially leading to data breaches or further compromise. how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} known_false_positives = The creation of a new Federation is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider. @@ -3082,7 +3049,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions. +explanation = The following analytic identifies instances where a service principal in Office 365 Azure Active Directory assigns app roles without standard admin consent. It leverages `o365_management_activity` logs, specifically focusing on the 'Add app role assignment to service principal' operation. This activity is significant for SOCs as it may indicate a bypass of critical administrative controls, potentially leading to unauthorized access or privilege escalation. If confirmed malicious, this could allow an attacker to misuse automated processes to assign sensitive permissions, compromising the security of the environment. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. @@ -3092,7 +3059,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail. +explanation = The following analytic detects instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It uses O365 audit logs, focusing on events related to audit license changes in AzureActiveDirectory workloads. This activity is significant because the O365 advanced audit provides critical logging and insights into user and administrator activities. Disabling it can blind security teams to potential malicious actions. If confirmed malicious, attackers could operate within the user's mailbox or account with reduced risk of detection, leading to unauthorized data access, data exfiltration, or account compromise. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} known_false_positives = Administrators might temporarily disable the advanced audit for troubleshooting, performance reasons, or other administrative tasks. Filter as needed. @@ -3102,7 +3069,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations +explanation = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload. This activity is significant because assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. If confirmed malicious, an attacker could modify the application's settings, permissions, and behavior, leading to unauthorized data access, privilege escalation, or the introduction of malicious behavior within the application's operations. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = Application owners may be added for legitimate reasons, filter as needed. @@ -3112,7 +3079,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization. +explanation = The following analytic detects the assignment of the ApplicationImpersonation role in Office 365 to a user or application. It uses the Office 365 Management Activity API to monitor Azure Active Directory audit logs for role assignment events. This activity is significant because the ApplicationImpersonation role allows impersonation of any user, enabling access to and modification of their mailbox. If confirmed malicious, an attacker could gain unauthorized access to sensitive information, manipulate mailbox data, and perform actions as a legitimate user, posing a severe security risk to the organization. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} known_false_positives = While infrequent, the ApplicationImpersonation role may be granted for leigimate reasons, filter as needed. @@ -3122,7 +3089,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization. +explanation = The following analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats, allowing users to grant consent to malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]} known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization. @@ -3132,7 +3099,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications. +explanation = The following analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. It leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. This activity is significant because adding trusted IPs can weaken the security posture by bypassing MFA, which is a critical security control. If confirmed malicious, this could lead to unauthorized access, compromising sensitive information and systems. Immediate investigation is required to validate the legitimacy of the IP addition. how_to_implement = You must install Splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} known_false_positives = Unless it is a special case, it is uncommon to continually update Trusted IPs to MFA configuration. @@ -3142,7 +3109,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations. +explanation = The following analytic identifies when the results of a content search within the Office 365 Security and Compliance Center are exported. It uses the SearchExported operation from the SecurityComplianceCenter workload in the o365_management_activity data source. This activity is significant because exporting search results can involve sensitive or critical organizational data, potentially leading to data exfiltration. If confirmed malicious, an attacker could gain access to and exfiltrate sensitive information, posing a severe risk to the organization's data security and compliance posture. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} known_false_positives = Compliance content searche exports may be executed for legitimate purposes, filter as needed. @@ -3152,7 +3119,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations. +explanation = The following analytic detects when a content search is initiated within the Office 365 Security and Compliance Center. It leverages the SearchCreated operation from the o365_management_activity logs under the SecurityComplianceCenter workload. This activity is significant as it may indicate an attempt to access sensitive organizational data, including emails and documents. If confirmed malicious, this could lead to unauthorized data access, potential data exfiltration, and compliance violations. Monitoring this behavior helps ensure the integrity and security of organizational data. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} known_false_positives = Compliance content searches may be executed for legitimate purposes, filter as needed. @@ -3162,7 +3129,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. +explanation = The following analytic identifies user sessions in Office 365 accessed from multiple IP addresses, indicating potential adversary-in-the-middle (AiTM) phishing attacks. It detects this activity by analyzing Azure Active Directory logs for 'UserLoggedIn' operations and flags sessions with more than one associated IP address. This behavior is significant as it suggests unauthorized concurrent access, which is uncommon in normal usage. If confirmed malicious, the impact could include data theft, account takeover, and the launching of internal phishing campaigns, posing severe risks to organizational security. how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -3172,7 +3139,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. +explanation = The following analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to MFA settings. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. If confirmed malicious, this activity could indicate an attacker attempting to maintain persistence or an insider threat, significantly increasing the risk of unauthorized access. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. how_to_implement = You must install the Splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.CM"]} known_false_positives = Unless it is a special case, it is uncommon to disable MFA or Strong Authentication @@ -3182,7 +3149,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls. +explanation = The following analytic identifies the assignment of elevated mailbox permissions in an Office 365 environment via the Add-MailboxPermission operation. It leverages logs from the Exchange workload in the o365_management_activity data source, focusing on permissions such as FullAccess, ChangePermission, or ChangeOwner. This activity is significant as it indicates potential unauthorized access or control over mailboxes, which could lead to data exfiltration or privilege escalation. If confirmed malicious, attackers could gain extensive access to sensitive email data and potentially manipulate mailbox settings, posing a severe security risk. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} known_false_positives = FullAccess mailbox delegation may be assigned for legitimate purposes, filter as needed. @@ -3212,7 +3179,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted. +explanation = The following analytic identifies instances where a user in the Office 365 environment grants consent to an application requesting file permissions for OneDrive or SharePoint. It leverages O365 audit logs, focusing on OAuth application consent events. This activity is significant because granting such permissions can allow applications to access, modify, or delete files, posing a risk if the application is malicious or overly permissive. If confirmed malicious, this could lead to data breaches, data loss, or unauthorized data manipulation, necessitating immediate investigation to validate the application's legitimacy and assess potential risks. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = OAuth applications that require file permissions may be legitimate, investigate and filter as needed. @@ -3222,7 +3189,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss. +explanation = The following analytic detects the assignment of the 'full_access_as_app' permission to an application registration in Office 365 Exchange Online. This detection leverages Office 365 management activity logs and filters Azure Active Directory workload events to identify when the specific permission, identified by GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is granted. This activity is significant because it provides extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. If confirmed malicious, this could lead to unauthorized data access, exfiltration, or account compromise. Immediate investigation is required. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. @@ -3232,7 +3199,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data. +explanation = The following analytic identifies an O365 account experiencing more than 20 failed authentication attempts within 5 minutes. It uses O365 Unified Audit Logs, specifically "UserLoginFailed" events, to monitor and flag accounts exceeding this threshold. This activity is significant as it may indicate a brute force attack or password guessing attempt. If confirmed malicious, an attacker could gain unauthorized access to the O365 environment, potentially compromising sensitive emails, documents, and other data. Prompt investigation and action are crucial to prevent unauthorized access and data breaches. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]} known_false_positives = Although unusual, users who have lost their passwords may trigger this detection. Filter as needed. @@ -3242,7 +3209,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment. +explanation = The following analytic detects when high-privilege roles such as "Exchange Administrator," "SharePoint Administrator," or "Global Administrator" are granted within Office 365. It leverages O365 audit logs to identify events where these roles are assigned to any user or service account. This activity is significant for SOCs as these roles provide extensive permissions, allowing broad access and control over critical resources and data. If confirmed malicious, this could enable attackers to gain significant control over O365 resources, access, modify, or delete critical data, and compromise the overall security and functionality of the O365 environment. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Privilege roles may be assigned for legitimate purposes, filter as needed. @@ -3252,7 +3219,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities. +explanation = The following analytic identifies instances where a user grants consent to an application requesting mail-related permissions within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to application permissions and user consent actions. This activity is significant as it can indicate potential security risks, such as data exfiltration or spear phishing, if malicious applications gain access. If confirmed malicious, this could lead to unauthorized data access, email forwarding, or sending malicious emails from the compromised account. Validating the legitimacy of the application and consent context is crucial to prevent data breaches. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. @@ -3262,7 +3229,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox. +explanation = The following analytic identifies instances where email forwarding has been enabled on mailboxes within an Office 365 environment. It detects this activity by monitoring the Set-Mailbox operation within the o365_management_activity logs, specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress parameters. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} known_false_positives = Email forwarding may be configured for legitimate purposes, filter as needed. @@ -3272,7 +3239,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders. +explanation = The following analytic identifies instances where read permissions are assigned to mailbox folders within an Office 365 environment. It leverages the `o365_management_activity` data source, specifically monitoring the `ModifyFolderPermissions` and `AddFolderPermissions` operations, while excluding Calendar, Contacts, and PersonMetadata objects. This activity is significant as unauthorized read permissions can lead to data exposure and potential information leakage. If confirmed malicious, an attacker could gain unauthorized access to sensitive emails, leading to data breaches and compromising the confidentiality of organizational communications. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed. @@ -3282,7 +3249,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents. +explanation = The following analytic identifies instances where read permissions are granted to mailbox folders within an Office 365 environment. It detects this activity by monitoring the `o365_management_activity` data source for the `Set-MailboxFolderPermission` and `Add-MailboxFolderPermission` operations. This behavior is significant as it may indicate unauthorized access or changes to mailbox folder permissions, potentially exposing sensitive email content. If confirmed malicious, an attacker could gain unauthorized access to read email communications, leading to data breaches or information leakage. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed. @@ -3292,7 +3259,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox. +explanation = The following analytic detects instances where the inbox folder of an Office 365 mailbox is shared with all users within the tenant. It leverages Office 365 management activity events to identify when the 'Inbox' folder permissions are modified to include 'Everyone' with read rights. This activity is significant as it represents a potential security risk, allowing unauthorized access to sensitive emails. If confirmed malicious, this could lead to data breaches, exfiltration of confidential information, and further compromise through spear-phishing or other malicious activities based on the accessed email content. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} known_false_positives = Administrators might temporarily share a mailbox with all users for legitimate reasons, such as troubleshooting, migrations, or other administrative tasks. Some organizations use shared mailboxes for teams or departments where multiple users need access to the same mailbox. Filter as needed. @@ -3302,7 +3269,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such access and that any inadvertent or malicious assignments are promptly identified. If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. +explanation = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. This activity is significant because the Mail.Read permission allows applications to access and read all emails within a user's mailbox, which often contain sensitive or confidential information. If confirmed malicious, this could lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1114.002", "T1114", "T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = There are legitimate scenarios in wich an Application registrations requires Mailbox read access. Filter as needed. @@ -3312,7 +3279,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects potential distributed password spraying attacks within an Office 365 environment. It identifies a significant increase in failed authentication attempts characterized by diverse user-and-IP address combinations, originating from multiple source IP addresses, and utilizing various user agents. These patterns may indicate an adversary's attempt to circumvent security controls by employing a spectrum of IP addresses to test commonly used passwords against a wide range of user accounts. The detection examines UserLoginFailed events from O365 Management Activity logs, with a particular focus on events with ErrorNumber 50126, which indicates a failed authentication due to incorrect credentials. By aggregating data over a five-minute interval, the analytic calculates the distinct counts of user-and-IP combinations and unique users and source IPs. It then applies a set of thresholds to these metrics to identify abnormal activities that could suggest a coordinated attack. The predefined thresholds within the analytic (such as unique IPs, unique users, etc.) serve as initial benchmarks and should be tailored to align with the organization's typical user behavior and risk tolerance. Early detection of such distributed activities is crucial for security operations centers (SOCs) to intercept unauthorized access attempts, avert account takeovers, and reduce the risk of subsequent malevolent actions within the organization's systems. A true positive alert from this analytic would indicate an ongoing distributed password spraying campaign targeting the organization's Office 365 tenant. If such an attack is successful, it could lead to unauthorized access, especially to accounts with administrative privileges, resulting in data breaches, privilege escalation, persistent threats, and lateral movement within the organization's digital environment. +explanation = The following analytic identifies a spike in failed authentication attempts within an Office 365 environment, indicative of a potential distributed password spraying attack. It leverages UserLoginFailed events from O365 Management Activity logs, focusing on ErrorNumber 50126. This detection is significant as it highlights attempts to bypass security controls using multiple IP addresses and user agents. If confirmed malicious, this activity could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization. Early detection is crucial to prevent account takeovers and mitigate subsequent threats. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. @@ -3322,7 +3289,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic is crafted to identify unusual and potentially malicious authentication activity within an O365 environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of O365 audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +explanation = The following analytic identifies unusual authentication activity in an O365 environment, where a single user account experiences more than 8 authentication attempts using 3 or more unique application IDs and over 5 unique user agents within a short timeframe. It leverages O365 audit logs, focusing on authentication events and applying statistical thresholds. This behavior is significant as it may indicate an adversary probing for multi-factor authentication weaknesses. If confirmed malicious, it suggests a compromised account, potentially leading to unauthorized access, privilege escalation, and data exfiltration. Early detection is crucial to prevent further exploitation. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. @@ -3332,7 +3299,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach. +explanation = The following analytic identifies potential "MFA fatigue" attacks targeting Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. It leverages O365 management activity logs, focusing on Azure Active Directory events with the UserLoginFailed operation, a Success ResultStatus, and an ErrorNumber of 500121. This activity is significant as attackers may exploit MFA fatigue to gain unauthorized access by overwhelming users with repeated MFA requests. If confirmed malicious, this could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation is crucial. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. @@ -3342,7 +3309,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold - set here to flag over five unique mailboxes accessed within 10 minutes - to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency. +explanation = The following analytic detects when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) within a short timeframe. It leverages 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. This activity is significant as it may indicate unauthorized mass email access, potentially signaling data exfiltration or account compromise. If confirmed malicious, attackers could gain access to sensitive information, leading to data breaches and further exploitation of compromised accounts. The threshold is set to flag over five unique mailboxes accessed within 10 minutes, but should be tailored to your environment. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may access multiple mailboxes via an API. You can filter by the ClientAppId or the CLientIpAddress fields. @@ -3352,7 +3319,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection aims to identify instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe, using O365 logs from the Unified Audit Log. The focus is on tracking the 'Add service principal' operation within the Office 365 Azure Active Directory environment. The query effectively buckets events in 10-minute intervals, specifically scrutinizing the actions of service principals. By quantifying the number of distinct OAuth applications each service principal establishes, the analytic provides critical insights for SOC teams into potentially anomalous or malicious activities. These activities could include a compromised or malicious service principal being used to create multiple service principals, which might be indicative of an attempt to expand control or access within the network. Security teams are advised to adapt the threshold of three applications to align with their typical operational baseline +explanation = The following analytic identifies instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in the Office 365 Azure Active Directory environment. This activity is significant as it may indicate a compromised or malicious service principal attempting to expand control or access within the network. If confirmed malicious, this could lead to unauthorized access and potential lateral movement within the environment, posing a significant security risk. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. @@ -3362,7 +3329,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection is tailored to spot occurrences where a single user, rather than a service principal, creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. Utilizing O365 logs from the Unified Audit Log, it focuses on the 'Add service principal' operation in Azure Active Directory. The query segments events into 10-minute intervals, exclusively monitoring user activities. It calculates the number of distinct OAuth applications initiated by each user, providing SOC teams with essential data for identifying potential security threats. Such activity could suggest that a user account is either compromised or engaged in unauthorized activities, potentially setting the stage for broader network infiltration or privilege escalation. It's important for security teams to adjust the threshold of three applications to fit their operational context. +explanation = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in Azure Active Directory. This activity is significant as it may indicate a compromised user account or unauthorized actions, potentially leading to broader network infiltration or privilege escalation. If confirmed malicious, this behavior could allow attackers to gain persistent access, escalate privileges, or exfiltrate sensitive information. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. @@ -3372,7 +3339,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication. +explanation = The following analytic identifies instances where more than 10 unique user accounts fail to authenticate from a single IP address within a 5-minute window. This detection leverages O365 audit logs, specifically Azure Active Directory login failures (AzureActiveDirectoryStsLogon). Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to breach security by targeting multiple accounts, potentially leading to unauthorized access. Immediate action is required to block or monitor the suspicious IP and notify affected users to enhance their security measures. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.CM"]} known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. @@ -3382,7 +3349,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior. +explanation = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters like ForwardTo, ForwardAsAttachmentTo, and RedirectTo. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed. @@ -3392,7 +3359,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format. +explanation = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment via the UpdateInboxRules operation. It leverages Office 365 management activity events to detect rules that forward emails to external recipients by examining the OperationProperties for specific forwarding actions. This activity is significant as it may indicate unauthorized email redirection, potentially leading to data exfiltration. If confirmed malicious, attackers could intercept sensitive communications, leading to data breaches and information leakage. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed. @@ -3402,7 +3369,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach. +explanation = The following analytic identifies the addition of a new federated domain in an Office 365 environment. This behavior is detected by analyzing Office 365 management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". The addition of a new federated domain is significant as it may indicate unauthorized changes or potential compromises. If confirmed malicious, attackers could establish a backdoor, bypass security measures, or exfiltrate data, leading to data breaches and unauthorized access to sensitive information. Immediate investigation is required to review the details of the added domain and any concurrent suspicious activities. how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} known_false_positives = The creation of a new Federated domain is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a similar or different cloud provider. @@ -3412,7 +3379,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification. +explanation = The following analytic detects the creation of new mail flow rules in Office 365 that may redirect or copy emails to unauthorized or external addresses. It leverages Office 365 Management Activity logs, specifically querying for the "New-TransportRule" operation and parameters like "BlindCopyTo", "CopyTo", and "RedirectMessageTo". This activity is significant as it can indicate potential data exfiltration or unauthorized access to sensitive information. If confirmed malicious, attackers could intercept or redirect email communications, leading to data breaches or information leakage. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]} known_false_positives = Forwarding mail flow rules may be created for legitimate reasons, filter as needed. @@ -3422,7 +3389,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +explanation = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account within Office 365. It leverages O365 audit logs to identify changes in MFA configurations. This activity is significant as it may indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges or access sensitive data. Immediate verification and remediation are required to secure the affected account. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed. @@ -3432,7 +3399,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access. +explanation = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. It leverages the ClientInfoString field to identify EWS interactions and aggregates metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing emails through EWS is crucial for identifying potential abuse or unauthorized data access. If confirmed malicious, this activity could lead to unauthorized email access, data exfiltration, or further compromise of sensitive information. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the src_ip to add trusted sources to an allow list. @@ -3442,7 +3409,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns. +explanation = The following analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API using the client ID '00000003-0000-0000-c000-000000000000'. It leverages the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. This activity is significant as unauthorized access to emails can lead to data breaches and information theft. If confirmed malicious, attackers could exfiltrate sensitive information, compromise user accounts, and further infiltrate the organization’s network. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the ClientAppId to add trusted applications to an allow list. @@ -3452,7 +3419,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications. +explanation = The following analytic detects the assignment of critical Graph API permissions in Azure AD using the O365 Unified Audit Log. It focuses on permissions such as Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. The detection method leverages Azure Active Directory workload events, specifically 'Update application' operations. This activity is significant as these permissions provide extensive control over Azure AD settings, posing a high risk if misused. If confirmed malicious, this could allow unauthorized modifications, leading to potential data breaches or privilege escalation. Immediate investigation is crucial. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. @@ -3462,7 +3429,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions. +explanation = The following analytic detects instances where a user has initiated an eDiscovery search or exported a PST file in an Office 365 environment. It leverages Office 365 management activity logs, specifically filtering for events under ThreatManagement with the name "eDiscovery search started or exported." This activity is significant as it may indicate data exfiltration attempts or unauthorized access to sensitive information. If confirmed malicious, it suggests an attacker or insider threat is attempting to gather or exfiltrate data, potentially leading to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required. how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]} known_false_positives = PST export can be done for legitimate purposes but due to the sensitive nature of its content it must be monitored. @@ -3472,7 +3439,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace. +explanation = The following analytic identifies alerts triggered by the Office 365 Security and Compliance Center, indicating potential threats or policy violations. It leverages data from the `o365_management_activity` dataset, focusing on events where the workload is SecurityComplianceCenter and the operation is AlertTriggered. This activity is significant as it highlights security and compliance issues within the O365 environment, which are crucial for maintaining organizational security. If confirmed malicious, these alerts could indicate attempts to breach security policies, leading to unauthorized access, data exfiltration, or other malicious activities. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]} known_false_positives = O365 Security and Compliance may also generate false positives or trigger on legitimate behavior, filter as needed. @@ -3482,7 +3449,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies the addition of new credentials for Service Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application +explanation = The following analytic detects the addition of new credentials for Service Principals within an Office 365 tenant. It uses O365 audit logs, focusing on events related to credential modifications or additions in the AzureActiveDirectory workload. This activity is significant because Service Principals represent application identities, and their credentials allow applications to authenticate and access resources. If an attacker successfully adds or modifies these credentials, they can impersonate the application, leading to unauthorized data access, data exfiltration, or malicious operations under the application's identity. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]} known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. @@ -3492,7 +3459,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to organizational data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed. @@ -3502,7 +3469,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +explanation = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This detection leverages O365 audit logs, specifically focusing on failed user consent actions due to system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that O365's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = Microsofts algorithm to identify risky applications is unknown and may flag legitimate applications. @@ -3512,7 +3479,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = O365 Tenant confidence = medium -explanation = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +explanation = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Office 365 environment. This detection leverages O365 audit logs, focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, it captures instances where users have actively rejected permission requests. This activity is significant as it may indicate users spotting potentially suspicious or unfamiliar applications. If confirmed malicious, it suggests an attempt by a potentially harmful application to gain unauthorized access, which was proactively blocked by the user. how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. @@ -3522,7 +3489,7 @@ providing_technologies = ["Microsoft Office 365"] type = detection asset_type = Amazon Elastic Container Registry confidence = medium -explanation = The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts. +explanation = The following analytic identifies high-risk activities within repositories by correlating repository data with risk scores. It leverages risk events from the Dev Sec Ops analytic stories, summing risk scores and capturing source and user information. The detection focuses on high-risk scores above 100 and sources with more than three occurrences. This activity is significant as it highlights repositories frequently targeted by threats, providing insights into potential vulnerabilities. If confirmed malicious, attackers could exploit these repositories, leading to data breaches or infrastructure compromise. how_to_implement = Ensure that all relevant detections in the Dev Sec Ops analytic stories are enabled and are configured to create risk events in Enterprise Security. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} known_false_positives = Unknown @@ -4575,7 +4542,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious 7z process with commandline pointing to SMB network share. This technique was seen in CONTI LEAK tools where it use 7z to archive a sensitive files and place it in network share tmp folder. This search is a good hunting query that may give analyst a hint why specific user try to archive a file pointing to SMB user which is un usual. +explanation = The following analytic detects the execution of 7z or 7za processes with command lines pointing to SMB network shares. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it may indicate an attempt to archive and exfiltrate sensitive files to a network share, a technique observed in CONTI LEAK tools. If confirmed malicious, this behavior could lead to data exfiltration, compromising sensitive information and potentially aiding further attacks. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -4585,7 +4552,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks. +explanation = The following analytic detects attempts to dump the LSASS process memory, a common technique in credential dumping attacks. It leverages Sysmon logs, specifically EventCode 10, to identify suspicious call traces to dbgcore.dll and dbghelp.dll associated with lsass.exe. This activity is significant as it often precedes the theft of sensitive login credentials, posing a high risk of unauthorized access to systems and data. If confirmed malicious, attackers could gain access to critical credentials, enabling further compromise and lateral movement within the network. how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual. @@ -4595,7 +4562,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a potential account discovery series of command used by several malware or attack to recon the target machine. This technique is also seen in some note worthy malware like trickbot where it runs a cmd process, or even drop its module that will execute the said series of net command. This series of command are good correlation search and indicator of attacker recon if seen in the machines within a none technical user or department (HR, finance, ceo and etc) network. +explanation = The following analytic detects potential account discovery activities using the 'net' command, commonly employed by malware like Trickbot for reconnaissance. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line patterns and process relationships. This activity is significant as it often precedes further malicious actions, such as lateral movement or privilege escalation. If confirmed malicious, attackers could gain valuable information about user accounts, enabling them to escalate privileges or move laterally within the network, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Admin or power user may used this series of command. @@ -4605,7 +4572,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +explanation = The following analytic identifies potential lateral movement activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Lateral Movement analytic story within a specified time frame. This is significant for a SOC as lateral movement is a common tactic used by attackers to expand their access within a network, posing a substantial risk. If confirmed malicious, this activity could allow attackers to escalate privileges, access sensitive information, and persist within the environment, leading to severe security breaches. how_to_implement = 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 as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. @@ -4615,7 +4582,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +explanation = The following analytic identifies potential privilege escalation activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Privilege Escalation analytic story within a specified time frame. This is significant for a SOC as it helps identify coordinated attempts to gain elevated privileges, which could indicate a serious security threat. If confirmed malicious, this activity could allow attackers to gain unauthorized access to sensitive systems and data, leading to potential data breaches and further compromise of the network. how_to_implement = 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 as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.AE"]} known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. @@ -4625,7 +4592,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious modification of the active setup registry for persistence and privilege escalation. This technique was seen in several malware (poisonIvy), adware and APT to gain persistence to the compromised machine upon boot up. This TTP is a good indicator to further check the process id that do the modification since modification of this registry is not commonly done. check the legitimacy of the file and process involve in this rules to check if it is a valid setup installer that creating or modifying this registry. +explanation = The following analytic detects suspicious modifications to the Active Setup registry for persistence and privilege escalation. It leverages data from the Endpoint.Registry data model, focusing on changes to the "StubPath" value within the "SOFTWARE\\Microsoft\\Active Setup\\Installed Components" path. This activity is significant as it is commonly used by malware, adware, and APTs to maintain persistence on compromised machines. If confirmed malicious, this could allow attackers to execute code upon system startup, potentially leading to further system compromise and unauthorized access. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.014", "T1547"], "nist": ["DE.CM"]} known_false_positives = Active setup installer may add or modify this registry. @@ -4635,7 +4602,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +explanation = The following analytic detects suspicious registry modifications that implement auto admin logon by adding DefaultUserName and DefaultPassword values. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry path. This activity is significant because it is associated with BlackMatter ransomware, which uses this technique to automatically log on to compromised hosts and continue encryption after a safe mode boot. If confirmed malicious, this could allow attackers to maintain persistence and further encrypt the network, leading to significant data loss and operational disruption. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -4645,7 +4612,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify a suspicious process command-line related to Windows Defender exclusion feature. This command is abused by adversaries, malware authors and red teams to bypass Windows Defender Antivirus products by excluding folder path, file path, process and extensions. From its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior. +explanation = The following analytic detects the use of commands to add or set exclusions in Windows Defender. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "Add-MpPreference" or "Set-MpPreference" with exclusion parameters. This activity is significant because adversaries often use it to bypass Windows Defender, allowing malicious code to execute undetected. If confirmed malicious, this behavior could enable attackers to evade antivirus detection, maintain persistence, and execute further malicious activities without interference from Windows Defender. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = Admin or user may choose to use this windows features. Filter as needed. @@ -4655,7 +4622,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain users. It leverages PowerShell Script Block Logging (EventCode=4104) to identify script blocks containing `[adsisearcher]`, `objectcategory=user`, and `.findAll()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this could lead to further reconnaissance, privilege escalation, or lateral movement within the network. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -4665,7 +4632,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious modification of firewall to allow file and printer sharing. This technique was seen in ransomware to be able to discover more machine connected to the compromised host to encrypt more files +explanation = The following analytic detects the modification of firewall settings to allow file and printer sharing. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving 'netsh' commands that enable file and printer sharing. This activity is significant because it can indicate an attempt by ransomware to discover and encrypt files on additional machines connected to the compromised host. If confirmed malicious, this could lead to widespread file encryption across the network, significantly increasing the impact of a ransomware attack. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered. @@ -4675,7 +4642,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a potential suspicious modification of firewall rule registry allowing inbound traffic in specific port with public profile. This technique was identified when an adversary wants to grant remote access to a machine by allowing the traffic in a firewall rule. +explanation = The following analytic detects suspicious modifications to firewall rule registry settings that allow inbound traffic on specific ports with a public profile. It leverages data from the Endpoint.Registry data model, focusing on registry paths and values indicative of such changes. This activity is significant as it may indicate an adversary attempting to grant remote access to a machine by modifying firewall rules. If confirmed malicious, this could enable unauthorized remote access, potentially leading to further exploitation, data exfiltration, or lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} known_false_positives = network admin may add/remove/modify public inbound firewall rule that may cause this rule to be triggered. @@ -4685,7 +4652,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell command to allow inbound traffic inbound to a specific local port within the public profile. This technique was seen in some attacker want to have a remote access to a machine by allowing the traffic in firewall rule. +explanation = The following analytic detects a suspicious PowerShell command that allows inbound traffic to a specific local port within the public profile. It leverages PowerShell script block logging (EventCode 4104) to identify commands containing keywords like "firewall," "Inbound," "Allow," and "-LocalPort." This activity is significant because it may indicate an attacker attempting to establish remote access by modifying firewall rules. If confirmed malicious, this could allow unauthorized access to the machine, potentially leading to further exploitation and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} known_false_positives = administrator may allow inbound traffic in certain network or machine. @@ -4695,7 +4662,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious modification to the firewall to allow network discovery on a machine. This technique was seen in couple of ransomware (revil, reddot) to discover other machine connected to the compromised host to encrypt more files. +explanation = The following analytic detects a suspicious modification to the firewall to allow network discovery on a machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving the 'netsh' command to enable network discovery. This activity is significant because it is commonly used by ransomware, such as REvil and RedDot, to discover and compromise additional machines on the network. If confirmed malicious, this could lead to widespread file encryption across multiple hosts, significantly amplifying the impact of the ransomware attack. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered. @@ -4705,7 +4672,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a potential privilege escalation attempt to perform malicious task. This registry modification is designed to allow the `Consent Admin` to perform an operation that requires elevation without consent or credentials. We also found this in some attacker to gain privilege escalation to the compromise machine. +explanation = The following analytic detects a registry modification that allows the 'Consent Admin' to perform operations requiring elevation without user consent or credentials. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the 'ConsentPromptBehaviorAdmin' value within the Windows Policies System registry path. This activity is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to execute high-privilege tasks without user approval. If confirmed malicious, this could lead to unauthorized administrative access and control over the compromised machine, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4715,7 +4682,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies a 7z.exe spawned from `Rundll32.exe` or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`. It has been observed where an adversary will rename `7z.exe`. Additional coverage may be required to identify the behavior of renamed instances of `7z.exe`. During triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture any files written to disk and analyze as needed. Review parallel processes for additional behaviors. Typically, archiving files will result in exfiltration. +explanation = The following analytic detects the execution of 7z.exe, a 7-Zip utility, spawned from rundll32.exe or dllhost.exe. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and parent processes. This activity is significant as it may indicate an adversary attempting to use 7-Zip for data exfiltration, often by renaming the executable to evade detection. If confirmed malicious, this could lead to unauthorized data archiving and exfiltration, compromising sensitive information and potentially leading to further system exploitation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited as this behavior is not normal for `rundll32.exe` or `dllhost.exe` to spawn and run 7zip. @@ -4725,7 +4692,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of PowerShell downloading a file using `DownloadFile` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +explanation = The following analytic detects the use of PowerShell's `DownloadFile` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant as it is commonly used in malicious frameworks to download and execute additional payloads. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the system. Analysts should investigate the source and destination of the download and review AMSI or PowerShell transaction logs for additional context. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage. @@ -4735,7 +4702,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of PowerShell downloading a file using `DownloadString` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +explanation = The following analytic detects the use of PowerShell's `DownloadString` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because `DownloadString` is commonly used in malicious PowerShell scripts to fetch and execute remote code. If confirmed malicious, this behavior could allow an attacker to download and run arbitrary code, potentially leading to unauthorized access, data exfiltration, or further compromise of the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage. @@ -4745,7 +4712,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives. +explanation = The following analytic detects the execution of tools commonly exploited by cybercriminals, such as those used for unauthorized access, network scanning, or data exfiltration. It leverages process activity data from Endpoint Detection and Response (EDR) agents, focusing on known attacker tool names. This activity is significant because it serves as an early warning system for potential security incidents, enabling prompt response. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further network compromise, posing a severe threat to the organization's security infrastructure. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Reconnaissance"], "mitre_attack": ["T1036.005", "T1036", "T1003", "T1595"], "nist": ["DE.CM"]} known_false_positives = Some administrator activity can be potentially triggered, please add those users to the filter macro. @@ -4755,7 +4722,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security. +explanation = The following analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. It leverages process activity and command-line arguments from Endpoint Detection and Response (EDR) logs mapped to the Splunk `Processes` data model. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.CM"]} known_false_positives = There may be legitimate reasons for administrators to add a certificate to the untrusted certificate store. In such cases, this will typically be done on a large number of systems. @@ -4765,7 +4732,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack. +explanation = The following analytic detects attempts to stop security-related services on an endpoint, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, specifically searching for processes involving the "sc.exe" command with the "stop" parameter. This activity is significant because disabling security services can undermine the organization's security posture, potentially leading to unauthorized access, data exfiltration, or further attacks like malware installation or privilege escalation. If confirmed malicious, this behavior could compromise the endpoint and the entire network, necessitating immediate investigation and response. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = None identified. Attempts to disable security-related services should be identified and understood. @@ -4785,7 +4752,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +explanation = The following analytic detects a suspicious registry modification that enables auto admin logon on a host. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "AutoAdminLogon" value within the "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" registry path. This activity is significant because it was observed in BlackMatter ransomware attacks to maintain access after a safe mode reboot, facilitating further encryption. If confirmed malicious, this could allow attackers to automatically log in and continue their operations, potentially leading to widespread network encryption and data loss. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4805,7 +4772,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious bcdedit commandline to configure the host from safe mode back to normal boot configuration. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +explanation = The following analytic detects the execution of a suspicious `bcdedit` command that reconfigures a host from safe mode back to normal boot. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant as it may indicate the presence of ransomware, such as BlackMatter, which manipulates boot configurations to facilitate encryption processes. If confirmed malicious, this behavior could allow attackers to maintain control over the boot process, potentially leading to further system compromise and data encryption. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4825,7 +4792,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. The query identifies the parameters used to create, resume or add a file to a BITS job. Typically seen combined in a oneliner or ran in sequence. If identified, review the BITS job created and capture any files written to disk. It is possible for BITS to be used to upload files and this may require further network data analysis to identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +explanation = The following analytic detects the use of `bitsadmin.exe` to schedule a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line parameters such as `create`, `addfile`, and `resume`. This activity is significant because BITS jobs can be used by attackers to maintain persistence, download malicious payloads, or exfiltrate data. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or transfer sensitive information, necessitating further investigation and potential remediation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"]} known_false_positives = Limited false positives will be present. Typically, applications will use `BitsAdmin.exe`. Any filtering should be done based on command-line arguments (legitimate applications) or parent process. @@ -4835,7 +4802,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote object. In addition, look for `download` or `upload` on the command-line, the switches are not required to perform a transfer. Capture any files downloaded. Review the reputation of the IP or domain used. Typically once executed, a follow on command will be used to execute the dropped file. Note that the network connection or file modification events related will not spawn or create from `bitsadmin.exe`, but the artifacts will appear in a parallel process of `svchost.exe` with a command-line similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel and child processes to capture any behaviors and artifacts. In some suspicious and malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +explanation = The following analytic detects the use of `bitsadmin.exe` with the `transfer` parameter to download a remote object. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because `bitsadmin.exe` can be exploited to download and execute malicious files without immediate detection. If confirmed malicious, an attacker could use this technique to download and execute payloads, potentially leading to code execution, privilege escalation, or persistent access within the environment. Review parallel and child processes, especially `svchost.exe`, for associated artifacts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation", "Installation"], "mitre_attack": ["T1197", "T1105"], "nist": ["DE.CM"]} known_false_positives = Limited false positives, however it may be required to filter based on parent process name or network connection. @@ -4845,7 +4812,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Certutil.exe may download a file from a remote destination using `-urlcache`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. However, it is uncommon for `certutil.exe` to write files to world writeable paths. During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. +explanation = The following analytic detects the use of certutil.exe to download files using the `-urlcache` and `-split` arguments. It leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions that include these specific arguments. This activity is significant because certutil.exe is typically used for certificate services, and its use to download files from remote locations is uncommon and potentially malicious. If confirmed, this behavior could indicate an attempt to download and execute malicious payloads, leading to potential system compromise and unauthorized data access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection. @@ -4855,7 +4822,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Certutil.exe may download a file from a remote destination using `-VerifyCtl`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. \ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. Using `-VerifyCtl`, the file will either be written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\`. +explanation = The following analytic detects the use of `certutil.exe` to download files using the `-VerifyCtl` and `-split` arguments. This behavior is identified by monitoring command-line executions for these specific arguments via Endpoint Detection and Response (EDR) telemetry. This activity is significant because `certutil.exe` is a legitimate tool often abused by attackers to download and execute malicious payloads. If confirmed malicious, this could allow an attacker to download and execute arbitrary files, potentially leading to code execution, data exfiltration, or further compromise of the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection. @@ -4875,7 +4842,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = CertUtil.exe may be used to `encode` and `decode` a file, including PE and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded file that was downloaded. Once decoded, it will be loaded by a parallel process. Note that there are two additional command switches that may be used - `encodehex` and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for further execution. During triage, identify the source of the file being decoded. Review its contents or execution behavior for further analysis. +explanation = The following analytic detects the use of CertUtil.exe with the 'decode' argument, which may indicate an attempt to decode a previously encoded file, potentially containing malicious payloads. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving CertUtil.exe. This activity is significant because attackers often use CertUtil to decode malicious files downloaded from the internet, which are then executed to compromise the system. If confirmed malicious, this activity could lead to unauthorized code execution, further system compromise, and potential data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1140"], "nist": ["DE.CM"]} known_false_positives = Typically seen used to `encode` files, but it is possible to see legitimate use of `decode`. Filter based on parent-child relationship, file paths, endpoint or user. @@ -4885,7 +4852,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious registry modification to change the default file association of windows to malicious payload. This technique was seen in some APT where it modify the default process to run file association, like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other payload that will load malicious commands to the compromised host. +explanation = The following analytic detects suspicious registry modifications that change the default file association to execute a malicious payload. It leverages data from the Endpoint data model, specifically monitoring registry paths under "*\\shell\\open\\command\\*" and "*HKCR\\*". This activity is significant because altering default file associations can allow attackers to execute arbitrary scripts or payloads when a user opens a file, leading to potential code execution. If confirmed malicious, this technique can enable attackers to persist on the compromised host and execute further malicious commands, posing a severe threat to the environment. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4895,7 +4862,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious bcdedit commandline to configure the host to boot in safe mode with network config. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +explanation = The following analytic detects the execution of a suspicious `bcdedit` command that configures a host to boot in safe mode with network support. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant because it is a known technique used by BlackMatter ransomware to force a compromised host into safe mode for continued encryption. If confirmed malicious, this could allow attackers to bypass certain security controls, persist in the environment, and continue their malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4905,7 +4872,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect execution of chcp.exe application. this utility is used to change the active code page of the console. This technique was seen in icedid malware to know the locale region/language/country of the compromise host. +explanation = The following analytic detects the execution of the chcp.exe application, which is used to change the active code page of the console. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where chcp.exe is executed by cmd.exe with specific command-line arguments. This activity is significant because it can indicate the presence of malware, such as IcedID, which uses this technique to determine the locale region, language, or country of the compromised host. If confirmed malicious, this could lead to further system compromise and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} known_false_positives = other tools or script may used this to change code page to UTF-* or others @@ -4915,7 +4882,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious whoami execution to check if the cmd or shell instance process is with elevated privileges. This technique was seen in FIN7 js implant where it execute this as part of its data collection to the infected machine to check if the running shell cmd process is elevated or not. This TTP is really a good alert for known attacker that recon on the targetted host. This command is not so commonly executed by a normal user or even an admin to check if a process is elevated. +explanation = The following analytic identifies the execution of the 'whoami' command with specific parameters to check for elevated privileges. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because it is commonly used by attackers, such as FIN7, to perform reconnaissance on a compromised host. If confirmed malicious, this behavior could indicate an attacker is assessing their privilege level, potentially leading to further privilege escalation or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4945,7 +4912,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytics are designed to identifies some CLOP ransomware variant that using arguments to execute its main code or feature of its code. In this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files in network shares and if it is "temp.dat", it will try to read from some stream pipe or file start encrypting files within the infected local machines. This technique can be also identified as an anti-sandbox technique to make its code non-responsive since it is waiting for some parameter to execute properly. +explanation = The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"]} known_false_positives = Operators can execute third party tools using these parameters. @@ -4955,7 +4922,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection is to identify the common service name created by the CLOP ransomware as part of its persistence and high privilege code execution in the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API in creating this service entry. +explanation = The following analytic identifies the creation of a service with a known name used by CLOP ransomware for persistence and high-privilege code execution. It detects this activity by monitoring Windows Event Logs (EventCode 7045) for specific service names ("SecurityCenterIBM", "WinCheckDRVs"). This activity is significant because the creation of such services is a common tactic used by ransomware to maintain control over infected systems. If confirmed malicious, this could allow attackers to execute code with elevated privileges, maintain persistence, and potentially disrupt or encrypt critical data. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -4965,7 +4932,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies command-line arguments where `cmd.exe /c` is used to execute a program. `cmd /c` is used to run commands in MS-DOS and terminate after command or process completion. This technique is commonly seen in adversaries and malware to execute batch command using different shell like PowerShell or different process other than `cmd.exe`. This is a good hunting query for suspicious command-line made by a script or relative process execute it. +explanation = The following analytic detects the use of `cmd.exe /c` to execute commands, a technique often employed by adversaries and malware to run batch commands or invoke other shells like PowerShell. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. Monitoring this activity is crucial as it can indicate script-based attacks or unauthorized command execution. If confirmed malicious, this behavior could lead to unauthorized code execution, privilege escalation, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.AE"]} known_false_positives = False positives may be high based on legitimate scripted code in any environment. Filter as needed. @@ -4975,7 +4942,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a common behavior by Cobalt Strike and other frameworks where the adversary will escalate privileges, either via `jump` (Cobalt Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. +explanation = The following analytic identifies the use of named-pipe impersonation for privilege escalation, commonly associated with Cobalt Strike and similar frameworks. It detects command-line executions where `cmd.exe` uses `echo` to write to a named pipe, such as `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant as it indicates potential privilege escalation attempts. If confirmed malicious, attackers could gain elevated privileges, enabling further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059", "T1059.003", "T1543.003", "T1543"], "nist": ["DE.CM"]} known_false_positives = Unknown. It is possible filtering may be required to ensure fidelity. @@ -4985,7 +4952,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a non-standard parent process (not matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also typically seen when an adversary is injected into another process performing different discovery techniques. This event stands out as a TTP since these tools are commonly executed with a shell application or Explorer parent, and not by another application. This TTP is a good indicator for an adversary gathering host information, but one possible false positive might be an automated tool used by a system administator. +explanation = The following analytic identifies instances where `ipconfig.exe`, `systeminfo.exe`, or similar tools are executed by a non-standard parent process, excluding CMD, PowerShell, or Explorer. This detection leverages Endpoint Detection and Response (EDR) telemetry to monitor process creation events. Such behavior is significant as it may indicate adversaries using injected processes to perform system discovery, a tactic observed in FIN7's JSSLoader. If confirmed malicious, this activity could allow attackers to gather critical host information, aiding in further exploitation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"]} known_false_positives = A network operator or systems administrator may utilize an automated host discovery application that may generate false positives. Filter as needed. @@ -5005,8 +4972,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of default or publicly known named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. Cobalt Strike uses named pipes in many ways and has default values used with the Artifact Kit and Malleable C2 Profiles. The following query assists with identifying these default named pipes. Each EDR product presents named pipes a little different. Consider taking the values and generating a query based on the product of choice. \ -Upon triage, review the process performing the named pipe. If it is explorer.exe, It is possible it was injected into by another process. Review recent parallel processes to identify suspicious patterns or behaviors. A parallel process may have a network connection, review and follow the connection back to identify any file modifications. +explanation = The following analytic detects the use of default or publicly known named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 to identify specific named pipes commonly used by Cobalt Strike's Artifact Kit and Malleable C2 Profiles. This activity is significant because Cobalt Strike is a popular tool for adversaries to conduct post-exploitation tasks, and identifying its named pipes can reveal potential malicious activity. If confirmed malicious, this could indicate an active Cobalt Strike beacon, leading to unauthorized access, data exfiltration, or further lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = The idea of using named pipes with Cobalt Strike is to blend in. Therefore, some of the named pipes identified and added may cause false positives. Filter by process name or pipe name to reduce false positives. @@ -5016,7 +4982,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack. +explanation = The following analytic detects modifications to files with extensions commonly associated with ransomware. It leverages the Endpoint.Filesystem data model to identify changes in file extensions that match known ransomware patterns. This activity is significant because it suggests an attacker is attempting to encrypt or alter files, potentially leading to severe data loss and operational disruption. If confirmed malicious, this activity could result in the encryption of critical data, rendering it inaccessible and causing significant damage to the organization's data integrity and availability. how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint Filesystem data model node. To see the additional metadata, add the following fields, if not already present, please review the detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details` annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]} known_false_positives = It is possible for a legitimate file with these extensions to be created. If this is a true ransomware attack, there will be a large number of files created with these extensions. @@ -5036,7 +5002,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +explanation = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows path traversal attacks by manipulating file_path and file_name parameters in the URL. It leverages the Endpoint datamodel Filesystem node to identify suspicious file system events, specifically targeting paths and filenames associated with ScreenConnect. This activity is significant as it can lead to unauthorized access to sensitive files and directories, potentially resulting in data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access and control over the host system, posing a severe security risk. how_to_implement = This analytic utilizes the Endpoint datamodel Filesystem node to identify path traversal attempts against ScreenConnect. Note that using SACL auditing or other file system monitoring tools may also be used to detect path traversal attempts. Typically the data for this analytic will come from EDR or other properly CIM mapped data sources. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, as the detection is based on the presence of file system events that indicate path traversal attempts. The analytic may be modified to look for any file writes to this path as it is not common for files to write here. @@ -5046,7 +5012,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +explanation = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability using Windows SACL EventCode 4663. It identifies path traversal attacks by monitoring file system events related to the ScreenConnect service. This activity is significant as it allows unauthorized access to sensitive files and directories, potentially leading to data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access to critical data or execute harmful code, compromising the integrity and security of the affected system. Immediate remediation by updating to version 23.9.8 or above is recommended. how_to_implement = To implement the following query, enable SACL auditing for the ScreenConnect directory(ies). With this data, the following analytic will work correctly. A GIST is provided in the references to assist with enabling SACL Auditing. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the analytic is specific to ScreenConnect path traversal attempts. Tune as needed, or restrict to specific hosts if false positives are encountered. @@ -5066,7 +5032,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies control.exe loading either a .cpl or .inf from a writable directory. This is related to CVE-2021-40444. During triage, review parallel processes, parent and child, for further suspicious behaviors. In addition, capture file modifications and analyze. +explanation = The following analytic identifies instances of control.exe loading a .cpl or .inf file from a writable directory, which is related to CVE-2021-40444. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it may indicate an attempt to exploit a known vulnerability, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to gain control over the affected system, leading to further compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.002"], "nist": ["DE.CM"]} known_false_positives = Limited false positives will be present as control.exe does not natively load from writable paths as defined. One may add .cpl or .inf to the command-line if there is any false positives. Tune as needed. @@ -5076,7 +5042,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack. +explanation = The following analytic detects the creation of local administrator accounts using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes named net.exe or net1.exe with the "/add" parameter and keywords related to administrator accounts. This activity is significant as it may indicate an attacker attempting to gain persistent access or escalate privileges. If confirmed malicious, this could lead to unauthorized access, data theft, or further system compromise. Review the process details, user context, and related artifacts to determine the legitimacy of the activity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]} known_false_positives = Administrators often leverage net.exe to create admin accounts. @@ -5086,7 +5052,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. +explanation = The following analytic detects the creation or deletion of Windows shares using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes involving net.exe with actions related to share management. This activity is significant because it may indicate an attacker attempting to manipulate network shares for malicious purposes, such as data exfiltration, malware distribution, or establishing persistence. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, service disruption, or malware introduction. Immediate investigation is required to determine the intent and mitigate potential threats. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.005"], "nist": ["DE.CM"]} known_false_positives = Administrators often leverage net.exe to create or delete network shares. You should verify that the activity was intentional and is legitimate. @@ -5096,7 +5062,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect suspicious process injection in command shell. This technique was seen in IcedID where it execute cmd.exe process to inject its shellcode as part of its execution as banking trojan. It is really uncommon to have a create remote thread execution in the following application. +explanation = The following analytic detects suspicious process injection in command shell applications, specifically targeting `cmd.exe` and `powershell.exe`. It leverages Sysmon EventCode 8 to identify the creation of remote threads within these shell processes. This activity is significant because it is a common technique used by malware, such as IcedID, to inject malicious code and execute it within legitimate processes. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5106,7 +5072,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon EventID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats. +explanation = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS). This behavior is identified using Sysmon Event ID 8 logs, focusing on processes that create remote threads in lsass.exe. This activity is significant because it is commonly associated with credential dumping, a tactic used by adversaries to steal user authentication credentials. If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information, leading to potential compromise of the entire network. Analysts should investigate to differentiate between legitimate tools and potential threats. how_to_implement = This search needs Sysmon Logs with a Sysmon configuration, which includes EventCode 8 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = Other tools can access LSASS for legitimate reasons and generate an event. In these cases, tweaking the search may help eliminate noise. @@ -5116,7 +5082,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Windows confidence = medium -explanation = Detect the hands on keyboard behavior of Windows Task Manager creating a process dump of lsass.exe. Upon this behavior occurring, a file write/modification will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, cannot be renamed, however if the dump occurs more than once, it will be named lsass (2).dmp. +explanation = The following analytic detects the creation of an lsass.exe process dump using Windows Task Manager. It leverages Sysmon EventID 11 to identify file creation events where the target filename matches *lsass*.dmp. This activity is significant because creating an lsass dump can be a precursor to credential theft, as the dump file contains sensitive information such as user passwords. If confirmed malicious, an attacker could use the lsass dump to extract credentials and escalate privileges, potentially compromising the entire network. how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 11 for detecting file create of lsass.dmp. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual. @@ -5136,7 +5102,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack. +explanation = The following analytic detects the creation of shadow copies using "wmic" or "Powershell" commands. It leverages the Endpoint.Processes data model in Splunk to identify processes where the command includes "shadowcopy" and "create". This activity is significant because it may indicate an attacker attempting to manipulate or access data unauthorizedly, potentially leading to data theft or manipulation. If confirmed malicious, this behavior could allow attackers to backup and exfiltrate sensitive data or hide their tracks by restoring files to a previous state after an attack. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} known_false_positives = Legtimate administrator usage of wmic to create a shadow copy. @@ -5146,7 +5112,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as "sam", "security", "system", and "ntds.dit", located in system directories like "system32" or "windows". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack +explanation = The following analytic detects the use of the copy command to dump credentials from a shadow copy. It leverages Endpoint Detection and Response (EDR) data to identify processes with command lines referencing critical files like "sam", "security", "system", and "ntds.dit" in system directories. This activity is significant as it indicates an attempt to extract credentials, a common technique for unauthorized access and privilege escalation. If confirmed malicious, this could lead to attackers gaining sensitive login information, escalating privileges, moving laterally within the network, or accessing sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5156,7 +5122,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies. The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model. The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack. +explanation = The following analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. It leverages the Endpoint.Processes data model in Splunk to identify processes executing commands containing "mklink" and "HarddiskVolumeShadowCopy". This activity is significant because attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts. If confirmed malicious, this could prevent data restoration, complicate incident response, and lead to data loss or compromise. Analysts should review the process details, user, parent process, and any related artifacts to identify the attack source. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5166,7 +5132,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this analytic is to detect a suspicious compile before delivery approach of .net compiler csc.exe. This technique was seen in several adversaries, malware and even in red teams to take advantage the csc.exe .net compiler tool to compile on the fly a malicious .net code to evade detection from security product. This is a good hunting query to check further the file or process created after this event and check the file path that passed to csc.exe which is the .net code. Aside from that, powershell is capable of using this compiler in executing .net code in a powershell script so filter on that case is needed. +explanation = The following analytic detects the use of the .NET compiler csc.exe for on-the-fly compilation of potentially malicious .NET code. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns associated with csc.exe. This activity is significant because adversaries and malware often use this technique to evade detection by compiling malicious code at runtime. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.004", "T1027"], "nist": ["DE.AE"]} known_false_positives = A network operator or systems administrator may utilize an automated powershell script taht execute .net code that may generate false positive. filter is needed. @@ -5176,7 +5142,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of curl on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +explanation = The following analytic detects the use of curl on Linux or MacOS systems to download a file from a remote source and pipe it directly to bash for execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and parent processes. This activity is significant as it is commonly associated with malicious actions such as coinminers and exploitation of vulnerabilities like CVE-2021-44228 in Log4j. If confirmed malicious, this behavior could lead to unauthorized code execution, system compromise, and further exploitation within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however filtering may be required. @@ -5186,7 +5152,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This following analytic detects PowerShell command to delete shadow copy using the WMIC PowerShell module. This technique was seen used by a recent adversary to deploy DarkSide Ransomware where it executed a child process of PowerShell to execute a hex encoded command to delete shadow copy. This hex encoded command was able to be decrypted by PowerShell log. +explanation = The following analytic detects the use of PowerShell to delete shadow copies via the WMIC PowerShell module. It leverages EventCode 4104 and searches for specific keywords like "ShadowCopy," "Delete," or "Remove" within the ScriptBlockText. This activity is significant because deleting shadow copies is a common tactic used by ransomware, such as DarkSide, to prevent data recovery. If confirmed malicious, this action could lead to irreversible data loss and hinder recovery efforts, significantly impacting business continuity and data integrity. how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5196,7 +5162,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect a suspicious net.exe/net1.exe command-line to delete a user on a system. This technique may be use by an administrator for legitimate purposes, however this behavior has been used in the wild to impair some user or deleting adversaries tracks created during its lateral movement additional systems. During triage, review parallel processes for additional behavior. Identify any other user accounts created before or after. +explanation = The following analytic detects the use of net.exe or net1.exe command-line to delete a user account on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. This activity is significant as it may indicate an attempt to impair user accounts or cover tracks during lateral movement. If confirmed malicious, this could lead to unauthorized access removal, disruption of legitimate user activities, or concealment of adversarial actions, complicating incident response and forensic investigations. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.CM"]} known_false_positives = System administrators or scripts may delete user accounts via this technique. Filter as needed. @@ -5216,7 +5182,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the common command-line argument used by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +explanation = The following analytic detects the execution of the `Invoke-AzureHound` command-line argument, commonly used by the AzureHound tool. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because AzureHound is often used for reconnaissance in Azure environments, potentially exposing sensitive information. If confirmed malicious, this activity could allow an attacker to map out Azure Active Directory structures, aiding in further attacks and privilege escalation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = Unknown. @@ -5226,7 +5192,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is similar to SharpHound file modifications, but this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound equivilent but for Azure. It's possible this may never be seen in an environment as most attackers may execute this tool remotely. Once execution is complete, a zip file with a similar name will drop `20210601090751-azurecollection.zip`. In addition to the zip, multiple .json files will be written to disk, which are in the zip. +explanation = The following analytic detects the creation of specific AzureHound-related files, such as `*-azurecollection.zip` and various `.json` files, on disk. It leverages data from the Endpoint.Filesystem datamodel, focusing on file creation events with specific filenames. This activity is significant because AzureHound is a tool used to gather information about Azure environments, similar to SharpHound for on-premises Active Directory. If confirmed malicious, this activity could indicate an attacker is collecting sensitive Azure environment data, potentially leading to further exploitation or privilege escalation within the cloud infrastructure. how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed. @@ -5236,7 +5202,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit. +explanation = The following analytic detects attempts to exploit the Baron Samedit vulnerability (CVE-2021-3156) by identifying the use of the "sudoedit -s \\" command. This detection leverages logs from Linux systems, specifically searching for instances of the sudoedit command with the "-s" flag followed by a double quote. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows attackers to gain root privileges. If confirmed malicious, this could lead to complete system compromise, unauthorized access to sensitive data, and potential data breaches. how_to_implement = Splunk Universal Forwarder running on Linux systems, capturing logs from the /var/log directory. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5246,7 +5212,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action. +explanation = The following analytic identifies a heap-based buffer overflow in sudoedit by detecting Linux logs containing both "sudoedit" and "segfault" terms. This detection leverages Splunk to monitor for more than five occurrences of these terms on a single host within a specified timeframe. This activity is significant because exploiting this vulnerability (CVE-2021-3156) can allow attackers to gain root privileges, leading to potential system compromise, unauthorized access, and data breaches. If confirmed malicious, this could result in elevated privileges and full control over the affected system, posing a severe security risk. how_to_implement = Splunk Universal Forwarder running on Linux systems (tested on Centos and Ubuntu), where segfaults are being logged. This also captures instances where the exploit has been compiled into a binary. The detection looks for greater than 5 instances of sudoedit combined with segfault over your search time period on a single host annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = If sudoedit is throwing segfaults for other reasons this will pick those up too. @@ -5256,7 +5222,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command "sudoedit -s *" is run using the osquery_process data source. This indicates that the sudoedit command is used with the "-s" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the "-s" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment. +explanation = The following analytic detects the execution of the "sudoedit -s *" command, which is associated with the Baron Samedit CVE-2021-3156 heap-based buffer overflow vulnerability. This detection leverages the `osquery_process` data source to identify instances where this specific command is run. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows privilege escalation. If confirmed malicious, an attacker could gain full control of the system, execute arbitrary code, or access sensitive data, leading to potential data breaches and system disruptions. how_to_implement = OSQuery installed and configured to pick up process events (info at https://osquery.io) as well as using the Splunk OSQuery Add-on https://splunkbase.splunk.com/app/4402. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5266,7 +5232,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when the attacker tool Certify or Certipy are used to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments of these tools are similar and perform near identical enumeration or exploitation functions. +explanation = The following analytic detects the use of Certify or Certipy tools to enumerate Active Directory Certificate Services (AD CS) environments. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with these tools. This activity is significant because it indicates potential reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized access or privilege escalation. If confirmed malicious, attackers could gain insights into the AD CS infrastructure, potentially compromising sensitive certificates and escalating their privileges within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1649", "T1105"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -5276,7 +5242,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when the attacker tool Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions. +explanation = The following analytic detects the use of the Certify tool via an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. It leverages PowerShell Script Block Logging (EventCode 4104) to identify specific command patterns associated with Certify's enumeration and exploitation functions. This activity is significant as it indicates potential reconnaissance or exploitation attempts against AD CS, which could lead to unauthorized certificate issuance. If confirmed malicious, attackers could leverage this to escalate privileges, persist in the environment, or access sensitive information by abusing AD CS. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1649", "T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = Unknown, partial script block matches. @@ -5286,7 +5252,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process. +explanation = The following analytic detects the use of the Certipy tool to enumerate Active Directory Certificate Services (AD CS) environments by identifying unique file modifications. It leverages endpoint process and filesystem data to spot the creation of files with specific names or extensions associated with Certipy's information gathering and exfiltration activities. This activity is significant as it indicates potential reconnaissance and data exfiltration efforts by an attacker. If confirmed malicious, this could lead to unauthorized access to sensitive AD CS information, enabling further attacks or privilege escalation within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints as well as file creation or deletion events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1560"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -5306,10 +5272,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the most basic use cases for credentials being taken for offline cracking. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the use of PowerShell commands to copy the SAM, SYSTEM, or SECURITY hives, which are critical for credential theft. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command executed. This activity is significant as it indicates an attempt to exfiltrate sensitive registry hives for offline password cracking. If confirmed malicious, this could lead to unauthorized access to credentials, enabling further compromise of the system and potential lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} known_false_positives = Limited false positives as the scope is limited to SAM, SYSTEM and SECURITY hives. @@ -5319,7 +5282,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities. +explanation = The following analytic detects attempts to read LSASS memory, indicative of credential dumping. It leverages Sysmon EventCode 10, filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process. This activity is significant because it suggests an attacker is trying to extract credentials from LSASS memory, potentially leading to unauthorized access, data breaches, and compromise of sensitive information. If confirmed malicious, this could enable attackers to escalate privileges, move laterally within the network, or exfiltrate data. Extensive triage is necessary to differentiate between malicious and benign activities. how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = The activity may be legitimate. Other tools can access lsass for legitimate reasons, and it's possible this event could be generated in those cases. In these cases, false positives should be fairly obvious and you may need to tweak the search to eliminate noise. @@ -5329,10 +5292,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the common PowerShell stager used by PowerShell-Empire. Each stager that may use PowerShell all uses the same pattern. The initial HTTP will be base64 encoded and use `system.net.webclient`. Note that some obfuscation may evade the analytic. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects suspicious PowerShell execution indicative of PowerShell-Empire activity. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze commands sent to PowerShell, specifically looking for patterns involving `system.net.webclient` and base64 encoding. This behavior is significant as it often represents initial stagers used by PowerShell-Empire, a known post-exploitation framework. If confirmed malicious, this activity could allow attackers to download and execute additional payloads, leading to potential code execution, data exfiltration, or further compromise of the affected system. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives may only pertain to it not being related to Empire, but another framework. Filter as needed if any applications use the same pattern. @@ -5364,7 +5324,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant. +explanation = The following analytic identifies the creation of suspicious .aspx files in known drop locations for Exchange exploitation, specifically targeting paths associated with HAFNIUM group and vulnerabilities like ProxyShell and ProxyNotShell. It leverages data from the Endpoint datamodel, focusing on process and filesystem events. This activity is significant as it may indicate a web shell deployment, a common method for persistent access and remote code execution. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary commands, and potentially escalate privileges within the Exchange environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. @@ -5374,7 +5334,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a renamed instance of hh.exe (HTML Help) executing a Compiled HTML Help (CHM). This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Validate it is the legitimate version of hh.exe by reviewing the PE metadata. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects instances where hh.exe (HTML Help) has been renamed and is executing a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because attackers can use renamed hh.exe to execute malicious scripts embedded in CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow attackers to run arbitrary scripts, escalate privileges, or persist within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.AE"]} known_false_positives = Although unlikely a renamed instance of hh.exe will be used legitimately, filter as needed. @@ -5384,7 +5344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) that spawns a child process. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review child process events and investigate further. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of hh.exe (HTML Help) spawning a child process, indicating the use of a Compiled HTML Help (CHM) file to execute Windows script code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where hh.exe is the parent process. This activity is significant as it may indicate an attempt to execute malicious scripts via CHM files, a known technique for bypassing security controls. If confirmed malicious, this could lead to unauthorized code execution, potentially compromising the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications (ex. web browsers) may spawn a child process. Filter as needed. @@ -5394,7 +5354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file from a remote url. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review reputation of remote IP and domain. Some instances, it is worth decompiling the .chm file to review its original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of hh.exe (HTML Help) loading a Compiled HTML Help (CHM) file from a remote URL. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing URLs. This activity is significant as it can indicate an attempt to execute malicious scripts via CHM files, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to run scripts using engines like JScript or VBScript, leading to further system compromise or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may retrieve a CHM remotely, filter as needed. @@ -5404,7 +5364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique will load Windows script code from a compiled help file, using InfoTech Storage Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm file from within a CHM file. CHM files may contain nearly any file type embedded. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of hh.exe (HTML Help) using InfoTech Storage Handlers to load Windows script code from a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because it can be used to execute malicious scripts embedded within CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} known_false_positives = It is rare to see instances of InfoTech Storage Handlers being used, but it does happen in some legitimate instances. Filter as needed. @@ -5414,10 +5374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies common Mimikatz functions that may be identified in the script block, including `mimikatz`. This will catch the most basic use cases for Pass the Ticket, Pass the Hash and `-DumprCreds`. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of Mimikatz commands via PowerShell by leveraging PowerShell Script Block Logging (EventCode=4104). This method captures and logs the full command sent to PowerShell, allowing for the identification of suspicious activities such as Pass the Ticket, Pass the Hash, and credential dumping. This activity is significant as Mimikatz is a well-known tool used for credential theft and lateral movement. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1003", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the commands being identifies are quite specific to EventCode 4104 and Mimikatz. Filter as needed. @@ -5427,7 +5384,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies "mshta.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "mshta.exe" and its parent process. +explanation = The following analytic detects the execution of "mshta.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments and process details. This activity is significant because mshta.exe can be exploited to execute malicious scripts, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or establish persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. @@ -5437,7 +5394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies renamed instances of mshta.exe executing. Mshta.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. This analytic utilizes the internal name of the PE to identify if is the legitimate mshta binary. Further analysis should be performed to review the executed content and validation it is the real mshta. +explanation = The following analytic identifies instances where mshta.exe has been renamed and executed. It leverages Endpoint Detection and Response (EDR) data, specifically focusing on the original file name field to detect discrepancies. This activity is significant because renaming mshta.exe is a common tactic used by attackers to evade detection and execute malicious scripts. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.AE"]} known_false_positives = Although unlikely, some legitimate applications may use a moved copy of mshta.exe, but never renamed, triggering a false positive. @@ -5447,7 +5404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies when Microsoft HTML Application Host (mshta.exe) utility is used to make remote http connections. Adversaries may use mshta.exe to proxy the download and execution of remote .hta files. The analytic identifies command line arguments of http and https being used. This technique is commonly used by malicious software to bypass preventative controls. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +explanation = The following analytic detects the use of Microsoft HTML Application Host (mshta.exe) to make remote HTTP or HTTPS connections. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments containing URLs. This activity is significant because adversaries often use mshta.exe to download and execute remote .hta files, bypassing security controls. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further network infiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} known_false_positives = It is possible legitimate applications may perform this behavior and will need to be filtered. @@ -5457,7 +5414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack. +explanation = The following analytic detects the creation of new accounts elevated to local administrators. It uses Windows event logs, specifically EventCode 4720 (user account creation) and EventCode 4732 (user added to Administrators group). This activity is significant as it indicates potential unauthorized privilege escalation, which is critical for SOC monitoring. If confirmed malicious, this could allow attackers to gain administrative access, leading to unauthorized data access, system modifications, and disruption of services. Immediate investigation is required to mitigate risks and prevent further unauthorized actions. how_to_implement = You must be ingesting Windows event logs using the Splunk Windows TA and collecting event code 4720 and 4732 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]} known_false_positives = The activity may be legitimate. For this reason, it's best to verify the account with an administrator and ask whether there was a valid service request for the account creation. If your local administrator group name is not "Administrators", this search may generate an excessive number of false positives @@ -5507,7 +5464,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for events where `PsExec.exe` is run with the `accepteula` flag in the command line. PsExec is a built-in Windows utility that enables you to execute processes on other systems. It is fully interactive for console applications. This tool is widely used for launching interactive command prompts on remote systems. Threat actors leverage this extensively for executing code on compromised systems. If an attacker is running PsExec for the first time, they will be prompted to accept the end-user license agreement (EULA), which can be passed as the argument `accepteula` within the command line. +explanation = The following analytic identifies the execution of `PsExec.exe` with the `accepteula` flag in the command line. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because PsExec is commonly used by threat actors to execute code on remote systems, and the `accepteula` flag indicates first-time usage, which could signify initial compromise. If confirmed malicious, this activity could allow attackers to gain remote code execution capabilities, potentially leading to further system compromise and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]} known_false_positives = Administrators can leverage PsExec for accessing remote systems and might pass `accepteula` as an argument if they are running this tool for the first time. However, it is not likely that you'd see multiple occurrences of this event on a machine @@ -5517,7 +5474,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the occurrence of rare processes that appear only once across the network within a specified timeframe. It operates by compiling a list of process executions. This detection is crucial for a Security Operations Center (SOC) as it helps in identifying potentially malicious activities or unauthorized software that could indicate a security breach or an ongoing attack. Identifying such rare processes allows for early detection of threats, minimizing the potential impact of an attack which could range from data theft to complete system compromise. +explanation = The following analytic detects the execution of rare processes that appear only once across the network within a specified timeframe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant for a SOC as it helps identify potentially malicious activities or unauthorized software, which could indicate a security breach or ongoing attack. If confirmed malicious, such rare processes could lead to data theft, privilege escalation, or complete system compromise, making early detection crucial for minimizing impact. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} known_false_positives = Some legitimate processes may be only rarely executed in your environment. @@ -5527,7 +5484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies commonly used command-line arguments used by `rclone.exe` to initiate a file transfer. Some arguments were negated as they are specific to the configuration used by adversaries. In particular, an adversary may list the files or directories of the remote file share using `ls` or `lsd`, which is not indicative of malicious behavior. During triage, at this stage of a ransomware event, exfiltration is about to occur or has already. Isolate the endpoint and continue investigating by review file modifications and parallel processes. +explanation = The following analytic detects the usage of `rclone.exe` with specific command-line arguments indicative of file transfer activities. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as `rclone.exe` is often used by adversaries for data exfiltration, especially during ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized data transfer, resulting in data breaches and potential loss of sensitive information. Immediate isolation of the affected endpoint and further investigation are recommended. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as this is restricted to the Rclone process name. Filter or tune the analytic as needed. @@ -5537,7 +5494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies regasm.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +explanation = The following analytic detects regasm.exe spawning a child process. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where regasm.exe is the parent process. This activity is significant because regasm.exe spawning a process is rare and can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5547,7 +5504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies regasm.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +explanation = The following analytic detects the execution of regasm.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon EventID 3 logs to identify such behavior. This activity is significant as regasm.exe is a legitimate Microsoft-signed binary that can be exploited to bypass application control mechanisms. If confirmed malicious, this behavior could indicate an adversary's attempt to establish a remote Command and Control (C2) channel, potentially leading to privilege escalation and further malicious actions within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regasm.exe with a network connection may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5557,7 +5514,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies regasm.exe with no command line arguments. This particular behavior occurs when another process injects into regasm.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`. +explanation = The following analytic detects instances of regasm.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regasm.exe. The detection leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line executions. This activity is significant as it may signal an attempt to evade detection or execute malicious code. If confirmed malicious, attackers could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. Investigate network connections, parallel processes, and suspicious module loads for further context. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regasm.exe or may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5567,7 +5524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies regsvcs.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +explanation = The following analytic identifies regsvcs.exe spawning a child process. This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is regsvcs.exe. This activity is significant because regsvcs.exe rarely spawns child processes, and such behavior can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated suspicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5577,7 +5534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies Regsvcs.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +explanation = The following analytic identifies instances of Regsvcs.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon Event ID 3 logs to monitor network connections initiated by Regsvcs.exe. This activity is significant as Regsvcs.exe, a legitimate Microsoft-signed binary, can be exploited to bypass application control mechanisms and establish remote Command and Control (C2) channels. If confirmed malicious, this behavior could allow an attacker to escalate privileges, persist in the environment, and exfiltrate sensitive data. Immediate investigation and remediation are recommended. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5587,7 +5544,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies regsvcs.exe with no command line arguments. This particular behavior occurs when another process injects into regsvcs.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +explanation = The following analytic detects instances of regsvcs.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regsvcs.exe. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, IDs, and command-line executions. This activity is significant as it may signal an attempt to evade detection and execute malicious code. If confirmed malicious, the attacker could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. @@ -5597,8 +5554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is often referred to as a "Squiblydoo" attack. \ -Upon investigating, look for network connections to remote destinations (internal or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon execution. +explanation = The following analytic identifies the abuse of Regsvr32.exe to proxy execution of malicious code, specifically detecting the loading of "scrobj.dll" by Regsvr32.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line executions. This activity is significant because Regsvr32.exe is a trusted, signed Microsoft binary, often used in "Squiblydoo" attacks to bypass application control mechanisms. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise and persistent access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"]} known_false_positives = Limited false positives related to third party software registering .DLL's. @@ -5608,7 +5564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when a file from a known remote access software is written to disk within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects the writing of files from known remote access software to disk within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on file path, file name, and user information. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration, further compromise, or complete control over affected systems. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the file path, file name, and the user that created the file. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = Known or approved applications used by the organization or usage of built-in functions. @@ -5618,7 +5574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when process with file or code signing attributes from a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects the execution of processes with file or code signing attributes from known remote access software within the environment. It leverages Sysmon EventCode 1 data and cross-references a lookup table of remote access utilities such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use these tools to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration or further compromise of the network. how_to_implement = This analytic relies on Sysmon to be properly installed and utilized in the environment. Ensure that proper logging is setup for Sysmon and data is being ingested into Splunk. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = Known or approved applications used by the organization or usage of built-in functions. @@ -5628,7 +5584,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when a known remote access software is executed within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects the execution of known remote access software within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes mapped to the Endpoint data model. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or deploy additional malware, posing a severe threat to the organization's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. @@ -5638,7 +5594,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies renamed 7-Zip usage using Sysmon. At this stage of an attack, review parallel processes and file modifications for data that is staged or potentially have been exfiltrated. This analytic utilizes the OriginalFileName to capture the renamed process. During triage, validate this is the legitimate version of `7zip` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +explanation = The following analytic detects the usage of a renamed 7-Zip executable using Sysmon data. It leverages the OriginalFileName field to identify instances where the 7-Zip process has been renamed. This activity is significant as attackers often rename legitimate tools to evade detection while staging or exfiltrating data. If confirmed malicious, this behavior could indicate data exfiltration attempts or other unauthorized data manipulation, potentially leading to significant data breaches or loss of sensitive information. Analysts should validate the legitimacy of the 7-Zip executable and investigate parallel processes for further suspicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} known_false_positives = Limited false positives, however this analytic will need to be modified for each environment if Sysmon is not used. @@ -5648,7 +5604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies renamed instances of `PsExec.exe` being utilized on an endpoint. Most instances, it is highly probable to capture `Psexec.exe` or other SysInternal utility usage with the command-line argument of `-accepteula`. During triage, validate this is the legitimate version of `PsExec` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +explanation = The following analytic identifies instances where `PsExec.exe` has been renamed and executed on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because renaming `PsExec.exe` is a common tactic to evade detection. If confirmed malicious, this could allow an attacker to execute commands remotely, potentially leading to unauthorized access, lateral movement, or further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]} known_false_positives = Limited false positives should be present. It is possible some third party applications may use older versions of PsExec, filter as needed. @@ -5658,7 +5614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the usage of `rclone.exe`, renamed, being used to exfiltrate data to a remote destination. RClone has been used by multiple ransomware groups to exfiltrate data. In many instances, it will be downloaded from the legitimate site and executed accordingly. During triage, isolate the endpoint and begin to review parallel processes for additional behavior. At this stage, the adversary may have staged data to be exfiltrated. +explanation = The following analytic detects the execution of a renamed `rclone.exe` process, which is commonly used for data exfiltration to remote destinations. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and original file names that do not match. This activity is significant because ransomware groups often use RClone to exfiltrate sensitive data. If confirmed malicious, this behavior could indicate an ongoing data exfiltration attempt, potentially leading to significant data loss and further compromise of the affected systems. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited as this analytic identifies renamed instances of `rclone.exe`. Filter as needed if there is a legitimate business use case. @@ -5668,7 +5624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analtyic identifies renamed instances of `WinRAR.exe`. In most cases, it is not common for WinRAR to be used renamed, however it is common to be installed by a third party application and executed from a non-standard path. During triage, validate additional metadata from the binary that this is `WinRAR`. Review parallel processes and file modifications. +explanation = The following analytic identifies instances where `WinRAR.exe` has been renamed and executed. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names within the Endpoint data model. This activity is significant because renaming executables is a common tactic used by attackers to evade detection. If confirmed malicious, this could indicate an attempt to bypass security controls, potentially leading to unauthorized data extraction or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} known_false_positives = Unknown. It is possible third party applications use renamed instances of WinRAR. @@ -5678,7 +5634,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +explanation = The following analytic identifies the use of the right-to-left override (RTLO) character in file names. It leverages data from the Endpoint.Filesystem datamodel, specifically focusing on file creation events and file names containing the RTLO character (U+202E). This activity is significant because adversaries use RTLO to disguise malicious files as benign by reversing the text that follows the character. If confirmed malicious, this technique can deceive users and security tools, leading to the execution of harmful files and potential system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that includes the full command line of the process being launched on your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]} known_false_positives = Implementation in regions that use right to left in native language. @@ -5688,7 +5644,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +explanation = The following analytic identifies the abuse of the right-to-left override (RTLO) character (U+202E) in process names. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line data. This activity is significant because adversaries use the RTLO character to disguise malicious files or commands, making them appear benign. If confirmed malicious, this technique can allow attackers to execute harmful code undetected, potentially leading to unauthorized access, data exfiltration, or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]} known_false_positives = Implementation in regions that use right to left in native language. @@ -5698,7 +5654,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe loading advpack.dll and ieadvpack.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +explanation = The following analytic detects the execution of rundll32.exe loading advpack.dll or ieadvpack.dll via the LaunchINFSection function. This method is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate script content, network connections, and any spawned child processes for further context. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use advpack.dll or ieadvpack.dll, triggering a false positive. @@ -5708,7 +5664,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe loading setupapi.dll and iesetupapi.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +explanation = The following analytic detects the execution of rundll32.exe loading setupapi.dll and iesetupapi.dll via the LaunchINFSection function. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events and command-line arguments. This activity is significant as it indicates a potential application control bypass, allowing an attacker to execute arbitrary script code. If confirmed malicious, this technique could enable code execution, privilege escalation, or persistence within the environment, posing a severe threat to system integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use setupapi triggering a false positive. @@ -5718,7 +5674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe loading syssetup.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +explanation = The following analytic detects the execution of rundll32.exe loading syssetup.dll via the LaunchINFSection function. This method is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate the script content, network connections, and any spawned child processes for further context. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use syssetup.dll, triggering a false positive. @@ -5728,7 +5684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies "rundll32.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. This type of behavior is commonly observed with fileless malware or application whitelisting bypass techniques. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +explanation = The following analytic detects the execution of "rundll32.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line arguments. This activity is significant as it is often associated with fileless malware or application whitelisting bypass techniques. If confirmed malicious, this could allow an attacker to execute arbitrary code, bypass security controls, and maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. @@ -5738,7 +5694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies common command-line arguments used by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +explanation = The following analytic detects the execution of SharpHound command-line arguments, specifically `-collectionMethod` and `invoke-bloodhound`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as SharpHound is commonly used for Active Directory enumeration, which can be a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially compromising sensitive information and critical systems. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the arguments used are specific to SharpHound. Filter as needed or add more command-line arguments as needed. @@ -5748,7 +5704,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. SharpHound will query the domain controller and begin gathering all the data related to the domain and trusts. For output, it will drop a .zip file upon completion following a typical pattern that is often not changed. This analytic focuses on the default file name scheme. Note that this may be evaded with different parameters within SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` are two examples. In addition, executing SharpHound via .exe or .ps1 without any command-line arguments will still perform activity and dump output to the default filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates multiple temp files following the same pattern `20210601182121_computers.json`, `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, or remove these json's entirely if it is too noisy. During traige, review parallel processes for further suspicious behavior. Typically, the process executing the `.ps1` ingestor will be PowerShell. +explanation = The following analytic detects the creation of files typically associated with SharpHound, a reconnaissance tool used for gathering domain and trust data. It leverages file modification events from the Endpoint.Filesystem data model, focusing on default file naming patterns like `*_BloodHound.zip` and various JSON files. This activity is significant as it indicates potential domain enumeration, which is a precursor to more targeted attacks. If confirmed malicious, an attacker could gain detailed insights into the domain structure, facilitating lateral movement and privilege escalation. how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed. @@ -5758,7 +5714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies SharpHound binary usage by using the original filena,e. In addition to renaming the PE, other coverage is available to detect command-line arguments. This particular analytic looks for the original_file_name of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe have different original filenames. Dependent upon the operator, the code may be re-compiled and the attributes removed or changed to anything else. During triage, review the metadata of the binary in question. Review parallel processes for suspicious behavior. Identify the source of this binary. +explanation = The following analytic detects the usage of the SharpHound binary by identifying its original filename, `SharpHound.exe`, and the process name. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process metadata and command-line executions. SharpHound is a tool used for Active Directory enumeration, often by attackers during the reconnaissance phase. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially leading to privilege escalation and lateral movement within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as this is specific to a file attribute not used by anything else. Filter as needed. @@ -5768,7 +5724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses a pre-trained Deep Learning model to predict whether a processname is suspicious or not. Malwares and malicious programs such as ransomware often use tactics, techniques, and procedures (TTPs) such as copying malicious files to the local machine to propagate themselves across the network. A key indicator of compromise is that after a successful execution of the malware, it copies itself as an executable file with a randomly generated filename and places this file in one of the directories. Such techniques are seen in several malwares such as TrickBot. We develop machine learning model that uses a Recurrent Neural Network (RNN) to distinguish between malicious and benign processnames. The model is trained independently and is then made available for download. We use a character level RNN to classify malicious vs. benign processnames. The higher is_malicious_prob, the more likely is the processname to be suspicious (between [0,1]). The threshold for flagging a processname as suspicious is set as 0.5. +explanation = The following analytic identifies suspicious process names using a pre-trained Deep Learning model. It leverages Endpoint Detection and Response (EDR) telemetry to analyze process names and predict their likelihood of being malicious. The model, a character-level Recurrent Neural Network (RNN), classifies process names as benign or suspicious based on a threshold score of 0.5. This detection is significant as it helps identify malware, such as TrickBot, which often uses randomly generated filenames to evade detection. If confirmed malicious, this activity could indicate the presence of malware capable of propagating across the network and executing harmful actions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if a suspicious processname is similar to a benign processname. @@ -5778,7 +5734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for the execution of the cscript.exe or wscript.exe processes, with a parent of cmd.exe. The search will return the count, the first and last time this execution was seen on a machine, the user, and the destination of the machine +explanation = The following analytic detects the execution of cscript.exe or wscript.exe processes initiated by cmd.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes within the Endpoint data model. This activity is significant as it may indicate script-based attacks or administrative actions that could be leveraged for malicious purposes. If confirmed malicious, this behavior could allow attackers to execute scripts, potentially leading to code execution, privilege escalation, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"]} known_false_positives = This detection may also be triggered by legitimate applications and numerous service accounts, which often end with a $ sign. To manage this, it's advised to check the service account's activities and, if they are valid, modify the filter macro to exclude them. @@ -5788,7 +5744,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is used to detect the abuse of web applications by adversaries. Adversaries may install a backdoor or script onto web servers by exploiting known vulnerabilities or misconfigruations. Web shells are used to establish persistent access to systems and provide a set of executable functions or a command-line interface on the system hosting the Web server. +explanation = The following analytic identifies the execution of suspicious processes typically associated with webshell activity on web servers. It detects when processes like `cmd.exe`, `powershell.exe`, or `bash.exe` are spawned by web server processes such as `w3wp.exe` or `nginx.exe`. This behavior is significant as it may indicate an adversary exploiting a web application vulnerability to install a webshell, providing persistent access and command execution capabilities. If confirmed malicious, this activity could allow attackers to maintain control over the compromised server, execute arbitrary commands, and potentially escalate privileges or exfiltrate sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate OS functions called by vendor applications, baseline the environment and filter before enabling. Recommend throttle by dest/process_name @@ -5798,12 +5754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. \ -All event subscriptions have three components \ -1. Filter - WQL Query for the events we want. EventID equals 19 \ -1. Consumer - An action to take upon triggering the filter. EventID equals 20 \ -1. Binding - Registers a filter to a consumer. EventID equals 21 \ -Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. +explanation = The following analytic identifies the creation of WMI Event Subscriptions, which can be used to establish persistence or perform privilege escalation. It detects EventID 19 (EventFilter creation), EventID 20 (EventConsumer creation), and EventID 21 (FilterToConsumerBinding creation) from Sysmon logs. This activity is significant because WMI Event Subscriptions can execute code with elevated SYSTEM privileges, making it a powerful persistence mechanism. If confirmed malicious, an attacker could maintain long-term access, escalate privileges, and execute arbitrary code, posing a severe threat to the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with that provide WMI Event Subscription from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA and have enabled EventID 19, 20 and 21. Tune and filter known good to limit the volume. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"]} known_false_positives = It is possible some applications will create a consumer and may be required to be filtered. For tuning, add any additional LOLBin's for further depth of coverage. @@ -5823,7 +5774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this search is to identify modification in registry to disable AMSI windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +explanation = The following analytic detects modifications to the Windows registry that disable the Antimalware Scan Interface (AMSI) by setting the "AmsiEnable" value to "0x00000000". This detection leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable". Disabling AMSI is significant as it is a common technique used by ransomware, Remote Access Trojans (RATs), and Advanced Persistent Threats (APTs) to evade detection and impair defenses. If confirmed malicious, this activity could allow attackers to execute payloads with minimal alerts, leading to potential system compromise and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = network operator may disable this feature of windows but not so common. @@ -5833,7 +5784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +explanation = The following analytic detects the modification of Windows Defender registry settings to disable antivirus and antispyware protections. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with Windows Defender policies. This activity is significant because disabling antivirus protections is a common tactic used by adversaries to evade detection and maintain persistence on compromised systems. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches, system compromise, and further propagation of malware within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable windows defender product @@ -5843,7 +5794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks suspicious files the first time seen on the host. +explanation = The following analytic detects the modification of the Windows registry to disable the Windows Defender BlockAtFirstSeen feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the DisableBlockAtFirstSeen value. This activity is significant because disabling this feature can allow malicious files to bypass initial detection by Windows Defender, increasing the risk of malware infection. If confirmed malicious, this action could enable attackers to execute malicious code undetected, leading to potential system compromise and data breaches. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable windows defender product @@ -5853,7 +5804,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is intended to detect a suspicious modification of registry to disable windows defender features. This technique attempts to bypass or evade detection from Windows Defender AV, specifically the Enhanced Notification feature where a user or admin would receive alerts. +explanation = The following analytic detects the modification of the registry to disable Windows Defender's Enhanced Notification feature. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring changes to the registry path associated with Windows Defender reporting. This activity is significant because disabling Enhanced Notifications can prevent users and administrators from receiving critical security alerts, potentially allowing malicious activities to go unnoticed. If confirmed malicious, this action could enable an attacker to bypass detection mechanisms, maintain persistence, and escalate their activities without triggering alerts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = user may choose to disable windows defender AV @@ -5863,7 +5814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +explanation = The following analytic detects the modification of the Windows Defender MpEngine registry value, specifically setting MpEnablePus to 0x00000000. This detection leverages endpoint registry logs, focusing on changes within the path "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*". This activity is significant as it indicates an attempt to disable key Windows Defender features, potentially allowing malware to evade detection. If confirmed malicious, this could lead to undetected malware execution, persistence, and further system compromise. Immediate investigation and endpoint isolation are recommended. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable windows defender product @@ -5883,7 +5834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the feature that submits samples for further analysis. +explanation = The following analytic detects the modification of the Windows registry to disable the Windows Defender Submit Samples Consent feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the SubmitSamplesConsent value set to 0x00000000. This activity is significant as it indicates an attempt to bypass or evade detection by preventing Windows Defender from submitting samples for further analysis. If confirmed malicious, this could allow an attacker to execute malicious code without being detected by Windows Defender, leading to potential system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable windows defender product @@ -5893,7 +5844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to identify modification in registry to disable ETW windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +explanation = The following analytic detects modifications to the registry that disable the Event Tracing for Windows (ETW) feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\.NETFramework\\ETWEnabled" with a value set to "0x00000000". This activity is significant because disabling ETW can allow attackers to evade detection mechanisms, making it harder for security tools to monitor malicious activities. If confirmed malicious, this could enable attackers to execute payloads with minimal alerts, impairing defenses and potentially leading to further compromise of the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = network operator may disable this feature of windows but not so common. @@ -5913,7 +5864,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search identifies modification of registry to disable the regedit or registry tools of the windows operating system. Since registry tool is a swiss knife in analyzing registry, malware such as RAT or trojan Spy disable this application to prevent the removal of their registry entry such as persistence, file less components and defense evasion. +explanation = The following analytic detects modifications to the Windows registry aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" with a value of "0x00000001". This activity is significant because malware, such as RATs or trojans, often disable registry tools to prevent the removal of their entries, aiding in persistence and defense evasion. If confirmed malicious, this could hinder incident response efforts and allow the attacker to maintain control over the compromised system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} known_false_positives = admin may disable this application for non technical user. @@ -5923,7 +5874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious commandline to disable existing schedule task. This technique is used by adversaries or commodity malware like IcedID to disable security application (AV products) in the targetted host to evade detections. This TTP is a good pivot to check further why and what other process run before and after this detection. check which process execute the commandline and what task is disabled. parent child process is quite valuable in this scenario too. +explanation = The following analytic detects the execution of a command to disable an existing scheduled task using 'schtasks.exe' with the '/change' and '/disable' parameters. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Disabling scheduled tasks is significant as it is a common tactic used by adversaries, including malware like IcedID, to disable security applications and evade detection. If confirmed malicious, this activity could allow attackers to persist undetected, disable critical security defenses, and further compromise the targeted host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin may disable problematic schedule task @@ -5933,7 +5884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable security audit logs. This technique was shared by a researcher to disable Security logs of windows by adding this registry. The Windows will think it is WinPE and will not log any event to the Security Log +explanation = The following analytic detects a suspicious registry modification aimed at disabling security audit logs by adding a specific registry entry. It leverages data from the Endpoint.Registry data model, focusing on changes to the "Control\\MiniNt" registry path. This activity is significant because it can prevent Windows from logging any events to the Security Log, effectively blinding security monitoring efforts. If confirmed malicious, this technique could allow an attacker to operate undetected, making it difficult to trace their actions and compromising the integrity of security audits. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Unknown. @@ -5943,7 +5894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to prevent users from seeing all the files with hidden attributes. This event or techniques are known on some worm and trojan spy malware that will drop hidden files on the infected machine. +explanation = The following analytic detects modifications to the Windows registry that disable the display of hidden files. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with hidden file settings. This activity is significant because malware, such as worms and trojan spyware, often use hidden files to evade detection. If confirmed malicious, this behavior could allow an attacker to conceal malicious files on the system, making it harder for security tools and analysts to identify and remove the threat. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.001", "T1562.001", "T1564", "T1562", "T1112"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -5953,7 +5904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious modification of registry to disable UAC remote restriction. This technique was well documented in Microsoft page where attacker may modify this registry value to bypassed UAC feature of windows host. This is a good indicator that some tries to bypassed UAC to suspicious process or gain privilege escalation. +explanation = The following analytic detects the modification of the registry to disable UAC remote restriction by setting the "LocalAccountTokenFilterPolicy" value to "0x00000001". It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\CurrentVersion\\Policies\\System*". This activity is significant because disabling UAC remote restriction can allow an attacker to bypass User Account Control (UAC) protections, potentially leading to privilege escalation. If confirmed malicious, this could enable an attacker to execute unauthorized actions with elevated privileges, compromising the security of the affected system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = admin may set this policy for non-critical machine. @@ -5963,7 +5914,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a suspicious registry modification to disable Windows hotkey (shortcut keys) for native Windows applications. This technique is commonly used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. This technique is used to impair the analyst in analyzing and removing the attacker implant in compromised systems. +explanation = The following analytic detects a suspicious registry modification aimed at disabling Windows hotkeys for native applications. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values indicative of this behavior. This activity is significant as it can impair an analyst's ability to use essential tools like Task Manager and Command Prompt, hindering incident response efforts. If confirmed malicious, this technique can allow an attacker to maintain persistence and evade detection, complicating the remediation process. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -5983,7 +5934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following search identifies a modification of registry to disable the smartscreen protection of windows machine. This is windows feature provide an early warning system against website that might engage in phishing attack or malware distribution. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload. +explanation = The following analytic detects modifications to the Windows registry that disable SmartScreen protection. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with SmartScreen settings. This activity is significant because SmartScreen provides an early warning system against phishing and malware. Disabling it can indicate malicious intent, often seen in Remote Access Trojans (RATs) to evade detection while downloading additional payloads. If confirmed malicious, this action could allow attackers to bypass security measures, increasing the risk of successful phishing attacks and malware infections. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable this windows features. @@ -5993,7 +5944,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUser` commandlet with specific parameters. `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Get-ADUser` is used to query for domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack their passwords offline. +explanation = The following analytic detects the execution of the `Get-ADUser` PowerShell cmdlet with parameters indicating a search for domain accounts with Kerberos Pre-Authentication disabled. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific activity. This behavior is significant because discovering accounts with Kerberos Pre-Authentication disabled can allow adversaries to perform offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to user accounts, potentially compromising sensitive information and escalating privileges within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use search for accounts with Kerberos Pre Authentication disabled for legitimate purposes. @@ -6003,8 +5954,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet with specific parameters. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is used to identify domain users and combining it with `-PreauthNotRequired` allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled. \ -Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts and attempt to crack their passwords offline. +explanation = The following analytic detects the execution of the `Get-DomainUser` commandlet with the `-PreauthNotRequired` parameter using PowerShell Script Block Logging (EventCode=4104). This command is part of PowerView, a tool used for enumerating Windows Active Directory networks. Identifying domain accounts with Kerberos Pre-Authentication disabled is significant because adversaries can leverage this information to attempt offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to domain accounts, potentially compromising sensitive information and escalating privileges within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use PowerView for troubleshooting @@ -6014,7 +5964,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to identify modification in registry to disable cmd prompt application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging or deleting there samples through cmd application which is one of the tool of analyst to traverse on directory and files. +explanation = The following analytic detects modifications to the registry that disable the CMD prompt application. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableCMD" registry value. This activity is significant because disabling CMD can hinder an analyst's ability to investigate and remediate threats, a tactic often used by malware such as RATs, Trojans, or Worms. If confirmed malicious, this could prevent security teams from using CMD for directory and file traversal, complicating incident response and allowing the attacker to maintain persistence. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} known_false_positives = admin may disable this application for non technical user. @@ -6034,7 +5984,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This particular behavior is typically executed when an adversaries or malware gains access to an endpoint and beings to perform execution and to evade detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +explanation = The following analytic detects the disabling of Windows Defender services by monitoring registry modifications. It leverages registry event data to identify changes to specific registry paths associated with Defender services, where the 'Start' value is set to '0x00000004'. This activity is significant because disabling Defender services can indicate an attempt by an adversary to evade detection and maintain persistence on the endpoint. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches or system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to disable windows defender product @@ -6054,7 +6004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to identify registry modification to disable folder options feature of windows to show hidden files, file extension and etc. This technique used by malware in combination if disabling show hidden files feature to hide their files and also to hide the file extension to lure the user base on file icons or fake file extensions. +explanation = The following analytic detects the modification of the Windows registry to disable the Folder Options feature, which prevents users from showing hidden files and file extensions. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions" with a value of "0x00000001". This activity is significant as it is commonly used by malware to conceal malicious files and deceive users with fake file extensions. If confirmed malicious, this could allow an attacker to hide their presence and malicious files, making detection and remediation more difficult. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin may disable this application for non technical user. @@ -6074,7 +6024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to identify modification of registry to disable run application in window start menu. this application is known to be a helpful shortcut to windows OS user to run known application and also to execute some reg or batch script. This technique is used malware to make cleaning of its infection more harder by preventing known application run easily through run shortcut. +explanation = The following analytic detects the modification of the Windows registry to disable the Run application in the Start menu. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" with a value of "0x00000001". This activity is significant because the Run application is a useful shortcut for executing known applications and scripts. If confirmed malicious, this action could hinder system cleaning efforts and make it more difficult to run essential tools, thereby aiding malware persistence. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} known_false_positives = admin may disable this application for non technical user. @@ -6094,7 +6044,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following search identifies the modification of registry related in disabling the system restore of a machine. This event or behavior are seen in some RAT malware to make the restore of the infected machine difficult and keep their infection on the box. +explanation = The following analytic detects the modification of registry keys to disable System Restore on a machine. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with System Restore settings. This activity is significant because disabling System Restore can hinder recovery efforts and is a tactic often used by Remote Access Trojans (RATs) to maintain persistence on an infected system. If confirmed malicious, this action could prevent system recovery, allowing the attacker to sustain their foothold and potentially cause further damage or data loss. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = in some cases admin can disable systemrestore on a machine. @@ -6104,7 +6054,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to identifies modification of registry to disable the task manager of windows operating system. this event or technique are commonly seen in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate their process. +explanation = The following analytic identifies modifications to the Windows registry that disable Task Manager. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" with a value of "0x00000001". This activity is significant as it is commonly associated with malware such as RATs, Trojans, and worms, which disable Task Manager to prevent users from terminating malicious processes. If confirmed malicious, this could allow attackers to maintain persistence and control over the infected system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin may disable this application for non technical user. @@ -6124,7 +6074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies DLLHost.exe with no command line arguments with a network connection. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects instances of DLLHost.exe running without command line arguments while establishing a network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network activity data. It is significant because DLLHost.exe typically runs with specific arguments, and its absence can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers to execute code, move laterally, or exfiltrate data, posing a severe threat to the network's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate third party applications may use a moved copy of dllhost, triggering a false positive. @@ -6134,7 +6084,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +explanation = The following analytic identifies potential DNS exfiltration using the nslookup application. It detects specific command-line parameters such as query type (TXT, A, AAAA) and retry options, which are commonly used by attackers to exfiltrate data. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution logs. This activity is significant as it may indicate an attempt to communicate with a Command and Control (C2) server or exfiltrate sensitive data. If confirmed malicious, this could lead to data breaches and unauthorized access to critical information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"]} known_false_positives = admin nslookup usage @@ -6144,7 +6094,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover domain users. The `user` argument returns a list of all users registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to discover domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to map out domain users, which is a common precursor to further attacks. If confirmed malicious, this behavior could allow attackers to gain insights into user accounts, facilitating subsequent actions like privilege escalation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6154,7 +6104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike may use net.exe to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out user accounts, potentially leading to further exploitation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6174,7 +6124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `nltest.exe` with command-line arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', can be used to return a list of all domain controllers. Red Teams and adversaries alike may use nltest.exe to identify domain controllers in a Windows Domain for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `nltest.exe` with command-line arguments `/dclist:` or `/dsgetdc:` to discover domain controllers. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `nltest.exe` for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out domain controllers, facilitating further attacks such as privilege escalation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6184,7 +6134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command line return a list of all domain controllers in a Windows domain. Red Teams and adversaries alike use *.exe to identify remote systems for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to discover domain controllers in a Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it is commonly used by adversaries and Red Teams for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the network, identify key systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6194,7 +6144,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain groups. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `[adsisearcher]` and group-related queries. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain groups for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, privilege escalation, or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use Adsisearcher for troubleshooting. @@ -6204,7 +6154,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to query for domain groups. The argument `group`, returns a list of all domain groups. Red Teams and adversaries alike use may leverage dsquery.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to query for domain groups. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `dsquery.exe` to enumerate domain groups, gaining situational awareness and facilitating further Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the domain structure, identify high-value targets, and plan subsequent attacks, potentially leading to privilege escalation or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6214,7 +6164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` with command-line arguments utilized to query for domain groups. The argument `group /domain`, returns a list of all domain groups. Red Teams and adversaries alike use net.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `net.exe` with command-line arguments used to query domain groups, specifically `group /domain`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain groups, which is a common step in Active Directory Discovery. If confirmed malicious, this behavior could allow attackers to gain insights into the domain structure, aiding in further attacks such as privilege escalation or lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6224,7 +6174,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for domain groups. The arguments utilized in this command return a list of all domain groups. Red Teams and adversaries alike use wmic.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to query for domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to gain situational awareness and map out Active Directory structures. If confirmed malicious, this behavior could allow attackers to identify and target specific domain groups, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6234,7 +6184,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic will identify a suspicious download by the Telegram application on a Windows system. This behavior was identified on a honeypot where the adversary gained access, installed Telegram and followed through with downloading different network scanners (port, bruteforcer, masscan) to the system and later used to mapped the whole network and further move laterally. +explanation = The following analytic detects suspicious file downloads by the Telegram application on a Windows system. It leverages Sysmon EventCode 15 to identify instances where Telegram.exe creates files with a Zone.Identifier, indicating a download. This activity is significant as it may indicate an adversary using Telegram to download malicious tools, such as network scanners, for further exploitation. If confirmed malicious, this behavior could lead to network mapping, lateral movement, and potential compromise of additional systems within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and TargetFilename from your endpoints or Events that monitor filestream events which is happened when process download something. (EventCode 15) If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = normal download of file in telegram app. (if it was a common app in network) @@ -6244,7 +6194,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect dropping a suspicious file named as "license.dat" in %appdata%. This behavior seen in latest IcedID malware that contain the actual core bot that will be injected in other process to do banking stealing. +explanation = The following analytic detects the dropping of a suspicious file named "license.dat" in %appdata% or %programdata%. This behavior is associated with the IcedID malware, which uses this file to inject its core bot into other processes for banking credential theft. The detection leverages Sysmon EventCode 11 to monitor file creation events in these directories. This activity is significant as it indicates a potential malware infection aiming to steal sensitive banking information. If confirmed malicious, the attacker could gain unauthorized access to financial data, leading to significant financial loss and data breaches. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -6254,12 +6204,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies "dsquery.exe" execution with arguments looking for `TrustedDomain` query directly on the command-line. This is typically indicative of an Administrator or adversary perform domain trust discovery. Note that this query does not identify any other variations of "Dsquery.exe" usage. \ -Within this detection, it is assumed `dsquery.exe` is not moved or renamed. \ -The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "dsquery.exe" and its parent process. \ -DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` and only on Server operating system. \ -The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found loaded by another process, it is possible dsquery is running within that process context in memory. \ -In addition to trust discovery, review parallel processes for additional behaviors performed. Identify the parent process and capture any files (batch files, for example) being used. +explanation = The following analytic detects the execution of "dsquery.exe" with arguments targeting `TrustedDomain` queries directly from the command line. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line arguments. This activity is significant as it often indicates domain trust discovery, a common step in lateral movement or privilege escalation by adversaries. If confirmed malicious, this could allow attackers to map domain trusts, potentially leading to further exploitation and unauthorized access to trusted domains. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} known_false_positives = Limited false positives. If there is a true false positive, filter based on command-line or parent process. @@ -6269,7 +6214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source. +explanation = The following analytic detects the behavior of dumping credentials from memory by exploiting the Local Security Authority Subsystem Service (LSASS) using the comsvcs.dll and MiniDump via rundll32. This detection leverages process information from Endpoint Detection and Response (EDR) logs, focusing on specific command-line executions. This activity is significant because it indicates potential credential theft, which can lead to broader system compromise, persistence, lateral movement, and privilege escalation. If confirmed malicious, attackers could gain unauthorized access to sensitive information, leading to data theft, ransomware attacks, or other damaging outcomes. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = None identified. @@ -6279,8 +6224,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Detect procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. This query does not monitor for the internal name (original_file_name=procdump) of the PE or look for procdump64.exe. Modify the query as needed. \ -During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe. +explanation = The following analytic detects the use of procdump.exe to dump the LSASS process, specifically looking for the -mm and -ma command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant because dumping LSASS can expose sensitive credentials, posing a severe security risk. If confirmed malicious, an attacker could obtain credentials, escalate privileges, and move laterally within the network, leading to potential data breaches and further compromise of the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = None identified. @@ -6290,7 +6234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for specific elevated domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +explanation = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query elevated domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within Active Directory. If confirmed malicious, this behavior could lead to further attacks aimed at compromising privileged accounts, escalating privileges, or gaining unauthorized access to sensitive systems and data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6300,7 +6244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroupMember` commandlet. `Get-DomainGroupMember` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroupMember` is used to list the members of an specific domain group. Red Teams and adversaries alike use PowerView to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +explanation = The following analytic detects the execution of the `Get-DomainGroupMember` cmdlet from PowerView, identified through PowerShell Script Block Logging (EventCode=4104). This cmdlet is used to enumerate members of elevated domain groups such as Domain Admins and Enterprise Admins. Monitoring this activity is crucial as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within the domain. If confirmed malicious, this activity could lead to targeted attacks on privileged accounts, facilitating further compromise and lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerView for troubleshooting. @@ -6310,7 +6254,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for specific domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +explanation = The following analytic detects the execution of `wmic.exe` with command-line arguments querying specific elevated domain groups. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes that access the LDAP namespace and search for groups like "Domain Admins" or "Enterprise Admins." This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privilege accounts within Active Directory. If confirmed malicious, this behavior could lead to privilege escalation, allowing attackers to gain elevated access and control over critical network resources. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6320,7 +6264,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a modification to registry to enable rdp to a machine with different port number. This technique was seen in some atttacker tries to do lateral movement and remote access to a compromised machine to gain control of it. +explanation = The following analytic detects modifications to the registry that enable RDP on a machine using a non-default port number. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" and the "PortNumber" value. This activity is significant as attackers often modify RDP settings to facilitate lateral movement and maintain remote access to compromised systems. If confirmed malicious, this could allow attackers to bypass network defenses, gain persistent access, and potentially control the compromised machine. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -6330,7 +6274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to enable plain text credential feature of windows. This technique was used by several malware and also by mimikatz to be able to dumpe the a plain text credential to the compromised or target host. This TTP is really a good indicator that someone wants to dump the crendential of the host so it must be a good pivot for credential dumping techniques. +explanation = The following analytic detects a suspicious registry modification that enables the plain text credential feature in Windows by setting the "UseLogonCredential" value to 1 in the WDigest registry path. This detection leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because it is commonly used by malware and tools like Mimikatz to dump plain text credentials, indicating a potential credential dumping attempt. If confirmed malicious, this could allow an attacker to obtain sensitive credentials, leading to further compromise and lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1003"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -6340,7 +6284,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect a suspicious Telegram process enumerating all network users in a local group. This technique was seen in a Monero infected honeypot to mapped all the users on the compromised system. EventCode 4798 is generated when a process enumerates a user's security-enabled local groups on a computer or device. +explanation = The following analytic detects a Telegram process enumerating all network users in a local group. It leverages EventCode 4798, which is generated when a process enumerates a user's security-enabled local groups on a computer or device. This activity is significant as it may indicate an attempt to gather information on user accounts, a common precursor to further malicious actions. If confirmed malicious, this behavior could allow an attacker to map out user accounts, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Task Schedule (Exa. Security Log EventCode 4798) endpoints. Tune and filter known instances of process like logonUI used in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -6350,7 +6294,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the process - `esentutl.exe` - being used to capture credentials stored in ntds.dit or the SAM file on disk. During triage, review parallel processes and determine if legitimate activity. Upon determination of illegitimate activity, take further action to isolate and contain the threat. +explanation = The following analytic detects the use of `esentutl.exe` to access credentials stored in the ntds.dit or SAM file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it may indicate an attempt to extract sensitive credential information, which is a common tactic in lateral movement and privilege escalation. If confirmed malicious, this could allow an attacker to gain unauthorized access to user credentials, potentially compromising the entire network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited. Filter as needed. @@ -6370,7 +6314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following search identifies Eventvwr bypass by identifying the registry modification into a specific path that eventvwr.msc looks to (but is not valid) upon execution. A successful attack will include a suspicious command to be executed upon eventvwr.msc loading. Upon triage, review the parallel processes that have executed. Identify any additional registry modifications on the endpoint that may look suspicious. Remediate as necessary. +explanation = The following analytic detects an Eventvwr UAC bypass by identifying suspicious registry modifications in the path that Eventvwr.msc references upon execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry changes and process execution details. This activity is significant because it indicates a potential privilege escalation attempt, allowing an attacker to execute arbitrary commands with elevated privileges. If confirmed malicious, this could lead to unauthorized code execution, persistence, and further compromise of the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = Some false positives may be present and will need to be filtered. @@ -6380,7 +6324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies Microsoft Excel spawning PowerShell. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written. +explanation = The following analytic detects Microsoft Excel spawning PowerShell, an uncommon and suspicious behavior. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is "excel.exe" and the child process is PowerShell. This activity is significant because it is often associated with spearphishing attacks, where malicious attachments execute encoded PowerShell commands. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to data exfiltration, privilege escalation, or persistent access within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if any are present, filter as needed. @@ -6390,7 +6334,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies Microsoft Excel spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly. +explanation = The following analytic identifies instances where Microsoft Excel spawns Windows Script Host processes (`cscript.exe` or `wscript.exe`). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is `excel.exe`. This activity is significant because it is uncommon and often associated with malicious actions, such as spearphishing attacks. If confirmed malicious, this could allow an attacker to execute scripts, potentially leading to code execution, data exfiltration, or further system compromise. Immediate investigation and mitigation are recommended. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if any are present, filter as needed. In some instances, `cscript.exe` is used for legitimate business practices. @@ -6410,7 +6354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious series of process executions. We have observed that post exploit framework tools like Koadic and Meterpreter will launch an excessive number of processes with distinct file paths from Windows\Temp to execute actions on objective. This behavior is extremely anomalous compared to typical application behaviors that use Windows\Temp. +explanation = The following analytic identifies an excessive number of distinct processes executing from the Windows\Temp directory. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process paths and counts within a 20-minute window. This behavior is significant as it often indicates the presence of post-exploit frameworks like Koadic and Meterpreter, which use this technique to execute malicious actions. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, and maintain persistence within the environment, posing a severe threat to system integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = Many benign applications will create processes from executables in Windows\Temp, although unlikely to exceed the given threshold. Filter as needed. @@ -6420,7 +6364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies excessive file deletion events in the Windows Defender folder. This technique was observed in the WhisperGate malware campaign, where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges and then executed PowerShell commands to delete files within the Windows Defender application folder. Such behavior is a strong indicator that the offending process is attempting to corrupt a Windows Defender installation. +explanation = The following analytic detects excessive file deletion events in the Windows Defender folder. It leverages Sysmon EventCodes 23 and 26 to identify processes deleting multiple files within this directory. This behavior is significant as it may indicate an attempt to corrupt or disable Windows Defender, a key security component. If confirmed malicious, this activity could allow an attacker to disable endpoint protection, facilitating further malicious actions without detection. how_to_implement = To successfully implement this search, you must ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are utilizing Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = Windows Defender AV updates may trigger this alert. Please adjust the filter macros to mitigate false positives. @@ -6430,7 +6374,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This detection targets behaviors observed when threat actors have used sc.exe to modify services. We observed malware in a honey pot spawning numerous sc.exe processes in a short period of time, presumably to impair defenses, possibly to block others from compromising the same machine. This detection will alert when we see both an excessive number of sc.exe processes launched with specific commandline arguments to disable the start of certain services. +explanation = The following analytic detects an excessive number of `sc.exe` processes launched with the command line argument `start= disabled` within a short period. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and process GUIDs. This activity is significant as it may indicate an attempt to disable critical services, potentially impairing system defenses. If confirmed malicious, this behavior could allow an attacker to disrupt security mechanisms, hinder incident response, and maintain control over the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = Legitimate programs and administrators will execute sc.exe with the start disabled flag. It is possible, but unlikely from the telemetry of normal Windows operation we observed, that sc.exe will be called more than seven times in a short period of time. @@ -6440,7 +6384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection targets behaviors observed in post exploit kits like Meterpreter and Koadic that are run in memory. We have observed that these tools must invoke an excessive number of taskhost.exe and taskhostex.exe processes to complete various actions (discovery, lateral movement, etc.). It is extremely uncommon in the course of normal operations to see so many distinct taskhost and taskhostex processes running concurrently in a short time frame. +explanation = The following analytic identifies an excessive number of taskhost.exe and taskhostex.exe processes running within a short time frame. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and their counts. This behavior is significant as it is commonly associated with post-exploitation tools like Meterpreter and Koadic, which use multiple instances of these processes for actions such as discovery and lateral movement. If confirmed malicious, this activity could indicate an ongoing attack, allowing attackers to execute code, escalate privileges, or move laterally within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = Administrators, administrative actions or certain applications may run many instances of taskhost and taskhostex concurrently. Filter as needed. @@ -6450,7 +6394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious series of attempt to kill multiple services on a system using either `net.exe` or `sc.exe`. This technique is use by adversaries to terminate security services or other related services to continue there objective and evade detections. +explanation = The following analytic detects multiple attempts to stop or delete services on a system using `net.exe`, `sc.exe`, or `net1.exe`. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line executions within a one-minute window. This activity is significant as it may indicate an adversary attempting to disable security or critical services to evade detection and further their objectives. If confirmed malicious, this could lead to the attacker gaining persistence, escalating privileges, or disrupting essential services, thereby compromising the system's security posture. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -6460,7 +6404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe` or `icacls.exe` application to change file or folder permission. This behavior is commonly seen where the adversary attempts to impair some users from deleting or accessing its malware components or artifact from the compromised system. +explanation = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe`, or `icacls.exe` to change file or folder permissions. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an adversary attempting to restrict access to malware components or artifacts on a compromised system. If confirmed malicious, this behavior could prevent users from deleting or accessing critical files, aiding in the persistence and concealment of malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"]} known_false_positives = Administrators or administrative scripts may use this application. Filter as needed. @@ -6470,7 +6414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies excessive usage of `net.exe` or `net1.exe` within a bucket of time (1 minute). This behavior was seen in a Monero incident where the adversary attempts to create many users, delete and disable users as part of its malicious behavior. +explanation = The following analytic detects excessive usage of `net.exe` or `net1.exe` within a one-minute interval. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This behavior is significant as it may indicate an adversary attempting to create, delete, or disable multiple user accounts rapidly, a tactic observed in Monero mining incidents. If confirmed malicious, this activity could lead to unauthorized user account manipulation, potentially compromising system integrity and enabling further malicious actions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.AE"]} known_false_positives = unknown. Filter as needed. Modify the time span as needed. @@ -6480,7 +6424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type (TXT, A, AAAA) that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +explanation = The following analytic detects excessive usage of the nslookup application, which may indicate potential DNS exfiltration attempts. It leverages Sysmon EventCode 1 to monitor process executions, specifically focusing on nslookup.exe. The detection identifies outliers by comparing the frequency of nslookup executions against a calculated threshold. This activity is significant as it can reveal attempts by malware or APT groups to exfiltrate data via DNS queries. If confirmed malicious, this behavior could allow attackers to stealthily transfer sensitive information out of the network, bypassing traditional data exfiltration defenses. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of nslookup.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -6490,7 +6434,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious excessive usage of sc.exe in a host machine. This technique was seen in several ransomware , xmrig and other malware to create, modify, delete or disable a service may related to security application or to gain privilege escalation. +explanation = The following analytic detects excessive usage of the `sc.exe` service utility on a host machine. It leverages Sysmon EventCode 1 logs to identify instances where `sc.exe` is executed more frequently than normal within a 15-minute window. This behavior is significant as it is commonly associated with ransomware, cryptocurrency miners, and other malware attempting to create, modify, delete, or disable services, potentially related to security applications or for privilege escalation. If confirmed malicious, this activity could allow attackers to manipulate critical services, leading to system compromise or disruption of security defenses. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed taskkill.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]} known_false_positives = excessive execution of sc.exe is quite suspicious since it can modify or execute app in high privilege permission. @@ -6510,13 +6454,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious behavior related to ProxyShell against on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 which utilizes the Web Datamodel. \ -Modification of this analytic is requried to ensure fields are mapped accordingly. \ - \ -A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. This is indicative of accessing PowerShell on the back end of Exchange with SSRF. \ - \ -An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` (abbreviated) \ -Review the source attempting to perform this activity against your environment. In addition, review PowerShell logs and access recently granted to Exchange roles. +explanation = The following analytic detects suspicious behavior indicative of ProxyShell exploitation against on-premise Microsoft Exchange servers. It identifies HTTP POST requests to `autodiscover.json` containing `PowerShell` in the URI, leveraging server-side request forgery (SSRF) to access backend PowerShell. This detection uses Exchange server logs ingested into Splunk. Monitoring this activity is crucial as it may indicate an attacker attempting to execute commands or scripts on the Exchange server. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or persistent control over the Exchange environment. how_to_implement = The following analytic requires on-premise Exchange to be logging to Splunk using the TA - https://splunkbase.splunk.com/app/3225. Ensure logs are parsed correctly, or tune the analytic for your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Limited false positives, however, tune as needed. @@ -6526,11 +6464,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the usage of Exchange PowerShell modules that were recently used for a proof of concept related to ProxyShell. Adversaries may abuse a limited set of PwSh Modules related to Exchange once gained access via ProxyShell or ProxyNotShell. \ -Inherently, the usage of the modules is not malicious, but reviewing parallel processes, and user, of the session will assist with determining the intent. \ -Module - New-MailboxExportRequest will begin the process of exporting contents of a primary mailbox or archive to a .pst file. \ -Module - New-managementroleassignment can assign a management role to a management role group, management role assignment policy, user, or universal security group (USG). \ -Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate of search results, place search results on In-Place Hold or copy them to a Discovery mailbox. You can also place all contents in a mailbox on hold by not specifying a search query, which accomplishes similar results as Litigation Hold. \ Module - Get-Recipient cmdlet to view existing recipient objects in your organization. This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, mail contacts, and distribution groups). +explanation = The following analytic detects the usage of specific Exchange PowerShell modules, such as New-MailboxExportRequest, New-ManagementRoleAssignment, New-MailboxSearch, and Get-Recipient. It leverages PowerShell Script Block Logging (EventCode 4104) to identify these commands. This activity is significant because these modules can be exploited by adversaries who have gained access via ProxyShell or ProxyNotShell vulnerabilities. If confirmed malicious, attackers could export mailbox contents, assign management roles, conduct mailbox searches, or view recipient objects, potentially leading to data exfiltration, privilege escalation, or unauthorized access to sensitive information. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6540,7 +6474,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The Trickbot malware family also implements this behavior to try to infect other machines in the infected network. +explanation = The following analytic detects executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). It leverages Windows Security Event Logs with EventCode 5145 to identify this activity. This behavior is significant as it is commonly used by tools like PsExec/PaExec for staging binaries before creating and starting services on remote endpoints, a technique often employed for lateral movement and remote code execution. If confirmed malicious, this activity could allow an attacker to execute arbitrary code remotely, potentially compromising additional systems within the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]} known_false_positives = System Administrators may use looks like PsExec for troubleshooting or administrations tasks. However, this will typically come only from certain users and certain systems that can be added to an allow list. @@ -6550,7 +6484,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies potentially malicious executables or scripts by examining a list of suspicious file paths on Windows Operating System. The purpose of this technique is to uncover files with known file extensions that could be used by adversaries to evade detection and persistence. The suspicious file paths selected for investigation are typically uncommon and uncommonly associated with executable or script files. By scrutinizing these paths, we can proactively identify potential security threats and enhance overall system security. +explanation = The following analytic identifies the creation of executables or scripts in suspicious file paths on Windows systems. It leverages the Endpoint.Filesystem data model to detect files with specific extensions (e.g., .exe, .dll, .ps1) created in uncommon directories (e.g., \windows\fonts\, \users\public\). This activity is significant as adversaries often use these paths to evade detection and maintain persistence. If confirmed malicious, this behavior could allow attackers to execute unauthorized code, escalate privileges, or persist within the environment, posing a significant security threat. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"]} known_false_positives = Administrators may allow creation of script or exe in the paths specified. Filter as needed. @@ -6560,7 +6494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious process of cscript.exe where it tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique was seen in ransomware (reddot ransomware) where it execute javascript with this com object with combination of amsi disabling technique. +explanation = The following analytic detects the execution of JavaScript using the JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as it is a known technique used by ransomware, such as Reddot, to execute malicious scripts and potentially disable AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.005"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -6570,7 +6504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for processes launched from files that have double extensions in the file name. This is typically done to obscure the "real" file extension and make it appear as though the file being accessed is a data file, as opposed to executable content. +explanation = The following analytic detects the execution of files with multiple extensions, such as ".doc.exe" or ".pdf.exe". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the file name contains double extensions. This activity is significant because attackers often use double extensions to disguise malicious executables as benign documents, increasing the likelihood of user execution. If confirmed malicious, this technique can lead to unauthorized code execution, potentially compromising the endpoint and allowing further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.CM"]} known_false_positives = None identified. @@ -6580,7 +6514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of `reg.exe` exporting Windows Registry hives containing credentials. Adversaries may use this technique to export registry hives for offline credential access attacks. Typically found executed from a untrusted process or script. Upon execution, a file will be written to disk. +explanation = The following analytic detects the use of `reg.exe` to export Windows Registry hives, which may contain sensitive credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `save` or `export` actions targeting the `sam`, `system`, or `security` hives. This activity is significant as it indicates potential offline credential access attacks, often executed from untrusted processes or scripts. If confirmed malicious, attackers could gain access to credential data, enabling further compromise and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} known_false_positives = It is possible some agent based products will generate false positives. Filter as needed. @@ -6590,7 +6524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents. +explanation = The following analytic detects file writes with extensions indicative of a SamSam ransomware attack. It leverages file-system activity data to identify file names ending in .stubbin, .berkshire, .satoshi, .sophos, or .keyxml. This activity is significant because SamSam ransomware is highly destructive, leading to file encryption and ransom demands. If confirmed malicious, the impact includes significant financial losses, operational disruptions, and reputational damage. Immediate actions should include isolating affected systems, restoring files from backups, and investigating the attack source to prevent further incidents. how_to_implement = You must be ingesting data that records file-system activity from your hosts to populate the Endpoint file-system data-model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data. annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]} known_false_positives = Because these extensions are not typically used in normal operations, you should investigate all results. @@ -6600,7 +6534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application. +explanation = The following analytic detects the modification of a firewall rule to allow the execution of a specific application. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events with command-line arguments related to firewall rule changes. This activity is significant as it may indicate an attempt to bypass firewall restrictions, potentially allowing unauthorized applications to communicate over the network. If confirmed malicious, this could enable an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the target environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]} known_false_positives = A network operator or systems administrator may utilize an automated or manual execution of this firewall rule that may generate false positives. Filter as needed. @@ -6630,11 +6564,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Fodhelper.exe has a known UAC bypass as it attempts to look for specific registry keys upon execution, that do not exist. Therefore, an attacker can write its malicious commands in these registry keys to be executed by fodhelper.exe with the highest privilege. \ -* `HKCU:\Software\Classes\ms-settings\shell\open\command` \ -* `HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute` \ -* `HKCU:\Software\Classes\ms-settings\shell\open\command\(default)` \ -Upon triage, fodhelper.exe will have a child process and read access will occur on the registry keys. Isolate the endpoint and review parallel processes for additional behavior. +explanation = The following analytic detects the execution of fodhelper.exe, which is known to exploit a User Account Control (UAC) bypass by leveraging specific registry keys. The detection method uses Endpoint Detection and Response (EDR) telemetry to identify when fodhelper.exe spawns a child process and accesses the registry keys. This activity is significant because it indicates a potential privilege escalation attempt by an attacker. If confirmed malicious, the attacker could execute commands with elevated privileges, leading to unauthorized system changes and potential full system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = Limited to no false positives are expected. @@ -6644,7 +6574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious fsutil process to zeroing a target file. This technique was seen in lockbit ransomware where it tries to zero out its malware path as part of its defense evasion after encrypting the compromised host. +explanation = The following analytic detects the execution of the 'fsutil' command with the 'setzerodata' parameter, which zeros out a target file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it is a technique used by ransomware, such as LockBit, to evade detection by erasing its malware path after encrypting the host. If confirmed malicious, this action could hinder forensic investigations and allow attackers to cover their tracks, complicating incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -6654,7 +6584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` executing the Get-ADDefaultDomainPasswordPolicy commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` running the `Get-ADDefaultDomainPasswordPolicy` cmdlet, which is used to retrieve the password policy in a Windows domain. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. Monitoring this activity is crucial as it can indicate attempts by adversaries to gather information about domain policies for situational awareness and Active Directory discovery. If confirmed malicious, this activity could lead to further reconnaissance and potential exploitation of domain security settings. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6664,7 +6594,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADDefaultDomainPasswordPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-ADDefaultDomainPasswordPolicy` PowerShell cmdlet, which is used to retrieve the password policy in a Windows domain. This detection leverages PowerShell Script Block Logging (EventCode=4104) to identify the specific command execution. Monitoring this activity is significant as it can indicate an attempt to gather domain policy information, which is often a precursor to further malicious actions. If confirmed malicious, this activity could allow an attacker to understand password policies, aiding in password attacks or further domain enumeration. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6674,7 +6604,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to enumerate domain users. The `Get-AdUser' commandlet returns a list of all domain users. Red Teams and adversaries alike may use this commandlet to identify remote systems for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments used to enumerate domain users via the `Get-ADUser` cmdlet. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to gather information about domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, enabling attackers to identify high-value targets and plan subsequent attacks. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6684,7 +6614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGUser` commandlet. The `Get-AdUser` commandlet is used to return a list of all domain users. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-AdUser` PowerShell cmdlet, which is used to enumerate all domain users. It leverages PowerShell Script Block Logging (EventCode=4104) to identify instances where this command is executed with a filter. This activity is significant as it may indicate an attempt by adversaries or Red Teams to gather information about domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance and potential exploitation of user accounts within the domain. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6694,7 +6624,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` executing the Get ADUserResultantPasswordPolicy commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` running the `Get-ADUserResultantPasswordPolicy` cmdlet, which is used to obtain the password policy in a Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential enumeration of domain policies, a common tactic for situational awareness and Active Directory discovery by adversaries. If confirmed malicious, this could allow attackers to understand password policies, aiding in further attacks such as password spraying or brute force attempts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6704,7 +6634,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUserResultantPasswordPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-ADUserResultantPasswordPolicy` PowerShell cmdlet, which is used to obtain the password policy in a Windows domain. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. Monitoring this behavior is significant as it may indicate an attempt to enumerate domain policies, a common tactic used by adversaries for situational awareness and Active Directory discovery. If confirmed malicious, this activity could allow attackers to understand password policies, aiding in further attacks such as password guessing or policy exploitation. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6714,7 +6644,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` executing the `Get-DomainPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` running the `Get-DomainPolicy` cmdlet, which is used to retrieve password policies in a Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to gather domain policy information, which is crucial for planning further attacks. If confirmed malicious, this could lead to unauthorized access to sensitive domain configurations, aiding in privilege escalation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6724,7 +6654,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get DomainPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-DomainPolicy` cmdlet using PowerShell Script Block Logging (EventCode=4104). It leverages logs capturing script block text to identify attempts to obtain the password policy in a Windows domain. This activity is significant as it indicates potential reconnaissance efforts by adversaries or Red Teams to gather domain policy information, which is crucial for planning further attacks. If confirmed malicious, this behavior could lead to detailed knowledge of domain security settings, aiding in privilege escalation or lateral movement within the network. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6734,7 +6664,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies Get-DomainTrust from PowerView in order to gather domain trust information. Typically, this is utilized within a script being executed and used to enumerate the domain trust information. This grants the adversary an understanding of how large or small the domain is. During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. +explanation = The following analytic identifies the execution of the Get-DomainTrust command from PowerView using PowerShell, which is used to gather domain trust information. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant as it indicates potential reconnaissance efforts by an adversary to understand domain trust relationships, which can inform lateral movement strategies. If confirmed malicious, this could allow attackers to map out the network, identify potential targets, and plan further attacks, potentially compromising additional systems within the domain. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} known_false_positives = Limited false positives as this requires an active Administrator or adversary to bring in, import, and execute. @@ -6744,10 +6674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies Get-DomainTrust from PowerView in order to gather domain trust information. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of the Get-DomainTrust command from PowerView using PowerShell Script Block Logging (EventCode=4104). This method captures the full command sent to PowerShell, allowing for detailed inspection. Identifying this activity is significant because it may indicate an attempt to gather domain trust information, which is often a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could enable an attacker to map trust relationships within the domain, potentially leading to further exploitation and compromise of additional systems. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} known_false_positives = It is possible certain system management frameworks utilize this command to gather trust information. @@ -6757,7 +6684,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to enumerate domain users. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments used to enumerate domain users via the `Get-DomainUser` command. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it indicates potential reconnaissance efforts by adversaries or Red Teams using PowerView for Active Directory discovery. If confirmed malicious, this could allow attackers to gain situational awareness and identify valuable targets within the domain, potentially leading to further exploitation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6767,7 +6694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet. `GetDomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-DomainUser` cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is part of PowerView, a tool often used for domain enumeration. The detection leverages PowerShell operational logs to identify instances where this command is executed. Monitoring this activity is crucial as it may indicate an adversary's attempt to gather information about domain users, which is a common step in Active Directory Discovery. If confirmed malicious, this activity could lead to further reconnaissance and potential exploitation of domain resources. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6777,7 +6704,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies Get-ForestTrust from PowerSploit in order to gather domain trust information. Typically, this is utilized within a script being executed and used to enumerate the domain trust information. This grants the adversary an understanding of how large or small the domain is. During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. +explanation = The following analytic detects the execution of the Get-ForestTrust command via PowerShell, commonly used by adversaries to gather domain trust information. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. Identifying this activity is crucial as it indicates potential reconnaissance efforts to map out domain trusts, which can inform further attacks. If confirmed malicious, this activity could allow attackers to understand domain relationships, aiding in lateral movement and privilege escalation within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} known_false_positives = Limited false positives as this requires an active Administrator or adversary to bring in, import, and execute. @@ -6787,10 +6714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies Get-ForestTrust from PowerSploit in order to gather domain trust information. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of the Get-ForestTrust command from PowerSploit using PowerShell Script Block Logging (EventCode=4104). This method captures the full command sent to PowerShell, providing detailed visibility into potentially suspicious activities. Monitoring this behavior is crucial as it can indicate an attempt to gather domain trust information, which is often a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to map trust relationships within the domain, facilitating further exploitation and access to sensitive resources. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1482", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives may be present. Tune as needed. @@ -6800,7 +6724,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies the use of `Get-WMIObject Win32_Group` being used with PowerShell to identify local groups on the endpoint. \ Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \ During triage, review parallel processes and identify any further suspicious behavior. +explanation = The following analytic detects the use of the `Get-WMIObject Win32_Group` command executed via PowerShell to enumerate local groups on an endpoint. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. Identifying local groups can be a precursor to privilege escalation or lateral movement. If confirmed malicious, this activity could allow an attacker to map out group memberships, aiding in further exploitation or unauthorized access to sensitive resources. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]} known_false_positives = False positives may be present. Tune as needed. @@ -6810,10 +6734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the usage of `Get-WMIObject Win32_Group`, which is typically used as a way to identify groups on the endpoint. Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of the `Get-WMIObject Win32_Group` command using PowerShell Script Block Logging (EventCode=4104). This method captures the full command sent to PowerShell, allowing for detailed analysis. Identifying group information on an endpoint is not inherently malicious but can be suspicious based on context such as time, endpoint, and user. This activity is significant as it may indicate reconnaissance efforts by an attacker. If confirmed malicious, it could lead to further enumeration and potential lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]} known_false_positives = False positives may be present. Tune as needed. @@ -6823,7 +6744,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. The `Get-AdComputer' commandlet returns a list of all domain computers. Red Teams and adversaries alike may use this commandlet to identify remote systems for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with the `Get-AdComputer` commandlet, which is used to discover remote systems within a domain. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it indicates potential reconnaissance efforts by adversaries to map out domain computers, which is a common step in the attack lifecycle. If confirmed malicious, this behavior could allow attackers to gain situational awareness and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6833,7 +6754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet is used to return a list of all domain computers. Red Teams and adversaries may leverage this commandlet to enumerate domain computers for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-AdComputer` PowerShell commandlet using PowerShell Script Block Logging (EventCode=4104). This detection leverages script block text to identify when this commandlet is run. The `Get-AdComputer` commandlet is significant as it can be used by adversaries to enumerate all domain computers, aiding in situational awareness and Active Directory discovery. If confirmed malicious, this activity could allow attackers to map the network, identify targets, and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6843,7 +6764,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. The `Get-AdGroup` commandlnet is used to return a list of all groups available in a Windows Domain. Red Teams and adversaries alike may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with the `Get-AdGroup` commandlet, which is used to query domain groups in a Windows Domain. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it may indicate an adversary or Red Team enumerating domain groups for situational awareness and Active Directory discovery. If confirmed malicious, this activity could lead to further reconnaissance, privilege escalation, or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6853,7 +6774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet is used to return a list of all domain groups. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-AdGroup` PowerShell cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is used to enumerate all domain groups, which adversaries may exploit for situational awareness and Active Directory discovery. Monitoring this activity is crucial as it can indicate reconnaissance efforts within the network. If confirmed malicious, this behavior could lead to further exploitation, such as privilege escalation or lateral movement, by providing attackers with detailed information about the domain's group structure. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6863,7 +6784,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powerhsell.exe` with command-line arguments that execute the `GetCurrent` method of the WindowsIdentity .NET class. This method returns an object that represents the current Windows user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments invoking the `GetCurrent` method of the WindowsIdentity .NET class. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as adversaries may use this method to identify the logged-in user on a compromised endpoint, aiding in situational awareness and Active Directory discovery. If confirmed malicious, this could allow attackers to gain insights into user context, potentially facilitating further exploitation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6873,7 +6794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `GetCurrent` method of the WindowsIdentity .NET class. This method returns an object that represents the current Windows user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `GetCurrent` method from the WindowsIdentity .NET class using PowerShell Script Block Logging (EventCode=4104). This method identifies the current Windows user. The detection leverages PowerShell script block logs to identify when this method is called. This activity is significant because adversaries and Red Teams may use it to gain situational awareness and perform Active Directory discovery on compromised endpoints. If confirmed malicious, this could allow attackers to map out user accounts and potentially escalate privileges or move laterally within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6883,7 +6804,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. `Get-DomainComputer` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments that utilize `Get-DomainComputer` to discover remote systems. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as `Get-DomainComputer` is part of PowerView, a tool often used by adversaries for domain enumeration and situational awareness. If confirmed malicious, this activity could allow attackers to map out the network, identify critical systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use PowerView for troubleshooting. @@ -6893,7 +6814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainComputer` commandlet. `GetDomainComputer` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain computers for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-DomainComputer` commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet is part of PowerView, a tool often used for enumerating domain computers within Windows environments. The detection leverages script block text analysis to identify this specific command. Monitoring this activity is crucial as it can indicate an adversary's attempt to gather information about domain computers, which is a common step in Active Directory reconnaissance. If confirmed malicious, this activity could lead to further network enumeration and potential lateral movement within the domain. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use PowerView for troubleshooting. @@ -6903,7 +6824,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. `Get-DomainController` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with the `Get-DomainController` command, which is used to discover remote systems within a Windows domain. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it may indicate an attempt to enumerate domain controllers, a common tactic in Active Directory discovery. If confirmed malicious, this activity could allow attackers to gain situational awareness, potentially leading to further exploitation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use PowerView for troubleshooting. @@ -6913,7 +6834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainController` commandlet. `Get-DomainController` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain computers for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-DomainController` commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet is part of PowerView, a tool often used for domain enumeration. The detection leverages script block text to identify this specific activity. Monitoring this behavior is crucial as it may indicate an adversary or Red Team performing reconnaissance to map out domain controllers. If confirmed malicious, this activity could lead to further domain enumeration, potentially exposing sensitive information and aiding in lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6923,7 +6844,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. `Get-DomainGroup` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments that query for domain groups using `Get-DomainGroup`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. Monitoring this activity is crucial as `Get-DomainGroup` is part of PowerView, a tool often used by adversaries for domain enumeration and situational awareness. If confirmed malicious, this activity could allow attackers to gain insights into domain group structures, aiding in further exploitation and privilege escalation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6933,7 +6854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroup` commandlet. `Get-DomainGroup` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroup` is used to query domain groups. Red Teams and adversaries may leverage this function to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-DomainGroup` cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet, part of the PowerView tool, is used to enumerate domain groups within a Windows domain. The detection leverages script block text to identify this specific command. Monitoring this activity is crucial as it may indicate an adversary or Red Team performing reconnaissance to gain situational awareness and map out Active Directory structures. If confirmed malicious, this activity could lead to further exploitation, including privilege escalation and lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this PowerView functions for troubleshooting. @@ -6943,7 +6864,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for local users. The `Get-LocalUser` commandlet is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with the `Get-LocalUser` commandlet, which is used to query local user accounts. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is significant because adversaries and Red Teams may use it to enumerate local users for situational awareness and Active Directory discovery. If confirmed malicious, this activity could allow attackers to identify potential targets for further exploitation or privilege escalation within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6953,7 +6874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-LocalUser` commandlet. The `Get-LocalUser` commandlet is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-LocalUser` PowerShell commandlet using PowerShell Script Block Logging (EventCode=4104). This commandlet lists all local users on a system. The detection leverages script block text from PowerShell logs to identify this activity. Monitoring this behavior is significant as adversaries and Red Teams may use it to enumerate local users for situational awareness and Active Directory discovery. If confirmed malicious, this activity could lead to further reconnaissance, enabling attackers to identify potential targets for privilege escalation or lateral movement. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.001", "T1059.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6963,7 +6884,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line utilized to get a listing of network connections on a compromised system. The `Get-NetTcpConnection` commandlet lists the current TCP connections. Red Teams and adversaries alike may use this commandlet for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `powershell.exe` with the `Get-NetTcpConnection` command, which lists current TCP connections on a system. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. Monitoring this activity is significant as it may indicate an adversary or Red Team performing network reconnaissance or situational awareness. If confirmed malicious, this activity could allow attackers to map network connections, aiding in lateral movement or further exploitation within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6973,7 +6894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-NetTcpconnection ` commandlet. This commandlet is used to return a listing of network connections on a compromised system. Red Teams and adversaries alike may use this commandlet for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-NetTcpconnection` PowerShell cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet lists network connections on a system, which adversaries may use for situational awareness and Active Directory discovery. Monitoring this activity is crucial as it can indicate reconnaissance efforts by an attacker. If confirmed malicious, this behavior could allow an attacker to map the network, identify critical systems, and plan further attacks, potentially leading to data exfiltration or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -6983,7 +6904,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. The `Get-WmiObject` commandlet combined with the `DS_Computer` parameter can be used to return a list of all domain computers. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments that utilize the `Get-WmiObject` cmdlet to discover remote systems, specifically targeting the `DS_Computer` parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain computers and gather situational awareness within Active Directory. If confirmed malicious, this behavior could allow attackers to map the network, identify critical systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -6993,7 +6914,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet. The `DS_Computer` class parameter leverages WMI to query for all domain computers. Red Teams and adversaries may leverage this commandlet to enumerate domain computers for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-WmiObject` cmdlet with the `DS_Computer` class parameter via PowerShell Script Block Logging (EventCode=4104). This detection leverages script block text to identify queries targeting domain computers using WMI. Monitoring this activity is crucial as adversaries and Red Teams may use it for Active Directory Discovery and situational awareness. If confirmed malicious, this behavior could allow attackers to map out domain computers, facilitating further attacks such as lateral movement or privilege escalation. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -7003,7 +6924,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. The `Get-WmiObject` commandlet combined with the `-class ds_group` parameter can be used to return the full list of groups in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `powershell.exe` with command-line arguments used to query domain groups via the `Get-WmiObject` cmdlet and the `-class ds_group` parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain groups, which is a common step in Active Directory Discovery. If confirmed malicious, this could allow attackers to gain insights into the domain structure, aiding in further attacks and privilege escalation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -7013,7 +6934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet used with specific parameters . The `DS_Group` parameter leverages WMI to query for all domain groups. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-WmiObject` commandlet with the `DS_Group` parameter via PowerShell Script Block Logging (EventCode=4104). This method leverages WMI to query all domain groups. Monitoring this activity is crucial as adversaries and Red Teams may use it for domain group enumeration, aiding in situational awareness and Active Directory discovery. If confirmed malicious, this activity could allow attackers to map out the domain structure, potentially leading to further exploitation and privilege escalation within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -7023,7 +6944,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain users. The `Get-WmiObject` commandlet combined with the `-class ds_user` parameter can be used to return the full list of users in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments used to query domain users via the `Get-WmiObject` cmdlet and `-class ds_user` parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain users, which is a common step in Active Directory Discovery. If confirmed malicious, this could lead to further attacks, including privilege escalation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -7033,7 +6954,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet. The `DS_User` class parameter leverages WMI to query for all domain users. Red Teams and adversaries may leverage this commandlet to enumerate domain users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-WmiObject` cmdlet with the `DS_User` class parameter via PowerShell Script Block Logging (EventCode=4104). It leverages logs to identify attempts to query all domain users using WMI. This activity is significant as it may indicate an adversary or Red Team operation attempting to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, enabling attackers to map out the network and identify potential targets for privilege escalation or lateral movement. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -7043,7 +6964,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query local users. The `Get-WmiObject` commandlet combined with the `Win32_UserAccount` parameter is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments that utilize the `Get-WmiObject` cmdlet and the `Win32_UserAccount` parameter to query local user accounts. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to enumerate user accounts for situational awareness or Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, privilege escalation, or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -7053,7 +6974,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet used with specific parameters. The `Win32_UserAccount` parameter is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of the `Get-WmiObject` commandlet with the `Win32_UserAccount` parameter via PowerShell Script Block Logging (EventCode=4104). This method leverages script block text to identify when a list of all local users is being enumerated. This activity is significant as it may indicate an adversary or Red Team operation attempting to gather user information for situational awareness and Active Directory discovery. If confirmed malicious, this could lead to further reconnaissance, privilege escalation, or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.001", "T1059.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -7063,7 +6984,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies gpupdate.exe with no command line arguments and with a network connection. It is unusual for gpupdate.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. gpupdate.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of gpupdate.exe without command line arguments and with an active network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network traffic data. It is significant because gpupdate.exe typically runs with specific arguments, and its execution without them, especially with network activity, is often associated with malicious software like Cobalt Strike. If confirmed malicious, this activity could indicate an attacker leveraging gpupdate.exe for lateral movement, command and control, or other nefarious purposes, potentially leading to system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process. @@ -7073,7 +6994,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies headless browser activity accessing mockbin.org or mocky.io. Mockbin.org and mocky.io are web services that allow users to mock HTTP requests and responses. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing and the presence of mockbin.org or mocky.io in the process. +explanation = The following analytic detects headless browser activity accessing mockbin.org or mocky.io. It identifies processes with the "--headless" and "--disable-gpu" command line arguments, along with references to mockbin.org or mocky.io. This behavior is significant as headless browsers are often used for automated tasks, including malicious activities like web scraping or automated attacks. If confirmed malicious, this activity could indicate an attempt to bypass traditional browser security measures, potentially leading to data exfiltration or further exploitation of web applications. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected with this detection, unless within the organization there is a legitimate need for headless browsing accessing mockbin.org or mocky.io. @@ -7083,7 +7004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic is designed to detect the usage of headless browsers in an organization. Headless browsers are web browsers without a graphical user interface and are operated via a command line interface or network requests. They are often used for automating tasks but can also be utilized by adversaries for malicious activities such as web scraping, automated testing, and performing actions on web pages without detection. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing. +explanation = The following analytic detects the usage of headless browsers within an organization. It identifies processes containing the "--headless" and "--disable-gpu" command line arguments, which are indicative of headless browsing. This detection leverages data from the Endpoint.Processes datamodel to identify such processes. Monitoring headless browser usage is significant as these tools can be exploited by adversaries for malicious activities like web scraping, automated testing, and undetected web interactions. If confirmed malicious, this activity could lead to unauthorized data extraction, automated attacks, or other covert operations on web applications. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003"], "nist": ["DE.AE"]} known_false_positives = This hunting analytic is meant to assist with baselining and understanding headless browsing in use. Filter as needed. @@ -7093,7 +7014,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious registry modification to hide a user account on the Windows Login screen. This technique was seen in some tradecraft where the adversary will create a hidden user account with Admin privileges in login screen to avoid noticing by the user that they already compromise and to persist on that said machine. +explanation = The following analytic detects a suspicious registry modification that hides a user account from the Windows Login screen. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" with a value of "0x00000000". This activity is significant as it may indicate an adversary attempting to create a hidden admin account to avoid detection and maintain persistence on the compromised machine. If confirmed malicious, this could allow the attacker to maintain undetected access and control over the system, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = Unknown. Filter as needed. @@ -7103,7 +7024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Attackers leverage an existing Windows binary, attrib.exe, to mark specific as hidden by using specific flags so that the victim does not see the file. The search looks for specific command-line arguments to detect the use of attrib.exe to hide files. +explanation = The following analytic detects the use of the Windows binary attrib.exe to hide files or directories by marking them with specific flags. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments that include the "+h" flag. This activity is significant because hiding files can be a tactic used by attackers to conceal malicious files or tools from users and security software. If confirmed malicious, this behavior could allow an attacker to persist in the environment undetected, potentially leading to further compromise or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222", "T1222.001"], "nist": ["DE.CM"]} known_false_positives = Some applications and users may legitimately use attrib.exe to interact with the files. @@ -7113,7 +7034,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious high frequency copying/moving of files in network share as part of information sabotage. This anomaly event can be a good indicator of insider trying to sabotage data by transfering classified or internal files within network share to exfitrate it after or to lure evidence of insider attack to other user. This behavior may catch several noise if network share is a common place for classified or internal document processing. +explanation = The following analytic detects a high frequency of file copying or moving within network shares, which may indicate potential data sabotage or exfiltration attempts. It leverages Windows Security Event Logs (EventCode 5145) to monitor access to specific file types and network shares. This activity is significant as it can reveal insider threats attempting to transfer classified or internal files, potentially leading to data breaches or evidence tampering. If confirmed malicious, this behavior could result in unauthorized data access, data loss, or compromised sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"]} known_false_positives = This behavior may seen in normal transfer of file within network if network share is common place for sharing documents. @@ -7123,7 +7044,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify a high frequency of process termination events on a computer in a short period of time, which is a common behavior of ransomware malware before encrypting files. This technique is designed to avoid an exception error while accessing (docs, images, database and etc..) in the infected machine for encryption. +explanation = The following analytic identifies a high frequency of process termination events on a computer within a short period. It leverages Sysmon EventCode 5 logs to detect instances where 15 or more processes are terminated within a 3-second window. This behavior is significant as it is commonly associated with ransomware attempting to avoid exceptions during file encryption. If confirmed malicious, this activity could indicate an active ransomware attack, potentially leading to widespread file encryption and significant data loss. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Image (process full path of terminated process) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]} known_false_positives = admin or user tool that can terminate multiple process. @@ -7133,7 +7054,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The hunting analytic outlined below is designed to detect any version of the 3CXDesktopApp, also known as the 3CX Desktop App, operating on either Mac or Windows systems. It is important to note that this particular analytic employs the Endpoint datamodel Processes node, which means that the file version information is not provided. Recently, 3CX has identified a vulnerability specifically in versions 18.12.407 and 18.12.416 of the desktop app. +explanation = The following analytic detects the presence of any version of the 3CXDesktopApp, also known as the 3CX Desktop App, on Mac or Windows systems. It leverages the Endpoint data model's Processes node to identify instances of the application running, although it does not provide file version information. This activity is significant because 3CX has identified vulnerabilities in versions 18.12.407 and 18.12.416, which could be exploited by attackers. If confirmed malicious, this could lead to unauthorized access, data exfiltration, or further compromise of the affected systems. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002"], "nist": ["DE.AE"]} known_false_positives = There may be false positives generated due to the reliance on version numbers for identification purposes. Despite this limitation, the primary goal of this approach is to aid in the detection of the software within the environment. @@ -7143,7 +7064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies instances where an adversary modifies the security permissions of a particular file or directory. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. The purpose of this behavior is to actively evade detection and impede access to their associated files. By identifying these security permission changes, we can enhance our ability to detect and respond to potential threats, mitigating the impact of malicious activities on the system. +explanation = The following analytic detects instances where an adversary modifies security permissions of a file or directory using commands like "icacls.exe", "cacls.exe", or "xcacls.exe" with deny options. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it is commonly used by Advanced Persistent Threats (APTs) and coinminer scripts to evade detection and impede access to critical files. If confirmed malicious, this could allow attackers to maintain persistence and hinder incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.CM"]} known_false_positives = Unknown. It is possible some administrative scripts use ICacls. Filter as needed. @@ -7153,7 +7074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies adversaries who manipulate the security permissions of specific files or directories by granting additional access. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. The objective behind this behavior is to actively evade detection mechanisms and tightly control access to their associated files. By identifying these security permission modifications, we can improve our ability to identify and respond to potential threats, thereby minimizing the impact of malicious activities on the system. +explanation = The following analytic detects the use of the ICACLS command to grant additional access permissions to files or directories. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific process names and command-line arguments. This activity is significant because it is commonly used by Advanced Persistent Threats (APTs) and coinminer scripts to evade detection and maintain control over compromised systems. If confirmed malicious, this behavior could allow attackers to manipulate file permissions, potentially leading to unauthorized access, data exfiltration, or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.CM"]} known_false_positives = Unknown. Filter as needed. @@ -7173,7 +7094,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the presence of suspicious commandline parameters typically present when using Impacket tools. Impacket is a collection of python classes meant to be used with Microsoft network protocols. There are multiple scripts that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` and `atexec.py` used to execute commands on remote endpoints. By default, these scripts leverage administrative shares and hardcoded parameters that can be used as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets tools for lateral movement and remote code execution. +explanation = The following analytic identifies the use of suspicious command-line parameters associated with Impacket tools, such as `wmiexec.py`, `smbexec.py`, `dcomexec.py`, and `atexec.py`, which are used for lateral movement and remote code execution. It detects these activities by analyzing process execution logs from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns. This activity is significant because Impacket tools are commonly used by adversaries and Red Teams to move laterally within a network. If confirmed malicious, this could allow attackers to execute commands remotely, potentially leading to further compromise and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases. @@ -7183,7 +7104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic focuses on identifying suspicious command-line parameters commonly associated with the use of Impacket wmiexec.py. Impacket is a set of Python classes designed for working with Microsoft network protocols, and it includes several scripts like wmiexec.py, smbexec.py, dcomexec.py, and atexec.py that enable command execution on remote endpoints. These scripts typically utilize administrative shares and hardcoded parameters, which can serve as signatures to detect their usage. Both Red Teams and adversaries may employ Impacket tools for lateral movement and remote code execution purposes. By monitoring for these specific command-line indicators, the analytic aims to detect potentially malicious activities related to Impacket tool usage. +explanation = The following analytic identifies suspicious command-line parameters associated with the use of Impacket's smbexec.py for lateral movement. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns indicative of Impacket tool usage. This activity is significant as both Red Teams and adversaries use Impacket for remote code execution and lateral movement. If confirmed malicious, this activity could allow attackers to execute commands on remote endpoints, potentially leading to unauthorized access, data exfiltration, or further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases. @@ -7193,7 +7114,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the presence of suspicious commandline parameters typically present when using Impacket tools. Impacket is a collection of python classes meant to be used with Microsoft network protocols. There are multiple scripts that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` and `atexec.py` used to execute commands on remote endpoints. By default, these scripts leverage administrative shares and hardcoded parameters that can be used as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets tools for lateral movement and remote code execution. +explanation = The following analytic detects the use of Impacket's `wmiexec.py` tool for lateral movement by identifying specific command-line parameters. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes spawned by `wmiprvse.exe` with command-line patterns indicative of Impacket usage. This activity is significant as Impacket tools are commonly used by adversaries for remote code execution and lateral movement within a network. If confirmed malicious, this could allow attackers to execute arbitrary commands on remote systems, potentially leading to further compromise and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases. @@ -7203,7 +7124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the usage of the `Enter-PSSession`. This commandlet can be used to open an interactive session on a remote endpoint leveraging the WinRM protocol. Red Teams and adversaries alike may abuse WinRM and `Enter-PSSession` for lateral movement and remote code execution. +explanation = The following analytic detects the use of the `Enter-PSSession` cmdlet to establish an interactive session on a remote endpoint via the WinRM protocol. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity by searching for specific script block text patterns. This behavior is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this activity could allow attackers to execute commands remotely, potentially leading to further compromise of the network and unauthorized access to sensitive information. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WinRM and `Enter-PSSession` for administrative and troubleshooting tasks. This activity is usually limited to a small set of hosts or users. In certain environments, tuning may not be possible. @@ -7213,7 +7134,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies a Java user agent performing a GET request for a .class file from the remote site. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell). +explanation = The following analytic identifies a Java user agent performing a GET request for a .class file from a remote site. It leverages web or proxy logs within the Web Datamodel to detect this activity. This behavior is significant as it may indicate exploitation attempts, such as those related to CVE-2021-44228 (Log4Shell). If confirmed malicious, an attacker could exploit vulnerabilities in the Java application, potentially leading to remote code execution and further compromise of the affected system. how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = Filtering may be required in some instances, filter as needed. @@ -7223,7 +7144,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the process java writing a .jsp to disk. This is potentially indicative of a web shell being written to disk. Modify and tune the analytic based on data ingested. For instance, it may be worth running a broad query for jsp file writes first before performing a join. +explanation = The following analytic detects the Java process writing a .jsp file to disk, which may indicate a web shell being deployed. It leverages data from the Endpoint datamodel, specifically monitoring process and filesystem activities. This activity is significant because web shells can provide attackers with remote control over the compromised server, leading to further exploitation. If confirmed malicious, this could allow unauthorized access, data exfiltration, or further compromise of the affected system, posing a severe security risk. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives are possible and filtering may be required. Restrict by assets or filter known jsp files that are common for the environment. @@ -7233,7 +7154,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a execution of jscript using cscript process. Commonly when a user run jscript file it was executed by wscript.exe application. This technique was seen in FIN7 js implant to execute its malicious script using cscript process. This behavior is uncommon and a good artifacts to check further anomalies within the network +explanation = The following analytic detects the execution of JScript using the cscript.exe process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This behavior is significant because JScript files are typically executed by wscript.exe, making cscript.exe execution unusual and potentially indicative of malicious activity, such as the FIN7 group's tactics. If confirmed malicious, this activity could allow attackers to execute arbitrary scripts, leading to code execution, data exfiltration, or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -7243,7 +7164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential kerberoasting attack against Active Directory networks. Kerberoasting allows an adversary to request kerberos tickets for domain accounts typically used as service accounts and attempt to crack them offline allowing them to obtain privileged access to the domain. This analytic looks for a specific combination of the Ticket_Options field based on common kerberoasting tools. Defenders should be aware that it may be possible for a Kerberoast attack to use different Ticket_Options. +explanation = The following analytic detects potential Kerberoasting attacks by identifying Kerberos service ticket requests with RC4 encryption through Event ID 4769. It leverages specific Ticket_Options values commonly used by Kerberoasting tools. This activity is significant as Kerberoasting allows attackers to request service tickets for domain accounts, typically service accounts, and crack them offline to gain privileged access. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and further compromise of the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]} known_false_positives = Older systems that support kerberos RC4 by default like NetApp may generate false positives. Filter as needed @@ -7253,7 +7174,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Windows Security Event 4738, `A user account was changed`, to identify a change performed on a domain user object that disables Kerberos Pre-Authentication. Disabling the Pre Authentication flag in the UserAccountControl property allows an adversary to easily perform a brute force attack against the user's password offline leveraging the ASP REP Roasting technique. Red Teams and adversaries alike who have obtained privileges in an Active Directory network may use this technique as a backdoor or a way to escalate privileges. +explanation = The following analytic detects when the Kerberos Pre-Authentication flag is disabled in a user account, using Windows Security Event 4738. This event indicates a change in the UserAccountControl property of a domain user object. Disabling this flag allows adversaries to perform offline brute force attacks on the user's password using the AS-REP Roasting technique. This activity is significant as it can be used by attackers with existing privileges to escalate their access or maintain persistence. If confirmed malicious, this could lead to unauthorized access and potential compromise of sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `User Account Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} known_false_positives = Unknown. @@ -7263,7 +7184,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Set-ADAccountControl` commandlet with specific parameters. `Set-ADAccountControl` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Set-ADAccountControl` is used to modify User Account Control values for an Active Directory domain account. With the appropiate parameters, Set-ADAccountControl allows adversaries to disable Kerberos Pre-Authentication for an account to to easily perform a brute force attack against the user's password offline leveraging the ASP REP Roasting technique. Red Teams and adversaries alike who have obtained privileges in an Active Directory network may use this technique as a backdoor or a way to escalate privileges. +explanation = The following analytic detects the use of the `Set-ADAccountControl` PowerShell cmdlet with parameters that disable Kerberos Pre-Authentication. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific command execution. Disabling Kerberos Pre-Authentication is significant because it allows adversaries to perform offline brute force attacks against user passwords using the AS-REP Roasting technique. If confirmed malicious, this activity could enable attackers to escalate privileges or maintain persistence within an Active Directory environment, posing a severe security risk. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, Administrators may need to set this flag for legitimate purposes. @@ -7273,7 +7194,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential Kerberos Service Ticket request related to a Golden Ticket attack. Adversaries who have obtained the Krbtgt account NTLM password hash may forge a Kerberos Granting Ticket (TGT) to obtain unrestricted access to an Active Directory environment. Armed with a Golden Ticket, attackers can request service tickets to move laterally and execute code on remote systems. Looking for Kerberos Service Ticket requests using the legacy RC4 encryption mechanism could represent the second stage of a Golden Ticket attack. RC4 usage should be rare on a modern network since Windows Vista & Windows Sever 2008 and newer support AES Kerberos encryption.\ Defenders should note that if an attacker does not leverage the NTLM password hash but rather the AES key to create a golden ticket, this detection may be bypassed. +explanation = The following analytic detects Kerberos service ticket requests using RC4 encryption, leveraging Kerberos Event 4769. This method identifies potential Golden Ticket attacks, where adversaries forge Kerberos Granting Tickets (TGT) using the Krbtgt account NTLM password hash to gain unrestricted access to an Active Directory environment. Monitoring for RC4 encryption usage is significant as it is rare in modern networks, indicating possible malicious activity. If confirmed malicious, attackers could move laterally and execute code on remote systems, compromising the entire network. Note: This detection may be bypassed if attackers use the AES key instead of the NTLM hash. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.001"], "nist": ["DE.CM"]} known_false_positives = Based on Microsoft documentation, legacy systems or applications will use RC4-HMAC as the default encryption for Kerberos Service Ticket requests. Specifically, systems before Windows Server 2008 and Windows Vista. Newer systems will use AES128 or AES256. @@ -7283,7 +7204,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event 4768, A Kerberos authentication ticket (TGT) was requested, to identify a TGT request with encryption type 0x17, or RC4-HMAC. This encryption type is no longer utilized by newer systems and could represent evidence of an OverPass The Hash attack. Similar to Pass The Hash, OverPass The Hash is a form of credential theft that allows adversaries to move laterally or consume resources in a target network. Leveraging this attack, an adversary who has stolen the NTLM hash of a valid domain account is able to authenticate to the Kerberos Distribution Center(KDC) on behalf of the legitimate account and obtain a Kerberos TGT ticket. Depending on the privileges of the compromised account, this ticket may be used to obtain unauthorized access to systems and other network resources. +explanation = The following analytic detects a Kerberos Ticket Granting Ticket (TGT) request using RC4-HMAC encryption (type 0x17) by leveraging Event 4768. This encryption type is outdated and its presence may indicate an OverPass The Hash attack. Monitoring this activity is crucial as it can signify credential theft, allowing adversaries to authenticate to the Kerberos Distribution Center (KDC) using a stolen NTLM hash. If confirmed malicious, this could enable unauthorized access to systems and resources, potentially leading to lateral movement and further compromise within the network. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550"], "nist": ["DE.CM"]} known_false_positives = Based on Microsoft documentation, legacy systems or applications will use RC4-HMAC as the default encryption for TGT requests. Specifically, systems before Windows Server 2008 and Windows Vista. Newer systems will use AES128 or AES256. @@ -7293,7 +7214,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event Id 4768, A Kerberos authentication ticket (TGT) was requested, to identify one source endpoint trying to obtain an unusual number Kerberos TGT ticket for non existing users. This behavior could represent an adversary abusing the Kerberos protocol to perform a user enumeration attack against an Active Directory environment. When Kerberos is sent a TGT request with no preauthentication for an invalid username, it responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN or 0x6. Red teams and adversaries alike may abuse the Kerberos protocol to validate a list of users use them to perform further attacks.\ The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number requests. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. +explanation = The following analytic detects an unusual number of Kerberos Ticket Granting Ticket (TGT) requests for non-existing users from a single source endpoint. It leverages Event ID 4768 and identifies anomalies using the 3-sigma statistical rule. This behavior is significant as it may indicate an adversary performing a user enumeration attack against Active Directory. If confirmed malicious, the attacker could validate a list of usernames, potentially leading to further attacks such as brute force or credential stuffing, compromising the security of the environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1589", "T1589.002"], "nist": ["DE.AE"]} known_false_positives = Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. @@ -7303,7 +7224,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search detects a suspicioous termination of known services killed by ransomware before encrypting files in a compromised machine. This technique is commonly seen in most of ransomware now a days to avoid exception error while accessing the targetted files it wants to encrypts because of the open handle of those services to the targetted file. +explanation = The following analytic detects the suspicious termination of known services commonly targeted by ransomware before file encryption. It leverages Windows System Event Logs (EventCode 7036) to identify when critical services such as Volume Shadow Copy, backup, and antivirus services are stopped. This activity is significant because ransomware often disables these services to avoid errors and ensure successful file encryption. If confirmed malicious, this behavior could lead to widespread data encryption, rendering files inaccessible and potentially causing significant operational disruption and data loss. how_to_implement = To successfully implement this search, you need to be ingesting logs with the 7036 EventCode ScManager in System audit Logs from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = Admin activities or installing related updates may do a sudden stop to list of services we monitor. @@ -7313,7 +7234,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a deletion of ssh key in a linux machine. attacker may delete or modify ssh key to impair some security features or act as defense evasion in compromised linux machine. This Anomaly can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation. +explanation = The following analytic detects the deletion of SSH keys on a Linux machine. It leverages filesystem event logs to identify when files within "/etc/ssh/*" or "~/.ssh/*" are deleted. This activity is significant because attackers may delete or modify SSH keys to evade security measures or as part of a destructive payload, similar to the AcidRain malware. If confirmed malicious, this behavior could lead to impaired security features, hindered forensic investigations, or further unauthorized access, necessitating immediate investigation to identify the responsible process and user. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7323,7 +7244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic aims to detect unauthorized activities through suspicious file creation in recognized cron table directories, prevalent Unix-based locations for scheduling tasks. This behavior is often exploited by nefarious entities like malware or threat actors, including red teamers, to establish persistence on a targeted or compromised host. The analogy to Windows-based scheduled tasks helps explain the utility of a crontab or cron job. To enhance clarity and actionable intelligence, the anomaly query flags the anomaly, urging further investigation into the added file's details. A cybersecurity analyst should consider additional data points such as the user identity involved, the file's nature and purpose, file origin, timestamp, and any changes in system behavior post file execution. This comprehensive understanding aids in accurately determining the file's legitimacy, facilitating prompt and effective response actions. +explanation = The following analytic detects unauthorized file creation in known crontab directories on Unix-based systems. It leverages filesystem data to identify new files in directories such as /etc/cron* and /var/spool/cron/*. This activity is significant as it may indicate an attempt by threat actors or malware to establish persistence on a compromised host. If confirmed malicious, this could allow attackers to execute arbitrary code at scheduled intervals, potentially leading to further system compromise and unauthorized access to sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create file in crontab folders for automation purposes. Please update the filter macros to remove false positives. @@ -7333,7 +7254,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for commands to create user accounts on the linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to persist on the targeted or compromised host by creating new user with an elevated privilege. This Hunting query may catch normal creation of user by administrator so filter is needed. +explanation = The following analytic detects the creation of new user accounts on Linux systems using commands like "useradd" or "adduser." It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as adversaries often create new user accounts to establish persistence on compromised hosts. If confirmed malicious, this could allow attackers to maintain access, escalate privileges, and further compromise the system, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7343,7 +7264,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious modifications to cron jobs on Linux systems using the crontab command with list parameters. This command line parameter can be abused by malware like Industroyer2, as well as adversaries and red teamers, to add a crontab entry for executing their malicious code on a schedule of their choice. However, it's important to note that administrators or normal users may also use this command for legitimate automation purposes, so filtering is required to minimize false positives. Identifying the modification of cron jobs using list parameters is valuable for a SOC as it indicates potential malicious activity or an attempt to establish persistence on the system. If a true positive is detected, further investigation should be conducted to analyze the added cron job, its associated command, and the impact it may have on the system. This includes examining the purpose of the job, reviewing any on-disk artifacts, and identifying any related processes or activities occurring concurrently. The impact of a true positive can range from unauthorized execution of malicious code to data destruction or other damaging outcomes. +explanation = The following analytic detects suspicious modifications to cron jobs on Linux systems using the crontab command with list parameters. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt to establish persistence or execute malicious code on a schedule. If confirmed malicious, the impact could include unauthorized code execution, data destruction, or other damaging outcomes. Further investigation should analyze the added cron job, its associated command, and any related processes. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -7353,7 +7274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The apt-get is a command line tool for interacting with the Advanced Package Tool (APT) library (a package management system for Linux distributions). It allows you to search for, install, manage, update, and remove software. The tool does not build software from the source code. If sudo right is given to the tool for user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the 'apt-get' command with elevated privileges using 'sudo' on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it indicates a user may be attempting to escalate privileges to root, which could lead to unauthorized system control. If confirmed malicious, an attacker could gain root access, allowing them to execute arbitrary commands, install or remove software, and potentially compromise the entire system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7363,7 +7284,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Advanced Package Tool, more commonly known as APT, is a collection of tools used to install, update, remove, and otherwise manage software packages on Debian and its derivative operating systems, including Ubuntu and Linux Mint. If sudo right is given to the tool for user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the use of the Advanced Package Tool (APT) with elevated privileges via sudo on Linux systems. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes where APT commands are executed with sudo rights. This activity is significant because it indicates a user can run system commands as root, potentially leading to unauthorized root shell access. If confirmed malicious, this could allow an attacker to escalate privileges, execute arbitrary commands, and gain full control over the affected system, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7373,8 +7294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of suspicious configuration files, /etc/at.allow or /etc/at.deny, in Linux. These files are commonly abused by malware, adversaries, or red teamers to establish persistence on compromised hosts. The configuration files determine which users are allowed to execute the "at" application, which is used for scheduling tasks in Linux. Attackers can add their user or a compromised username to these files to execute malicious code using "at." It's important to consider potential false positives as administrators or network operators may create these files for legitimate automation purposes. Adjust the filter macros to minimize false positives. \ -Identifying the creation of these configuration files is valuable for a SOC as it indicates potential unauthorized activities or an attacker attempting to establish persistence. If a true positive is found, further investigation is necessary to examine the contents of the created configuration file and determine the source of creation. The impact of a true positive can vary but could result in unauthorized execution of malicious code, data theft, or other detrimental consequences. Analysts should review the file path, creation time, and associated processes to assess the extent of the attack and initiate appropriate response actions. +explanation = The following analytic detects the creation of the /etc/at.allow or /etc/at.deny configuration files in Linux. It leverages file creation events from the Endpoint datamodel to identify when these files are created. This activity is significant as these files control user permissions for the "at" scheduling application and can be abused by attackers to establish persistence. If confirmed malicious, this could allow unauthorized execution of malicious code, leading to potential data theft or further system compromise. Analysts should review the file path, creation time, and associated processes to assess the threat. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints into the Endpoint datamodel. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create this file for automation purposes. Please update the filter macros to remove false positives. @@ -7384,9 +7304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the execution of the "At" application in Linux, which can be used by attackers to create persistence entries on a compromised host. The "At" application can be used for automation purposes by administrators or network operators, so the filter macros should be updated to remove false positives. If a true positive is found, it suggests an attacker is trying to maintain access to the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, ensure you are ingesting logs with the required fields from your endpoints into the Endpoint datamodel. When a true positive is detected, it suggests that an attacker is attempting to establish persistence or deliver additional malicious payloads by leveraging the "At" application. This behavior can lead to data theft, ransomware attacks, or other damaging outcomes. \ -During triage, the SOC analyst should review the context surrounding the execution of the "At" application. This includes identifying the user, the parent process responsible for invoking the application, and the specific command-line arguments used. It is important to consider whether the execution is expected behavior by an administrator or network operator for legitimate automation purposes. \ -The presence of "At" application execution may indicate an attacker's attempt to maintain unauthorized access to the environment. Immediate investigation and response are necessary to mitigate further risks, identify the attacker's intentions, and prevent potential harm to the organization. +explanation = The following analytic detects the execution of the "At" application in Linux, which can be used by attackers to create persistence entries on a compromised host. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent process names associated with "at" or "atd". This activity is significant because the "At" application can be exploited to maintain unauthorized access or deliver additional malicious payloads. If confirmed malicious, this behavior could lead to data theft, ransomware attacks, or other severe consequences. Immediate investigation is required to determine the legitimacy of the execution and mitigate potential risks. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.002", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -7396,7 +7314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Awk is mostly used for processing and scanning patterns. It checks one or more files to determine whether any lines fit the specified patterns, and if so, it does the appropriate action. If sudo right is given to AWK binary for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the use of the AWK command with elevated privileges to execute system commands. It leverages Endpoint Detection and Response (EDR) telemetry, specifically monitoring processes that include "sudo," "awk," and "BEGIN*system" in their command lines. This activity is significant because it indicates a potential privilege escalation attempt, where a user could gain root access by executing commands as the root user. If confirmed malicious, this could allow an attacker to fully compromise the system, execute arbitrary commands, and maintain persistent control over the affected endpoint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -7406,7 +7324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides minimalist replacements for most of the utilities you usually find in GNU coreutils, util-linux, etc. If sudo right is given to BusyBox application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of BusyBox with sudo privileges, which can lead to privilege escalation on Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where BusyBox is executed with both 'sh' and 'sudo' commands. This activity is significant because it indicates a user may be attempting to gain root access, bypassing standard security controls. If confirmed malicious, this could allow an attacker to execute arbitrary commands as root, leading to full system compromise and potential persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7416,7 +7334,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The c89 and cc commands compile, assemble, and link-edit C programs; the cxx or c++ command does the same for C++ programs. The c89 command should be used when compiling C programs that are written according to Standard C. If sudo right is given to c89 application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the 'c89' command with elevated privileges, which can be used to compile and execute C programs as root. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events that include command-line arguments. This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute arbitrary commands as root. If confirmed malicious, this could lead to full system compromise, enabling the attacker to gain root access and execute any command with elevated privileges. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7426,7 +7344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The c99 utility is an interface to the standard C compilation system; it shall accept source code conforming to the ISO C standard. The system conceptually consists of a compiler and link editor. If sudo right is given to ruby application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the c99 utility with sudo privileges, which can lead to privilege escalation on Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it indicates a potential misuse of the c99 utility to gain root access, which is critical for maintaining system security. If confirmed malicious, this could allow an attacker to execute commands as root, potentially compromising the entire system and accessing sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7436,7 +7354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for a commandline that change the file owner to root using chown utility tool. This technique is commonly abuse by adversaries, malware author and red teamers to escalate privilege to the targeted or compromised host by changing the owner of their malicious file to root. This event is not so common in corporate network except from the administrator doing normal task that needs high privilege. +explanation = The following analytic detects the use of the 'chown' command to change a file owner to 'root' on a Linux system. It leverages Endpoint Detection and Response (EDR) telemetry, specifically monitoring command-line executions and process details. This activity is significant as it may indicate an attempt to escalate privileges by adversaries, malware, or red teamers. If confirmed malicious, this action could allow an attacker to gain root-level access, leading to full control over the compromised host and potential persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222.002", "T1222"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7456,7 +7374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for possible elevation control access using a common known process in linux platform to change the attribute and file ownership. This technique is commonly abused by adversaries, malware author and red teamers to gain persistence or privilege escalation on the target or compromised host. This common process is used to modify file attribute, file ownership or SUID. This tools can be used in legitimate purposes so filter is needed. +explanation = The following analytic identifies the execution of common Linux processes used for elevation control, such as `chmod`, `chown`, and `setuid`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because these processes are often abused by adversaries to gain persistence or escalate privileges on compromised hosts. If confirmed malicious, this behavior could allow attackers to modify file attributes, change file ownership, or set user IDs, potentially leading to unauthorized access and control over critical system resources. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7466,7 +7384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you. If sudo right is given to tool for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the Composer tool with elevated privileges on a Linux system. It identifies instances where Composer is run with the 'sudo' command, allowing the user to execute system commands as root. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because it can indicate an attempt to escalate privileges, potentially leading to unauthorized root access. If confirmed malicious, an attacker could gain full control over the system, execute arbitrary commands, and compromise sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7476,7 +7394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = cpulimit is a simple program which attempts to limit the cpu usage of a process (expressed in percentage, not in cpu time). This is useful to control batch jobs, when you don't want them to eat too much cpu. If sudo right is given to the program for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the use of the 'cpulimit' command with specific flags ('-l', '-f') executed with 'sudo' privileges. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments and execution details. This activity is significant because if 'cpulimit' is granted sudo rights, a user can potentially execute system commands as root, leading to privilege escalation. If confirmed malicious, this could allow an attacker to gain root access, execute arbitrary commands, and fully compromise the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7486,7 +7404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = csvtool is an easy to use command-line tool to work with .CSV files. If sudo right is given to the tool for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the 'csvtool' command with 'sudo' privileges, which can allow a user to run system commands as root. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it indicates a potential privilege escalation attempt, where a user could gain unauthorized root access. If confirmed malicious, this could lead to full system compromise, allowing an attacker to execute arbitrary commands, escalate privileges, and maintain persistent access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7496,7 +7414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies curl being utilized with the -F or --form, --upload-file, -T, -d, --data, --data-raw, -I and --head switches to upload AWS credentials or config to a remote destination. This enables uploading of binary files and so forth. To force the 'content' part to be a file, prefix the file name with an @ sign. To just get the content part from a file, prefix the file name with the symbol <. The difference between @ and < is then that @ makes a file get attached in the post as a file upload, while the < makes a text field and just get the contents for that text field from a file. This technique was utlized by the TeamTNT group to exfiltrate AWS credentials. +explanation = The following analytic detects the use of the curl command with specific switches (-F, --form, --upload-file, -T, -d, --data, --data-raw, -I, --head) to upload AWS credentials or configuration files to a remote destination. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it may indicate an attempt to exfiltrate sensitive AWS credentials, a technique known to be used by the TeamTNT group. If confirmed malicious, this could lead to unauthorized access and potential compromise of AWS resources. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = Filtering may be required. In addition to AWS credentials, add other important files and monitor. The inverse would be to look for _all_ -F behavior and tune from there. @@ -7506,7 +7424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a unix shell command that can wipe root folders of a linux host. This commandline is being abused by Awfulshred malware that wipes or corrupts files in a targeted Linux host. The shell command uses the rm command with force recursive deletion even in the root folder. This TTP can be a good indicator that a user or a process wants to wipe roots directory files in Linux host. +explanation = The following analytic detects the execution of a Unix shell command designed to wipe root directories on a Linux host. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on the 'rm' command with force recursive deletion and the '--no-preserve-root' option. This activity is significant as it indicates potential data destruction attempts, often associated with malware like Awfulshred. If confirmed malicious, this behavior could lead to severe data loss, system instability, and compromised integrity of the affected Linux host. Immediate investigation and response are crucial to mitigate potential damage. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -7516,7 +7434,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for dd command to overwrite file. This technique was abused by adversaries or threat actor to destroy files or data on specific system or in a large number of host within network to interrupt host avilability, services and many more. This is also used to destroy data where it make the file irrecoverable by forensic techniques through overwriting files, data or local and remote drives. +explanation = The following analytic detects the use of the 'dd' command to overwrite files on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because adversaries often use the 'dd' command to destroy or irreversibly overwrite files, disrupting system availability and services. If confirmed malicious, this behavior could lead to data destruction, making recovery difficult and potentially causing significant operational disruptions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7526,7 +7444,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the behavior of decoding base64-encoded data and passing it to a Linux shell. Additionally, it mitigates the potential damage and protects the organization's systems and data.The detection is made by searching for specific commands in the Splunk query, namely "base64 -d" and "base64 --decode", within the Endpoint.Processes data model. The analytic also includes a filter for Linux shells. The detection is important because it indicates the presence of malicious activity since Base64 encoding is commonly used to obfuscate malicious commands or payloads, and decoding it can be a step in running those commands. It suggests that an attacker is attempting to run malicious commands on a Linux system to gain unauthorized access, for data exfiltration, or perform other malicious actions. +explanation = The following analytic detects the decoding of base64-encoded data and its execution in a Linux shell. It leverages the Endpoint.Processes data model to search for commands like "base64 -d" and "base64 --decode" combined with Linux shell execution. This activity is significant because base64 encoding is often used to obfuscate malicious commands or payloads, indicating potential malicious activity. If confirmed malicious, this behavior could allow an attacker to execute unauthorized commands, gain unauthorized access, exfiltrate data, or perform other harmful actions on the Linux system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1027", "T1059.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on legitimate software being utilized. Filter as needed. @@ -7536,7 +7454,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious deletion of a critical folder in Linux machine using rm command. This technique was seen in industroyer2 campaign to wipe or destroy energy facilities of a targeted sector. Deletion in these list of folder is not so common since it need some elevated privileges to access some of it. We recommend to look further events specially in file access or file deletion, process commandline that may related to this technique. +explanation = The following analytic detects the deletion of critical directories on a Linux machine using the `rm` command with argument rf. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions targeting directories like /boot, /var/log, /etc, and /dev. This activity is significant because deleting these directories can severely disrupt system operations and is often associated with destructive campaigns like Industroyer2. If confirmed malicious, this action could lead to system instability, data loss, and potential downtime, making it crucial for immediate investigation and response. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -7546,7 +7464,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a deletion of cron job in a linux machine. This technique can be related to an attacker, threat actor or malware to disable scheduled cron jobs that might be related to security or to evade some detections. We also saw that this technique can be a good indicator for malware that is trying to wipe or delete several files on the compromised host like the acidrain malware. This anomaly detection can be a good pivot detection to look for process and user doing it why they doing. Take note that this event can be done by administrator so filtering on those possible false positive event is needed. +explanation = The following analytic detects the deletion of cron jobs on a Linux machine. It leverages filesystem event logs to identify when files within the "/etc/cron.*" directory are deleted. This activity is significant because attackers or malware may delete cron jobs to disable scheduled security tasks or evade detection mechanisms. If confirmed malicious, this action could allow an attacker to disrupt system operations, evade security measures, or facilitate further malicious activities such as data wiping, as seen with the acidrain malware. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7556,7 +7474,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a deletion of init daemon script in a linux machine. daemon script that place in /etc/init.d/ is a directory that can start and stop some daemon services in linux machines. attacker may delete or modify daemon script to impair some security features or act as defense evasion in a compromised linux machine. This TTP can be also a good indicator of a malware trying to wipe or delete several files in compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation. +explanation = The following analytic detects the deletion of init daemon scripts on a Linux machine. It leverages filesystem event logs to identify when files within the /etc/init.d/ directory are deleted. This activity is significant because init daemon scripts control the start and stop of critical services, and their deletion can indicate an attempt to impair security features or evade defenses. If confirmed malicious, this behavior could allow an attacker to disrupt essential services, execute destructive payloads, or persist undetected in the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7566,7 +7484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a deletion of services in a linux machine. attacker may delete or modify services to impair some security features or act as defense evasion in a compromised linux machine. This TTP can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation. +explanation = The following analytic detects the deletion of services on a Linux machine. It leverages filesystem event logs to identify when service files within system directories (e.g., /etc/systemd/, /lib/systemd/, /run/systemd/) are deleted. This activity is significant because attackers may delete or modify services to disable security features or evade defenses. If confirmed malicious, this behavior could indicate an attempt to impair system functionality or execute a destructive payload, potentially leading to system instability or data loss. Immediate investigation is required to determine the responsible process and user. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7576,7 +7494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a deletion of ssl certificate in a linux machine. attacker may delete or modify ssl certificate to impair some security features or act as defense evasion in compromised linux machine. This Anomaly can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation. +explanation = The following analytic detects the deletion of SSL certificates on a Linux machine. It leverages filesystem event logs to identify when files with extensions .pem or .crt are deleted from the /etc/ssl/certs/ directory. This activity is significant because attackers may delete or modify SSL certificates to disable security features or evade defenses on a compromised system. If confirmed malicious, this behavior could indicate an attempt to disrupt secure communications, evade detection, or execute a destructive payload, potentially leading to significant security breaches and data loss. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7586,7 +7504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to detect events that attempts to disable a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 malware to terminate security services or other related services to continue there objective as a destructive payload. +explanation = The following analytic detects attempts to disable a service on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes like "systemctl," "service," and "svcadm" with commands containing "disable." This activity is significant as adversaries may disable security or critical services to evade detection and facilitate further malicious actions, such as deploying destructive payloads. If confirmed malicious, this could lead to the termination of essential security services, allowing attackers to persist undetected and potentially cause significant damage to the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -7596,7 +7514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect the creation of doas.conf file in linux host platform. This configuration file can be use by doas utility tool to allow or permit standard users to perform tasks as root, the same way sudo does. This tool is developed as a minimalistic alternative to sudo application. This tool can be abused advesaries, attacker or malware to gain elevated privileges to the targeted or compromised host. On the other hand this can also be executed by administrator for a certain task that needs admin rights. In this case filter is needed. +explanation = The following analytic detects the creation of the doas.conf file on a Linux host. This file is used by the doas utility to allow standard users to perform tasks as root, similar to sudo. The detection leverages filesystem data from the Endpoint data model, focusing on the creation of the doas.conf file. This activity is significant because it can indicate an attempt to gain elevated privileges, potentially by an adversary. If confirmed malicious, this could allow an attacker to execute commands with root privileges, leading to full system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7606,7 +7524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect the doas tool execution in linux host platform. This utility tool allow standard users to perform tasks as root, the same way sudo does. This tool is developed as a minimalistic alternative to sudo application. This tool can be abused advesaries, attacker or malware to gain elevated privileges to the targeted or compromised host. On the other hand this can also be executed by administrator for a certain task that needs admin rights. In this case filter is needed. +explanation = The following analytic detects the execution of the 'doas' tool on a Linux host. This tool allows standard users to perform tasks with root privileges, similar to 'sudo'. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as 'doas' can be exploited by adversaries to gain elevated privileges on a compromised host. If confirmed malicious, this could lead to unauthorized administrative access, potentially compromising the entire system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7616,7 +7534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Docker is an open source containerization platform. It helps programmers to bundle applications into containers, which are standardized executable parts that include the application source code along with the OS libraries and dependencies needed to run that code in any setting. The user can add mount the root directory into a container and edit the /etc/password file to add a super user. This requires the user to be privileged enough to run docker, i.e. being in the docker group or being root. +explanation = The following analytic detects attempts to escalate privileges on a Linux system using Docker. It identifies processes where Docker commands are used to mount the root directory or execute shell commands within a container. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names, command-line arguments, and parent processes. This activity is significant because it can allow an attacker with Docker privileges to modify critical system files, such as /etc/passwd, to create a superuser. If confirmed malicious, this could lead to full system compromise and persistent unauthorized access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -7626,10 +7544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the suspicious editing of cron jobs in Linux via the crontab command-line parameter. This tactic could be used by adversaries or malware to schedule execution of their malicious code, potentially leading to system compromise or unauthorized persistent access. It pinpoints this activity by monitoring command-line executions involving 'crontab' and the edit parameter (-e). \ -Recognizing such activity is vital for a SOC as cron job manipulations might signal unauthorized persistence attempts or scheduled malicious actions, potentially resulting in substantial harm. A true positive signifies an active threat, with implications ranging from unauthorized access to broader network compromise. \ -To implement this analytic, logs capturing process name, parent process, and command-line executions from your endpoints must be ingested. \ -Known false positives could stem from valid administrative tasks or automation processes using crontab. To reduce these, fine-tune the filter macros according to the benign activities within your environment. These adjustments ensure legitimate actions aren't mistaken for threats, allowing analysts to focus on genuine potential risks. +explanation = The following analytic detects the suspicious editing of cron jobs in Linux using the crontab command-line parameter (-e). It identifies this activity by monitoring command-line executions involving 'crontab' and the edit parameter. This behavior is significant for a SOC as cron job manipulations can indicate unauthorized persistence attempts or scheduled malicious actions. If confirmed malicious, this activity could lead to system compromise, unauthorized access, or broader network compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -7639,7 +7554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = EMACS is a family of text editors that are characterized by their extensibility. The manual for the most widely used variant, GNU Emacs, describes it as "the extensible, customizable, self-documenting, real-time display editor". If sudo right is given to EMACS tool for the user, then the user can run special commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of Emacs with elevated privileges using the `sudo` command and the `--eval` option. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line arguments. This activity is significant because it indicates a potential privilege escalation attempt, where a user could gain root access by running Emacs with elevated permissions. If confirmed malicious, this could allow an attacker to execute arbitrary commands as root, leading to full system compromise and unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7649,7 +7564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious file creation in kernel/driver directory in linux platform. This directory is known folder for all linux kernel module available within the system. so creation of file in this directory is a good indicator that there is a possible rootkit installation in the host machine. This technique was abuse by adversaries, malware author and red teamers to gain high privileges to their malicious code such us in kernel level. Even this event is not so common administrator or legitimate 3rd party tool may install driver or linux kernel module as part of its installation. +explanation = The following analytic detects the creation of files in the Linux kernel/driver directory. It leverages filesystem data to identify new files in this critical directory. This activity is significant because the kernel/driver directory is typically reserved for kernel modules, and unauthorized file creation here can indicate a rootkit installation. If confirmed malicious, this could allow an attacker to gain high-level privileges, potentially compromising the entire system by executing code at the kernel level. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create file in this folders for automation purposes. Please update the filter macros to remove false positives. @@ -7659,7 +7574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious file creation on init system directories for automatic execution of script or file upon boot up. This technique is commonly abuse by adversaries, malware author and red teamer to persist on the targeted or compromised host. This behavior can be executed or use by an administrator or network operator to add script files or binary files as part of a task or automation. filter is needed. +explanation = The following analytic detects the creation of files in Linux init boot directories, which are used for automatic execution upon system startup. It leverages file system logs to identify new files in directories such as /etc/init.d/ and /etc/rc.d/. This activity is significant as it is a common persistence technique used by adversaries, malware authors, and red teamers. If confirmed malicious, this could allow an attacker to maintain persistence on the compromised host, potentially leading to further exploitation and unauthorized control over the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1037.004", "T1037"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create file in this folders for automation purposes. Please update the filter macros to remove false positives. @@ -7669,7 +7584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious file creation in /etc/profile.d directory to automatically execute scripts by shell upon boot up of a linux machine. This technique is commonly abused by adversaries, malware and red teamers as a persistence mechanism to the targeted or compromised host. This Anomaly detection is a good indicator that someone wants to run a code after boot up which can be done also by the administrator or network operator for automation purposes. +explanation = The following analytic detects the creation of files in the /etc/profile.d directory on Linux systems. It leverages filesystem data to identify new files in this directory, which is often used by adversaries for persistence by executing scripts upon system boot. This activity is significant as it may indicate an attempt to maintain long-term access to the compromised host. If confirmed malicious, this could allow attackers to execute arbitrary code with elevated privileges each time the system boots, potentially leading to further compromise and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.004", "T1546"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create file in profile.d folders for automation purposes. Please update the filter macros to remove false positives. @@ -7679,7 +7594,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Find is a command-line utility that locates files based on some user-specified criteria and either prints the pathname of each matched object or, if another action is requested, performs that action on each matched object. If sudo right is given to find utility for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the use of the 'find' command with 'sudo' and '-exec' options, which can indicate an attempt to escalate privileges on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line arguments. This activity is significant because it can allow a user to execute system commands as root, potentially leading to a root shell. If confirmed malicious, this could enable an attacker to gain full control over the system, leading to severe security breaches and unauthorized access to sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -7689,7 +7604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = GDB is the acronym for GNU Debugger. This tool helps to debug the programs written in C, C++, Ada, Fortran, etc. The console can be opened using the gdb command on terminal. If sudo right is given to GDB tool for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the GNU Debugger (GDB) with specific flags that indicate an attempt to escalate privileges on a Linux system. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes where GDB is run with the `-nx`, `-ex`, and `sudo` flags. This activity is significant because it can allow a user to execute system commands as root, potentially leading to a root shell. If confirmed malicious, this could result in full system compromise, allowing an attacker to gain complete control over the affected endpoint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7699,7 +7614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = RubyGems is a package manager for the Ruby programming language that provides a standard format for distributing Ruby programs and libraries (in a self-contained format called a "gem"), a tool designed to easily manage the installation of gems, and a server for distributing them. If sudo right is given to GEM utility for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the RubyGems utility with elevated privileges, specifically when it is used to run system commands as root. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include "gem open -e" and "sudo". This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute commands as the root user. If confirmed malicious, this could lead to full system compromise, enabling the attacker to gain root access and execute arbitrary commands with elevated privileges. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7709,7 +7624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = gawk command in Linux is used for pattern scanning and processing language. The awk command requires no compiling and allows the user to use variables, numeric functions, string functions, and logical operators. It is a utility that enables programmers to write tiny and effective programs in the form of statements that define text patterns that are to be searched for, in a text document and the action that is to be taken when a match is found within a line. If sudo right is given to gawk tool for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the 'gawk' command with elevated privileges on a Linux system. It leverages Endpoint Detection and Response (EDR) telemetry to identify command-line executions where 'gawk' is used with 'sudo' and 'BEGIN{system' patterns. This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute system commands as root. If confirmed malicious, this could lead to full root access, enabling the attacker to control the system, modify critical files, and maintain persistent access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7719,7 +7634,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for process execution to disable the swapping of paging devices. This technique was seen in Awfulshred malware that disables the swapping of the specified devices and files. This anomaly detection can be a good indicator that a process or a user tries to disable this Linux feature in a targeted host. +explanation = The following analytic detects the execution of the "swapoff" command, which disables the swapping of paging devices on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because disabling swap can be a tactic used by malware, such as Awfulshred, to evade detection and hinder forensic analysis. If confirmed malicious, this action could allow an attacker to manipulate system memory management, potentially leading to data corruption, system instability, or evasion of memory-based detection mechanisms. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1200"], "nist": ["DE.AE"]} known_false_positives = administrator may disable swapping of devices in a linux host. Filter is needed. @@ -7729,7 +7644,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a high frequency of file deletion relative to process name and process id /boot/ folder. These events was seen in industroyer2 wiper malware where it tries to delete all files in a critical directory in linux directory. This detection already contains some filter that might cause false positive during our testing. +explanation = The following analytic detects a high frequency of file deletions in the /boot/ folder on Linux systems. It leverages filesystem event logs to identify when 200 or more files are deleted within an hour by the same process. This behavior is significant as it may indicate the presence of wiper malware, such as Industroyer2, which targets critical system directories. If confirmed malicious, this activity could lead to system instability or failure, hindering the boot process and potentially causing a complete system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]} known_false_positives = linux package installer/uninstaller may cause this event. Please update you filter macro to remove false positives. @@ -7739,7 +7654,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a high frequency of file deletion relative to process name and process id /etc/ folder. These events was seen in acidrain wiper malware where it tries to delete all files in a non-standard directory in linux directory. This detection already contains some filter that might cause false positive during our testing. But we recommend to add more filter if needed. +explanation = The following analytic detects a high frequency of file deletions in the /etc/ folder on Linux systems. It leverages the Endpoint.Filesystem data model to identify instances where 200 or more files are deleted within an hour, grouped by process name and process ID. This behavior is significant as it may indicate the presence of wiper malware, such as AcidRain, which aims to delete critical system files. If confirmed malicious, this activity could lead to severe system instability, data loss, and potential disruption of services. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]} known_false_positives = linux package installer/uninstaller may cause this event. Please update you filter macro to remove false positives. @@ -7749,7 +7664,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for PKILL process execution for possible termination of process. This technique is being used by several Threat actors, adversaries and red teamers to terminate processes in a targeted linux machine. This Hunting detection can be a good pivot to check a possible defense evasion technique or termination of security application in a linux host or wiper like Awfulshred that corrupt all files. +explanation = The following analytic identifies the execution of the 'pkill' command, which is used to terminate processes on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because threat actors often use 'pkill' to disable security defenses or terminate critical processes, facilitating further malicious actions. If confirmed malicious, this behavior could lead to the disruption of security applications, enabling attackers to evade detection and potentially corrupt or destroy files on the targeted system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = network admin can terminate a process using this linux command. Filter is needed. @@ -7759,7 +7674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for processes that clear or free page cache in Linux system host. This technique was seen in Awfulshred malware wiper that tries to clear the cache using kernel system request drop_caches while wiping all files in the targeted host. This TTP detection can be a good indicator of user or process tries to clear page cache to delete tracks or might be a wiper like Awfulshred. +explanation = The following analytic detects processes that clear or free page cache on a Linux system. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line executions involving the kernel system request `drop_caches`. This activity is significant as it may indicate an attempt to delete forensic evidence or the presence of wiper malware like Awfulshred. If confirmed malicious, this behavior could allow an attacker to cover their tracks, making it difficult to investigate other malicious activities or system compromises. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -7769,7 +7684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious linux processes that delete service unit configuration files. This technique was seen in several malware to delete service configuration files to corrupt a services or security product as part of its defense evasion. This TTP detection can be a good indicator of possible malware try to kill several services or a wiper like AwfulShred shell script that wipes the targeted linux host +explanation = The following analytic detects the deletion of Linux service unit configuration files by suspicious processes. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on processes executing the 'rm' command targeting '.service' files. This activity is significant as it may indicate malware attempting to disable critical services or security products, a common defense evasion tactic. If confirmed malicious, this behavior could lead to service disruption, security tool incapacitation, or complete system compromise, severely impacting the integrity and availability of the affected Linux host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.004", "T1070"], "nist": ["DE.AE"]} known_false_positives = network admin can delete services unit configuration file as part of normal software installation. Filter is needed. @@ -7789,7 +7704,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies curl with the command-line switches that are commonly used to download, output, a remote script or binary. MetaSploit Framework will combine the -sO switch with | chmod +x to enable a simple one liner to download and set the execute bit to run the file immediately. During triage, review the remote domain and file being downloaded for legitimacy. +explanation = The following analytic detects the use of the curl command with specific switches (-O, -sO, -ksO, --output) commonly used to download remote scripts or binaries. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it may indicate an attempt to download and execute potentially malicious files, often used in initial stages of an attack. If confirmed malicious, this could lead to unauthorized code execution, enabling attackers to compromise the system further. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.AE"]} known_false_positives = False positives will be present. Tune and then change type to TTP. @@ -7799,7 +7714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for inserting of linux kernel module using insmod utility function. This event can detect a installation of rootkit or malicious kernel module to gain elevated privileges to their malicious code and bypassed detections. This Anomaly detection is a good indicator that someone installing kernel module in a linux host either admin or adversaries. filter is needed in this scenario +explanation = The following analytic detects the insertion of a Linux kernel module using the insmod utility. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include process names and command-line details. This activity is significant as it may indicate the installation of a rootkit or malicious kernel module, potentially allowing an attacker to gain elevated privileges and bypass security detections. If confirmed malicious, this could lead to unauthorized code execution, persistent access, and severe compromise of the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7809,7 +7724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for possible installing a linux kernel module using modprobe utility function. This event can detect a installation of rootkit or malicious kernel module to gain elevated privileges to their malicious code and bypassed detections. This Anomaly detection is a good indicator that someone installing kernel module in a linux host either admin or adversaries. filter is needed in this scenario +explanation = The following analytic detects the installation of a Linux kernel module using the modprobe utility. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because installing a kernel module can indicate an attempt to deploy a rootkit or other malicious kernel-level code, potentially leading to elevated privileges and bypassing security detections. If confirmed malicious, this could allow an attacker to gain persistent, high-level access to the system, compromising its integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7819,7 +7734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious commandline that modify the iptables firewall setting of a linux machine. This technique was seen in cyclopsblink malware where it modifies the firewall setting of the compromised machine to allow traffic to its tcp port that will be used to communicate with its C2 server. +explanation = The following analytic detects suspicious command-line activity that modifies the iptables firewall settings on a Linux machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command patterns that alter firewall rules to accept traffic on certain TCP ports. This activity is significant as it can indicate malware, such as CyclopsBlink, modifying firewall settings to allow communication with a Command and Control (C2) server. If confirmed malicious, this could enable attackers to maintain persistent access and exfiltrate data, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]} known_false_positives = administrator may do this commandline for auditing and testing purposes. In this scenario filter is needed. @@ -7829,7 +7744,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the process name of Java, Apache, or Tomcat spawning a Linux shell. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell). The shells included in the macro are "sh", "ksh", "zsh", "bash", "dash", "rbash", "fish", "csh', "tcsh', "ion", "eshell". Upon triage, review parallel processes and command-line arguments to determine legitimacy. +explanation = The following analytic detects instances where Java, Apache, or Tomcat processes spawn a Linux shell, which may indicate exploitation attempts, such as those related to CVE-2021-44228 (Log4Shell). This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and parent-child process relationships. This activity is significant as it can signify a compromised Java application, potentially leading to unauthorized shell access. If confirmed malicious, attackers could execute arbitrary commands, escalate privileges, or maintain persistent access, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on asset type. @@ -7849,7 +7764,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious process kworker commandline in a linux machine. kworker process name or thread are common names of kernel threads in linux process. This hunting detections can lead to investigate process contains process path in writable directory in linux like /home/, /var/log and /tmp/. This technique was seen in cyclopsblink malware to blend its core and other of its child process as normal kworker on the compromised machine. This detection might be a good pivot to look for other IOC related to cyclopsblink malware or attacks. +explanation = The following analytic detects the execution of a kworker process with a command line in writable directories such as /home/, /var/log, and /tmp on a Linux machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process paths. This activity is significant as kworker processes are typically kernel threads, and their presence in writable directories is unusual and indicative of potential malware, such as CyclopsBlink. If confirmed malicious, this could allow attackers to blend malicious processes with legitimate ones, leading to persistent access and further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.004", "T1036"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -7859,7 +7774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The Linux make command is used to build and maintain groups of programs and files from the source code. In Linux, it is one of the most frequently used commands by the developers. It assists developers to install and compile many utilities from the terminal. If sudo right is given to make utility for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the use of the 'make' command with elevated privileges to execute system commands as root, potentially leading to a root shell. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include 'make', '--eval', and 'sudo'. This activity is significant because it indicates a possible privilege escalation attempt, allowing a user to gain root access. If confirmed malicious, an attacker could achieve full control over the system, execute arbitrary commands, and compromise the entire environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7869,7 +7784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = MySQL is an open-source relational database management system. Its name is a combination of "My", the name of co-founder Michael Widenius's daughter My, and "SQL", the abbreviation for Structured Query Language. If sudo right is given to mysql utility for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of MySQL commands with elevated privileges using sudo, which can lead to privilege escalation. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it indicates a potential misuse of MySQL to execute system commands as root, which could allow an attacker to gain root shell access. If confirmed malicious, this could result in full control over the affected system, leading to severe security breaches and unauthorized access to sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -7879,7 +7794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Ngrok being utilized on the Linux operating system. Unfortunately, there is no original file name for Ngrok, so it may be worth an additional hunt to identify any command-line arguments. The sign of someone using Ngrok is not malicious, however, more recently it has become an adversary tool. +explanation = The following analytic detects the use of Ngrok on a Linux operating system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments associated with Ngrok. This activity is significant because Ngrok can be used by adversaries to establish reverse proxies, potentially bypassing network defenses. If confirmed malicious, this could allow attackers to create persistent, unauthorized access channels, facilitating data exfiltration or further exploitation of the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if Ngrok is an authorized utility. Filter as needed. @@ -7889,7 +7804,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Node.js is a back-end JavaScript runtime environment that is open-source, cross-platform, runs on the V8 engine, and executes JavaScript code outside of a web browser. It was created to help create scalable network applications. If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. +explanation = The following analytic identifies the execution of Node.js with elevated privileges using sudo, specifically when spawning child processes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include specific Node.js commands. This activity is significant because running Node.js as a superuser without dropping privileges can allow unauthorized access to the file system and potential privilege escalation. If confirmed malicious, this could enable an attacker to maintain privileged access, execute arbitrary code, and compromise sensitive data within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -7899,7 +7814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious command lines that may add entry to /etc/sudoers with NOPASSWD attribute in linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to gain elevated privilege to the targeted or compromised host. /etc/sudoers file controls who can run what commands users can execute on the machines and can also control whether user need a password to execute particular commands. This file is composed of aliases (basically variables) and user specifications. +explanation = The following analytic detects the addition of NOPASSWD entries to the /etc/sudoers file on Linux systems. It leverages Endpoint Detection and Response (EDR) telemetry to identify command lines containing "NOPASSWD:". This activity is significant because it allows users to execute commands with elevated privileges without requiring a password, which can be exploited by adversaries to maintain persistent, privileged access. If confirmed malicious, this could lead to unauthorized privilege escalation, persistent access, and potential compromise of sensitive data and system integrity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7919,7 +7834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = GNU Octave is a high-level programming language primarily intended for scientific computing and numerical computation. Octave helps in solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with MATLAB. If sudo right is given to the application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of GNU Octave with elevated privileges, specifically when it runs system commands via sudo. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments that include "octave-cli," "--eval," "system," and "sudo." This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute commands as root. If confirmed malicious, this could lead to full system compromise, enabling an attacker to gain root access and execute arbitrary commands, severely impacting system security and integrity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7929,7 +7844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It implements both client and server applications. If sudo right is given to the OpenVPN application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of OpenVPN with elevated privileges, specifically when combined with the `--dev`, `--script-security`, `--up`, and `sudo` options. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments and execution details. This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute system commands as root. If confirmed malicious, this could lead to full system compromise, enabling an attacker to gain root access and execute arbitrary commands with elevated privileges. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7939,7 +7854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following correlation is specific to Linux persistence and privilege escalation tactics and is tied to two analytic stories and any Linux analytic tied to persistence and privilege escalation. These techniques often overlap with Persistence techniques, as OS features that let an adversary persist can execute in an elevated context. +explanation = The following analytic identifies potential Linux persistence and privilege escalation activities. It leverages risk scores and event counts from various Linux-related data sources, focusing on tactics associated with persistence and privilege escalation. This activity is significant for a SOC because it highlights behaviors that could allow an attacker to maintain access or gain elevated privileges on a Linux system. If confirmed malicious, this activity could enable an attacker to execute code with higher privileges, persist in the environment, and potentially access sensitive information, posing a severe security risk. how_to_implement = Ensure Linux anomaly and TTP analytics are enabled. TTP may be set to Notables for point detections, anomaly should not be notables but risk generators. The correlation relies on more than x amount of distict detection names generated before generating a notable. Modify the value as needed. Default value is set to 4. This value may need to be increased based on activity in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers. @@ -7949,7 +7864,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = PHP is a general-purpose scripting language geared toward web development. It was originally created by Danish-Canadian programmer Rasmus Lerdorf in 1994. The PHP reference implementation is now produced by The PHP Group. If sudo right is given to php application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of PHP commands with elevated privileges on a Linux system. It identifies instances where PHP is used in conjunction with 'sudo' and 'system' commands, indicating an attempt to run system commands as the root user. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments. This activity is significant because it can indicate an attempt to escalate privileges, potentially leading to full root access. If confirmed malicious, this could allow an attacker to execute arbitrary commands with root privileges, compromising the entire system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -7959,7 +7874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `pkexec` spawning with no command-line arguments. A vulnerability in Polkit's pkexec component identified as CVE-2021-4034 (PwnKit) which is present in the default configuration of all major Linux distributions and can be exploited to gain full root privileges on the system. +explanation = The following analytic detects the execution of `pkexec` without any command-line arguments. This behavior leverages data from Endpoint Detection and Response (EDR) agents, focusing on process telemetry. The significance lies in the fact that this pattern is associated with the exploitation of CVE-2021-4034 (PwnKit), a critical vulnerability in Polkit's pkexec component. If confirmed malicious, this activity could allow an attacker to gain full root privileges on the affected Linux system, leading to complete system compromise and potential unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter as needed. @@ -7969,7 +7884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious process command-line that might be accessing or modifying sshd_config. This file is the ssh configuration file that might be modify by threat actors or adversaries to redirect port connection, allow user using authorized key generated during attack. This anomaly detection might catch noise from administrator auditing or modifying ssh configuration file. In this scenario filter is needed +explanation = The following analytic detects suspicious access or modification of the sshd_config file on Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving processes like "cat," "nano," "vim," and "vi" accessing the sshd_config file. This activity is significant because unauthorized changes to sshd_config can allow threat actors to redirect port connections or use unauthorized keys, potentially compromising the system. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or persistent backdoor access, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.004", "T1098"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -7979,7 +7894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a possible attempt to dump or access the content of /etc/passwd and /etc/shadow to enable offline credential cracking. "etc/passwd" store user information within linux OS while "etc/shadow" contain the user passwords hash. Adversaries and threat actors may attempt to access this to gain persistence and/or privilege escalation. This anomaly detection can be a good indicator of possible credential dumping technique but it might catch some normal administrator automation scripts or during credential auditing. In this scenario filter is needed. +explanation = The following analytic detects attempts to access or dump the contents of /etc/passwd and /etc/shadow files on Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes like 'cat', 'nano', 'vim', and 'vi' accessing these files. This activity is significant as it may indicate credential dumping, a technique used by adversaries to gain persistence or escalate privileges. If confirmed malicious, attackers could obtain hashed passwords for offline cracking, leading to unauthorized access and potential system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.008", "T1003"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7989,7 +7904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a possible access or modification of /etc/sudoers file. "/etc/sudoers" file controls who can run what command as what users on what machine and can also control whether a specific user need a password for particular commands. adversaries and threat actors abuse this file to gain persistence and/or privilege escalation during attack on targeted host. +explanation = The following analytic detects potential access or modification of the /etc/sudoers file on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes like "cat," "nano," "vim," and "vi" accessing the /etc/sudoers file. This activity is significant because the sudoers file controls user permissions for executing commands with elevated privileges. If confirmed malicious, an attacker could gain persistence or escalate privileges, compromising the security of the targeted host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -7999,8 +7914,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to identify suspicious command lines that may append user entries to either /etc/at.allow or /etc/at.deny. These files can be exploited by malicious actors for persistence on a compromised Linux host by altering permissions for scheduled tasks using the at command. \ -In this context, an attacker can create a user or add an existing user to these configuration files to execute their malicious code through scheduled tasks. The detection of such anomalous behavior can serve as an effective indicator warranting further investigation to validate if the activity is indeed malicious or a false positive. +explanation = The following analytic detects suspicious command lines that append user entries to /etc/at.allow or /etc/at.deny files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving these files. This activity is significant because altering these configuration files can allow attackers to schedule tasks with elevated permissions, facilitating persistence on a compromised Linux host. If confirmed malicious, this could enable attackers to execute arbitrary code at scheduled intervals, potentially leading to further system compromise and unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.002", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -8010,7 +7924,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious command-lines that can be possibly used to modify user profile files to automatically execute scripts/executables by shell upon reboot of the machine. This technique is commonly abused by adversaries, malware and red teamers as persistence mechanism to the targeted or compromised host. This Anomaly detection is a good indicator that someone wants to run code after reboot which can be done also by the administrator or network operator for automation purposes. +explanation = The following analytic detects suspicious command-lines that modify user profile files to automatically execute scripts or executables upon system reboot. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving profile files like ~/.bashrc and /etc/profile. This activity is significant as it indicates potential persistence mechanisms used by adversaries to maintain access to compromised hosts. If confirmed malicious, this could allow attackers to execute arbitrary code upon reboot, leading to persistent control over the system and potential further exploitation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.004", "T1546"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -8020,9 +7934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect potential tampering with cronjob files on a Linux system. It specifically searches for command lines that may be used to append code to existing cronjob files, a technique often employed by adversaries, malware, and red teamers for persistence or privilege escalation. Altering existing or sometimes normal cronjob script files allows malicious code to be executed automatically. \ -The analytic operates by monitoring logs for specific process names, parent processes, and command-line executions from your endpoints. It specifically checks for any 'echo' command which modifies files in directories commonly associated with cron jobs such as '/etc/cron*', '/var/spool/cron/', and '/etc/anacrontab'. If such activity is detected, an alert is triggered. \ -This behavior is worth identifying for a SOC because malicious cron jobs can lead to system compromises and unauthorized data access, impacting business operations and data integrity. +explanation = The following analytic detects potential tampering with cronjob files on a Linux system by identifying 'echo' commands that append code to existing cronjob files. It leverages logs from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This activity is significant because adversaries often use it for persistence or privilege escalation. If confirmed malicious, this could allow attackers to execute unauthorized code automatically, leading to system compromises and unauthorized data access, thereby impacting business operations and data integrity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = False positives may arise from legitimate actions by administrators or network operators who may use these commands for automation purposes. Therefore, it's recommended to adjust filter macros to eliminate such false positives. @@ -8032,10 +7944,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects potential unauthorized modifications to Linux cronjobs using text editors like "nano", "vi" or "vim". It identifies this behavior by tracking command-line executions that interact with paths related to cronjob configuration, a common Linux scheduling utility. Cronjob files may be manipulated by attackers for privilege escalation or persistent access, making such changes critical to monitor.\ The identified behavior is significant for a Security Operations Center (SOC) as it could indicate an ongoing attempt at establishing persistent access or privilege escalation, leading to data breaches, system compromise, or other malicious activities. \ -In case of a true positive, the impact could be severe. An attacker with escalated privileges or persistent access could carry out damaging actions, such as data theft, sabotage, or further network penetration. \ -To implement this analytic, ensure ingestion of logs tracking process name, parent process, and command-line executions from your endpoints. Utilize the Add-on for Linux Sysmon from Splunkbase if you're using Sysmon. \ -Known false positives include legitimate administrative tasks, as these commands may also be used for benign purposes. Careful tuning and filtering based on known benign activity in your environment can minimize these instances. +explanation = The following analytic detects potential unauthorized modifications to Linux cronjobs using text editors like "nano," "vi," or "vim." It identifies this activity by monitoring command-line executions that interact with cronjob configuration paths. This behavior is significant for a SOC as it may indicate attempts at privilege escalation or establishing persistent access. If confirmed malicious, the impact could be severe, allowing attackers to execute damaging actions such as data theft, system sabotage, or further network penetration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -8045,7 +7954,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for possible ssh key file creation on ~/.ssh/ folder. This technique is commonly abused by threat actors and adversaries to gain persistence and privilege escalation to the targeted host. by creating ssh private and public key and passing the public key to the attacker server. threat actor can access remotely the machine using openssh daemon service. +explanation = The following analytic detects the creation of SSH key files in the ~/.ssh/ directory. It leverages filesystem data to identify new files in this specific path. This activity is significant because threat actors often create SSH keys to gain persistent access and escalate privileges on a compromised host. If confirmed malicious, this could allow attackers to remotely access the machine using the OpenSSH daemon service, leading to potential unauthorized control and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.004", "T1098"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can create file in ~/.ssh folders for automation purposes. Please update the filter macros to remove false positives. @@ -8055,7 +7964,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious command that may hijack a library function in linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to gain privileges and persist on the machine. This detection pertains to loading a dll to hijack or hook a library function of specific program using LD_PRELOAD command. +explanation = The following analytic detects the use of the LD_PRELOAD environment variable to hijack or hook library functions on a Linux platform. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because adversaries, malware authors, and red teamers commonly use this technique to gain elevated privileges and establish persistence on a compromised machine. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, and maintain long-term access to the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.006", "T1574"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8065,7 +7974,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies curl being utilized with a proxy based on command-line arguments - -x, socks, --preproxy and --proxy. This behavior is built into the MetaSploit Framework as a auxiliary module. What does socks buy an adversary? SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address. The SOCKS5 protocol is defined in RFC 1928. It is an incompatible extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups. The protocols, and a proxy itself, allow an adversary to evade controls in place monitoring traffic, making it harder for the defender to identify and track activity. +explanation = The following analytic detects the use of the `curl` command with proxy-related arguments such as `-x`, `socks`, `--preproxy`, and `--proxy`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it may indicate an adversary attempting to use a proxy to evade network monitoring and obscure their actions. If confirmed malicious, this behavior could allow attackers to bypass security controls, making it difficult to track their activities and potentially leading to unauthorized data access or exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090", "T1095"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on proxy usage internally. Filter as needed. @@ -8075,7 +7984,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = In computing, Puppet is a software configuration management tool which includes its own declarative language to describe system configuration. It is a model-driven solution that requires limited programming knowledge to use. If sudo right is given to the tool for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of Puppet commands with elevated privileges, specifically when Puppet is used to apply configurations with sudo rights. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it indicates a potential privilege escalation attempt, where a user could gain root access and execute system commands as the root user. If confirmed malicious, this could allow an attacker to fully compromise the system, execute arbitrary commands, and maintain persistent control. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -8085,7 +7994,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = RPM Package Manager is a free and open-source package management system. The name RPM refers to the .rpm file format and the package manager program itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base. If sudo right is given to rpm utility for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the RPM Package Manager with elevated privileges, specifically when it is used to run system commands as root via the `--eval` and `lua:os.execute` options. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to gain root access. If confirmed malicious, this could lead to full system compromise, unauthorized access to sensitive data, and further exploitation of the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -8095,7 +8004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Ruby is one of the most used and easy to use programming languages. Ruby is an open-source, object-oriented interpreter that can be installed on a Linux system. If sudo right is given to ruby application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of Ruby commands with elevated privileges on a Linux system. It identifies processes where Ruby is used with the `-e` flag to execute commands via `sudo`, leveraging Endpoint Detection and Response (EDR) telemetry. This activity is significant because it indicates a potential privilege escalation attempt, allowing a user to execute commands as root. If confirmed malicious, this could lead to full system compromise, enabling an attacker to gain root access, execute arbitrary commands, and maintain persistent control over the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed. @@ -8105,8 +8014,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect suspicious file creation within the systemd timer directory on Linux platforms. Systemd is a system and service manager for Linux, similar to the combination of wininit.exe and services.exe on Windows. This process initializes a Linux system and starts defined services in unit files. Malicious actors, such as adversaries, malware, or red teamers, can exploit this feature by embedding a systemd service file for persistence on the targeted or compromised host. \ -The analytic works by monitoring logs with file name, file path, and process GUID data from your endpoints. If a .service file is created in certain systemd directories, the analytic triggers an alert. This behavior is significant for a Security Operations Center (SOC) as it may indicate a persistent threat within the network, with a potential impact of system compromise or data exfiltration. +explanation = The following analytic detects the creation of suspicious service files within the systemd directories on Linux platforms. It leverages logs containing file name, file path, and process GUID data from endpoints. This activity is significant for a SOC as it may indicate an adversary attempting to establish persistence on a compromised host. If confirmed malicious, this could lead to system compromise or data exfiltration, allowing attackers to maintain control over the system and execute further malicious activities. how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]} known_false_positives = False positives may arise when administrators or network operators create files in systemd directories for legitimate automation tasks. Therefore, it's important to adjust filter macros to account for valid activities. To implement this search successfully, it's crucial to ingest appropriate logs, preferably using the Linux Sysmon Add-on from Splunkbase for those using Sysmon. @@ -8116,9 +8024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the restarting or re-enabling of services in the Linux platform. It focuses on the use of the systemctl or service tools for executing these actions. Adversaries may leverage this technique to repeatedly execute malicious payloads as a form of persistence. Linux hosts typically start services during boot to perform background system functions. However, administrators may also create legitimate services for specific tools or applications as part of task automation. In such cases, it is recommended to verify the service path of the registered script or executable and identify the creator of the service for further validation. \ -It's important to be aware that this analytic may generate false positives as administrators or network operators may use the same command-line for legitimate automation purposes. Filter macros should be updated accordingly to minimize false positives. \ -Identifying restarted or re-enabled services is valuable for a SOC as it can indicate potential malicious activities attempting to maintain persistence or execute unauthorized actions on Linux systems. By detecting and investigating these events, security analysts can respond promptly to mitigate risks and prevent further compromise. The impact of a true positive can range from unauthorized access to data destruction or other damaging outcomes. +explanation = The following analytic detects the restarting or re-enabling of services on Linux systems using the `systemctl` or `service` commands. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. This activity is significant as adversaries may use it to maintain persistence or execute unauthorized actions. If confirmed malicious, this behavior could lead to repeated execution of malicious payloads, unauthorized access, or data destruction. Security analysts should investigate these events to mitigate risks and prevent further compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -8128,7 +8034,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation or enabling of services in Linux platforms, specifically using the systemctl or service tool application. This behavior is worth identifying as adversaries may create or modify services to execute malicious payloads as part of persistence. Legitimate services created by administrators for automation purposes may also trigger this analytic, so it is important to update the filter macros to remove false positives. If a true positive is found, it suggests an possible attacker is attempting to persist within the environment or deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, ensure you are ingesting logs with the process name, parent process, and command-line executions from your endpoints. +explanation = The following analytic detects the creation or enabling of services on Linux platforms using the systemctl or service tools. It leverages Endpoint Detection and Response (EDR) logs, focusing on process names, parent processes, and command-line executions. This activity is significant as adversaries may create or modify services to maintain persistence or execute malicious payloads. If confirmed malicious, this behavior could lead to persistent access, data theft, ransomware deployment, or other damaging outcomes. Monitoring and investigating such activities are crucial for maintaining the security and integrity of the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives. @@ -8138,7 +8044,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious chmod utility execution to enable SUID bit. This allows a user to temporarily gain root access, usually in order to run a program. For example, only the root account is allowed to change the password information contained in the password database; If the SUID bit appears as an s, the file's owner also has execute permission to the file; if it appears as an S, the file's owner does not have execute permission. The second specialty permission is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily change group membership, usually to execute a program. The SGID bit is set if an s or an S appears in the group section of permissions. +explanation = The following analytic detects the execution of the chmod utility to set the SUID or SGID bit on files, which can allow users to temporarily gain root or group-level access. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments related to chmod. This activity is significant as it can indicate an attempt to escalate privileges or maintain persistence on a system. If confirmed malicious, an attacker could gain elevated access, potentially compromising sensitive data or critical system functions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8148,7 +8054,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious setcap utility execution to enable SUID bit. This allows a user to temporarily gain root access, usually in order to run a program. For example, only the root account is allowed to change the password information contained in the password database; If the SUID bit appears as an s, the file's owner also has execute permission to the file; if it appears as an S, the file's owner does not have execute permission. The second specialty permission is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily change group membership, usually to execute a program. The SGID bit is set if an s or an S appears in the group section of permissions. +explanation = The following analytic detects the execution of the 'setcap' utility to enable the SUID bit on Linux systems. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments that indicate the use of 'setcap' with specific capabilities. This activity is significant because setting the SUID bit allows a user to temporarily gain root access, posing a substantial security risk. If confirmed malicious, an attacker could escalate privileges, execute arbitrary commands with elevated permissions, and potentially compromise the entire system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8158,7 +8064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a shred process to overwrite a files in a linux machine. Shred Linux application is designed to overwrite file to hide its contents or make the deleted file un-recoverable. Weve seen this technique in industroyer2 malware that tries to wipe energy facilities of targeted sector as part of its destructive attack. It might be some normal user may use this command for valid purposes but it is recommended to check what files, disk or folder it tries to shred that might be good pivot for incident response in this type of destructive malware. +explanation = The following analytic detects the execution of the 'shred' command on a Linux machine, which is used to overwrite files to make them unrecoverable. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because the 'shred' command can be used in destructive attacks, such as those seen in the Industroyer2 malware targeting energy facilities. If confirmed malicious, this activity could lead to the permanent destruction of critical files, severely impacting system integrity and data availability. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -8168,7 +8074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = sqlite3 is a terminal-based front-end to the SQLite library that can evaluate queries interactively and display the results in multiple formats. sqlite3 can also be used within shell scripts and other applications to provide batch processing features. If sudo right is given to this application for the user, then the user can run system commands as root and possibly get a root shell. +explanation = The following analytic detects the execution of the sqlite3 command with elevated privileges, which can be exploited for privilege escalation. It leverages Endpoint Detection and Response (EDR) telemetry to identify instances where sqlite3 is used in conjunction with shell commands and sudo. This activity is significant because it indicates a potential attempt to gain root access, which could lead to full system compromise. If confirmed malicious, an attacker could execute arbitrary commands as root, leading to unauthorized access, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filter as needed. @@ -8198,7 +8104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for suspicious commandline that redirect the stdout or possible stderror to dev/null file. This technique was seen in cyclopsblink malware where it redirect the possible output or error while modify the iptables firewall setting of the compromised machine to hide its action from the user. This Anomaly detection is a good pivot to look further why process or user use this un common approach. +explanation = The following analytic detects command-line activities that redirect stdout or stderr to the /dev/null file. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This behavior is significant as it can indicate attempts to hide command outputs, a technique observed in the CyclopsBlink malware to conceal modifications to iptables firewall settings. If confirmed malicious, this activity could allow an attacker to stealthily alter system configurations, potentially leading to unauthorized access or persistent control over the compromised machine. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -8208,7 +8114,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to detect events that attempt to stop or clear a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 malware to terminate security services or other related services to continue there objective as a destructive payload. +explanation = The following analytic detects attempts to stop or clear a service on Linux systems. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes like "systemctl," "service," and "svcadm" executing stop commands. This activity is significant as adversaries often terminate security or critical services to disable defenses or disrupt operations, as seen in malware like Industroyer2. If confirmed malicious, this could lead to the disabling of security mechanisms, allowing attackers to persist, escalate privileges, or deploy destructive payloads, severely impacting system integrity and availability. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]} known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives. @@ -8218,7 +8124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect the execution of sudo or su command in linux operating system. The "sudo" command allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments. This command is commonly abused by adversaries, malware author and red teamers to elevate privileges to the targeted host. This command can be executed by administrator for legitimate purposes or to execute process that need admin privileges, In this scenario filter is needed. +explanation = The following analytic detects the execution of the "sudo" or "su" command on a Linux operating system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent process names. This activity is significant because "sudo" and "su" commands are commonly used by adversaries to elevate privileges, potentially leading to unauthorized access or control over the system. If confirmed malicious, this activity could allow attackers to execute commands with root privileges, leading to severe security breaches, data exfiltration, or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8228,7 +8134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to looks for file creation of sudoers.tmp file cause by editing /etc/sudoers using visudo or editor in linux platform. This technique may abuse by adversaries, malware author and red teamers to gain elevated privilege to targeted or compromised host. /etc/sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The file is composed of aliases (basically variables) and user specifications (which control who can run what). +explanation = The following analytic detects the creation of the "sudoers.tmp" file, which occurs when editing the /etc/sudoers file using visudo or another editor on a Linux platform. This detection leverages filesystem data to identify the presence of "sudoers.tmp" files. Monitoring this activity is crucial as adversaries may exploit it to gain elevated privileges on a compromised host. If confirmed malicious, this activity could allow attackers to modify sudoers configurations, potentially granting them unauthorized access to execute commands as other users, including root, thereby compromising the system's security. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8238,7 +8144,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for possible enumeration of local network configuration. This technique is commonly used as part of recon of adversaries or threat actor to know some network information for its next or further attack. This anomaly detections may capture normal event made by administrator during auditing or testing network connection of specific host or network to network. +explanation = The following analytic identifies potential enumeration of local network configuration on Linux systems. It detects this activity by monitoring processes such as "arp," "ifconfig," "ip," "netstat," "firewall-cmd," "ufw," "iptables," "ss," and "route" within a 30-minute window. This behavior is significant as it often indicates reconnaissance efforts by adversaries to gather network information for subsequent attacks. If confirmed malicious, this activity could enable attackers to map the network, identify vulnerabilities, and plan further exploitation or lateral movement within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8248,7 +8154,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for possible execution of SysReq hack to reboot the Linux system host. This technique was seen in Awfulshred malware wiper to reboot the compromised host by using the linux magic sysreq key. This kernel configuration can trigger reboot by piping out 'b' to /proc/sysrq-trigger after enabling all the functions of sysrq. This TTP detection can be a good indicator of possible suspicious processes running on the Linux host since this command is not a common way to reboot a system. +explanation = The following analytic detects the execution of the SysReq hack to reboot a Linux system host. It leverages Endpoint Detection and Response (EDR) data to identify processes executing the command to pipe 'b' to /proc/sysrq-trigger. This activity is significant as it is an uncommon method to reboot a system and was observed in the Awfulshred malware wiper. If confirmed malicious, this technique could indicate the presence of suspicious processes and potential system compromise, leading to unauthorized reboots and disruption of services. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -8258,7 +8164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for possible execution of SysReq hack to enable all functions of kernel system requests of the Linux system host. This technique was seen in AwfulShred malware wiper to reboot the compromised host by using the linux magic sysreq key. This kernel configuration can be triggered by piping out bitmask '1' to /proc/sys/kernel/sysrq. This TTP detection can be a good indicator of possible suspicious processes running on the Linux host since this command is not so common shell commandline. +explanation = The following analytic detects the execution of a command to enable all SysRq functions on a Linux system, a technique associated with the AwfulShred malware. It leverages Endpoint Detection and Response (EDR) data to identify processes executing the command to pipe bitmask '1' to /proc/sys/kernel/sysrq. This activity is significant as it can indicate an attempt to manipulate kernel system requests, which is uncommon and potentially malicious. If confirmed, this could allow an attacker to reboot the system or perform other critical actions, leading to system instability or further compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.004", "T1059"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -8268,7 +8174,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to looks for suspicious commandline that add entry to /etc/sudoers by using visudo utility tool in linux platform. This technique may abuse by adversaries, malware author and red teamers to gain elevated privilege to targeted or compromised host. /etc/sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The file is composed of aliases (basically variables) and user specifications (which control who can run what). +explanation = The following analytic detects the execution of the 'visudo' utility to modify the /etc/sudoers file on a Linux system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because unauthorized changes to the /etc/sudoers file can grant elevated privileges to users, potentially allowing adversaries to execute commands as root. If confirmed malicious, this could lead to full system compromise, privilege escalation, and persistent unauthorized access, severely impacting the security posture of the affected host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives. @@ -8288,7 +8194,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = DynamicWrapperX is an ActiveX component that can be used in a script to call Windows API functions, but it requires the dynwrapx.dll to be installed and registered. With that, registering or loading dynwrapx.dll to a host is highly suspicious. In most instances when it is used maliciously, the best way to triage is to review parallel processes and pivot on the process_guid. Review the registry for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious module loads of dynwrapx.dll. This detection will return and identify the processes that invoke vbs/wscript/cscript. +explanation = The following analytic detects the loading of the dynwrapx.dll module, which is associated with the DynamicWrapperX ActiveX component. This detection leverages Sysmon EventCode 7 to identify processes that load or register dynwrapx.dll. This activity is significant because DynamicWrapperX can be used to call Windows API functions in scripts, making it a potential tool for malicious actions. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence on the host. Immediate investigation of parallel processes and registry modifications is recommended. how_to_implement = To successfully implement this search you need to be ingesting information on processes that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however it is possible to filter by Processes.process_name and specific processes (ex. wscript.exe). Filter as needed. This may need modification based on EDR telemetry and how it brings in registry data. For example, removal of (Default). @@ -8298,7 +8204,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for local users. The two arguments `user` and 'users', return a list of all local users. Red Teams and adversaries alike use net.exe to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments `user` or `users` to query local user accounts. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate local users, which is a common step in situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further attacks, including privilege escalation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -8308,7 +8214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for local users. The argument `useraccount` is used to leverage WMI to return a list of all local users. Red Teams and adversaries alike use net.exe to enumerate users for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `wmic.exe` with command-line arguments used to query local user accounts, specifically the `useraccount` argument. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate local users, which is a common step in situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further targeted attacks, privilege escalation, or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -8318,7 +8224,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This correlation find exploitation of Log4Shell CVE-2021-44228 against systems using detections from Splunk Security Content Analytic Story. It does this by calculating the distinct count of MITRE ATT&CK tactics from Log4Shell detections fired. If the count is larger than 2 or more distinct MITRE ATT&CK tactics we assume high problability of exploitation. The Analytic story breaks down into 3 major phases of a Log4Shell exploitation, specifically> Initial Payload delivery eg. `${jndi:ldap://PAYLOAD_INJECTED}` Call back to malicious LDAP server eg. Exploit.class Post Exploitation Activity/Lateral Movement using Powershell or similar T1562.001 Each of these phases fall into different MITRE ATT&CK Tactics (Initial Access, Execution, Command And Control), by looking into 2 or more phases showing up in detections triggerd is how this correlation search finds exploitation. If we get a notable from this correlation search the best way to triage it is by investigating the affected systems against Log4Shell exploitation using Splunk SOAR playbooks. +explanation = The following analytic identifies potential exploitation of Log4Shell CVE-2021-44228 by correlating multiple MITRE ATT&CK tactics detected in risk events. It leverages Splunk's risk data model to calculate the distinct count of MITRE ATT&CK tactics from Log4Shell-related detections. This activity is significant because it indicates a high probability of exploitation if two or more distinct tactics are observed. If confirmed malicious, this activity could lead to initial payload delivery, callback to a malicious server, and post-exploitation activities, potentially resulting in unauthorized access, lateral movement, and further compromise of the affected systems. how_to_implement = To implement this correlation search a user needs to enable all detections in the Log4Shell Analytic Story and confirm it is generation risk events. A simple search `index=risk analyticstories="Log4Shell CVE-2021-44228"` should contain events. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Delivery", "Installation"], "mitre_attack": ["T1105", "T1190", "T1059", "T1133"], "nist": ["DE.AE"]} known_false_positives = There are no known false positive for this search, but it could contain false positives as multiple detections can trigger and not have successful exploitation. @@ -8328,7 +8234,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious modification of registry entry to persist and gain privilege escalation upon booting up of compromised host. This technique was seen in several APT and malware where it modify UserInitMprLogonScript registry entry to its malicious payload to be executed upon boot up of the machine. +explanation = The following analytic detects the modification of the UserInitMprLogonScript registry entry, which is often used by attackers to establish persistence and gain privilege escalation upon system boot. It leverages data from the Endpoint.Registry data model, focusing on changes to the specified registry path. This activity is significant because it is a common technique used by APT groups and malware to ensure their payloads execute automatically when the system starts. If confirmed malicious, this could allow attackers to maintain persistent access and potentially escalate their privileges on the compromised host. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1037", "T1037.001"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -8338,7 +8244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies LOLBAS with network traffic. When adversaries abuse LOLBAS they are often used to download malicious code or executables. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like downloading malicious code. Looking for these process can help defenders identify lateral movement, command-and-control, or exfiltration activies. +explanation = The following analytic identifies the use of Living Off the Land Binaries and Scripts (LOLBAS) with network traffic. It leverages data from the Network Traffic data model to detect when native Windows binaries, often abused by adversaries, initiate network connections. This activity is significant as LOLBAS are frequently used to download malicious payloads, enabling lateral movement, command-and-control, or data exfiltration. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to organizational security. how_to_implement = To successfully implement this detection you must ingest events into the Network traffic data model that contain the source, destination, and communicating process in the app feild. Relevant processes must also be ingested in the Endpoint data model with matching process_id feild. Sysmon EID1 and EID3 are good examples of this type this data type. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives", "Command and Control", "Exploitation"], "mitre_attack": ["T1105", "T1567", "T1218"], "nist": ["DE.CM"]} known_false_positives = Legitmate usage of internal automation or scripting, espically powershell.exe internal to internal or logon scripts. It may be necessary to omit internal IP ranges if extremely noisy. ie NOT dest_ip IN ("10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","170.98.0.0/16","0:0:0:0:0:0:0:1") @@ -8388,7 +8294,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process modifying the registry with a known malicious CLSID under InProcServer32. Most COM classes are registered with the operating system and are identified by a GUID that represents the Class Identifier (CLSID) within the registry (usually under HKLM\\Software\\Classes\\CLSID or HKCU\\Software\\Classes\\CLSID). Behind the implementation of a COM class is the server (some binary) that is referenced within registry keys under the CLSID. The LocalServer32 key represents a path to an executable (exe) implementation, and the InprocServer32 key represents a path to a dynamic link library (DLL) implementation (Bohops). During triage, review parallel processes for suspicious activity. Pivot on the process GUID to see the full timeline of events. Analyze the value and look for file modifications. Being this is looking for inprocserver32, a DLL found in the value will most likely be loaded by a parallel process. +explanation = The following analytic detects a process modifying the registry with a known malicious CLSID under InProcServer32. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry modifications within the HKLM or HKCU Software Classes CLSID paths. This activity is significant as it may indicate an attempt to load a malicious DLL, potentially leading to code execution. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or escalate privileges, posing a severe threat to system integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.010", "T1112"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, filter as needed. In our test case, Remcos used regsvr32.exe to modify the registry. It may be required, dependent upon the EDR tool producing registry events, to remove (Default) from the command-line. @@ -8408,10 +8314,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of the EncodedCommand PowerShell parameter. This is typically used by Administrators to run complex scripts, but commonly used by adversaries to hide their code. \ -The analytic identifies all variations of EncodedCommand, as PowerShell allows the ability to shorten the parameter. For example enc, enco, encod and so forth. In addition, through our research it was identified that PowerShell will interpret different command switch types beyond the hyphen. We have added endash, emdash, horizontal bar, and forward slash. \ -During triage, review parallel events to determine legitimacy. Tune as needed based on admin scripts in use. \ -Alternatively, may use regex per matching here https://regexr.com/662ov. +explanation = The following analytic detects the use of the EncodedCommand parameter in PowerShell processes. It leverages Endpoint Detection and Response (EDR) data to identify variations of the EncodedCommand parameter, including shortened forms and different command switch types. This activity is significant because adversaries often use encoded commands to obfuscate malicious scripts, making detection harder. If confirmed malicious, this behavior could allow attackers to execute hidden code, potentially leading to unauthorized access, privilege escalation, or persistent threats within the environment. Review parallel events to determine legitimacy and tune based on known administrative scripts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.AE"]} known_false_positives = System administrators may use this option, but it's not common. @@ -8441,7 +8344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic looks for the use of Mimikatz command line parameters leveraged to execute pass the ticket attacks. Red teams and adversaries alike may use the pass the ticket technique using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Defenders should be aware that adversaries may customize the source code of Mimikatz and modify the command line parameters. This would effectively bypass this analytic. +explanation = The following analytic detects the use of Mimikatz command line parameters associated with pass-the-ticket attacks. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns related to Kerberos ticket manipulation. This activity is significant because pass-the-ticket attacks allow adversaries to move laterally within an environment using stolen Kerberos tickets, bypassing normal access controls. If confirmed malicious, this could enable attackers to escalate privileges, access sensitive information, and maintain persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003"], "nist": ["DE.CM"]} known_false_positives = Although highly unlikely, legitimate applications may use the same command line parameters as Mimikatz. @@ -8451,7 +8354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `mmc.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the DCOM protocol and the MMC20 COM object, the executed command is spawned as a child processs of `mmc.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of mmc.exe that are part of the LOLBAS project can help defenders identify lateral movement activity. +explanation = The following analytic identifies `mmc.exe` spawning a LOLBAS execution process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where `mmc.exe` is the parent process. This activity is significant because adversaries can abuse the DCOM protocol and MMC20 COM object to execute malicious code, using Windows native binaries documented by the LOLBAS project. If confirmed malicious, this behavior could indicate lateral movement, allowing attackers to execute code remotely, potentially leading to further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003", "T1218.014"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may trigger this behavior, filter as needed. @@ -8461,7 +8364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious modification of registry to deface or change the wallpaper of a compromised machines as part of its payload. This technique was commonly seen in ransomware like REVIL where it create a bitmap file contain a note that the machine was compromised and make it as a wallpaper. +explanation = The following analytic detects the modification of registry keys related to the desktop wallpaper settings. It leverages Sysmon EventCode 13 to identify changes to the "Control Panel\\Desktop\\Wallpaper" and "Control Panel\\Desktop\\WallpaperStyle" registry keys, especially when the modifying process is not explorer.exe or involves suspicious file paths like temp or public directories. This activity is significant as it can indicate ransomware behavior, such as the REVIL ransomware, which changes the wallpaper to display a ransom note. If confirmed malicious, this could signify a compromised machine and the presence of ransomware, leading to potential data encryption and extortion. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Image, TargetObject registry key, registry Details from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1491"], "nist": ["DE.CM"]} known_false_positives = 3rd party tool may used to changed the wallpaper of the machine @@ -8471,7 +8374,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious modification of ACL permission to a files or folder to make it available to everyone. This technique may be used by the adversary to evade ACLs or protected files access. This changes is commonly configured by the file or directory owner with appropriate permission. This behavior is a good indicator if this command seen on a machine utilized by an account with no permission to do so. +explanation = The following analytic detects the modification of ACL permissions to files or folders, making them accessible to everyone. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes like "cacls.exe," "icacls.exe," and "xcacls.exe" with specific command-line arguments. This activity is significant as it may indicate an adversary attempting to evade ACLs or access protected files. If confirmed malicious, this could allow unauthorized access to sensitive data, potentially leading to data breaches or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"]} known_false_positives = administrators may use this command. Filter as needed. @@ -8481,7 +8384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for registry activity associated with modifications to the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors`. In this scenario, an attacker can load an arbitrary .dll into the print-monitor registry by giving the full path name to the after.dll. The system will execute the .dll with elevated (SYSTEM) permissions and will persist after reboot. +explanation = The following analytic detects modifications to the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors`. It leverages data from the Endpoint.Registry data model, focusing on events where the registry path is modified. This activity is significant because attackers can exploit this registry key to load arbitrary .dll files, which will execute with elevated SYSTEM permissions and persist after a reboot. If confirmed malicious, this could allow attackers to maintain persistence, execute code with high privileges, and potentially compromise the entire system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.010", "T1547"], "nist": ["DE.CM"]} known_false_positives = You will encounter noise from legitimate print-monitor registry entries. @@ -8491,7 +8394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. The analytic is limited to process name MSExchangeMailboxReplication.exe, which typically does not write .aspx files to disk. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant. +explanation = The following analytic identifies the creation of suspicious .aspx files in specific directories associated with Exchange exploitation by the HAFNIUM group and the ProxyShell vulnerability. It detects this activity by monitoring the MSExchangeMailboxReplication.exe process, which typically does not write .aspx files. This behavior is significant as it may indicate an active exploitation attempt on Exchange servers. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, or maintain persistence within the environment. Immediate investigation and remediation are crucial to prevent further compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. @@ -8501,7 +8404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious MS scripting process such as wscript.exe or cscript.exe that loading ldap module to process ldap query. This behavior was seen in FIN7 implant where it uses javascript to execute ldap query to parse host information that will send to its C2 server. this anomaly detections is a good initial step to hunt further a suspicious ldap query or ldap related events to the host that may give you good information regarding ldap or AD information processing or might be a attacker. +explanation = The following analytic detects the execution of MS scripting processes (wscript.exe or cscript.exe) loading LDAP-related modules (Wldap32.dll, adsldp.dll, adsldpc.dll). It leverages Sysmon EventCode 7 to identify these specific DLL loads. This activity is significant as it may indicate an attempt to query LDAP for host information, a behavior observed in FIN7 implants. If confirmed malicious, this could allow attackers to gather detailed Active Directory information, potentially leading to further exploitation or data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.AE"]} known_false_positives = automation scripting language may used by network operator to do ldap query. @@ -8511,7 +8414,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious MS scripting process such as wscript.exe or cscript.exe that loading wmi module to process wmi query. This behavior was seen in FIN7 implant where it uses javascript to execute wmi query to parse host information that will send to its C2 server. this anomaly detections is a good initial step to hunt further a suspicious wmi query or wmi related events to the host that may give you good information regarding process that are commonly using wmi query or modules or might be an attacker using this technique. +explanation = The following analytic detects the loading of WMI modules by Microsoft scripting processes like wscript.exe or cscript.exe. It leverages Sysmon EventCode 7 to identify instances where these scripting engines load specific WMI-related DLLs. This activity is significant because it can indicate the presence of malware, such as the FIN7 implant, which uses JavaScript to execute WMI queries for gathering host information to send to a C2 server. If confirmed malicious, this behavior could allow attackers to collect sensitive system information and maintain persistence within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.AE"]} known_false_positives = automation scripting language may used by network operator to do ldap query. @@ -8521,7 +8424,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious child process of MSBuild spawned by Windows Script Host - cscript or wscript. This behavior or event are commonly seen and used by malware or adversaries to execute malicious msbuild process using malicious script in the compromised host. During triage, review parallel processes and identify any file modifications. MSBuild may load a script from the same path without having command-line arguments. +explanation = The following analytic detects the suspicious spawning of MSBuild.exe by Windows Script Host processes (cscript.exe or wscript.exe). This behavior is often associated with malware or adversaries executing malicious MSBuild processes via scripts on compromised hosts. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where MSBuild is a child of script hosts. This activity is significant as it may indicate an attempt to execute malicious code. If confirmed malicious, it could lead to unauthorized code execution, potentially compromising the host and allowing further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1127.001", "T1127"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as developers do not spawn MSBuild via a WSH. @@ -8531,7 +8434,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious mshta.exe process that spawn rundll32 or regsvr32 child process. This technique was seen in several malware nowadays like trickbot to load its initial .dll stage loader to execute and download the the actual trickbot payload. +explanation = The following analytic detects a suspicious mshta.exe process spawning rundll32 or regsvr32 child processes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process GUID, process name, and parent process fields. This activity is significant as it is a known technique used by malware like Trickbot to load malicious DLLs and execute payloads. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or download additional malware, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} known_false_positives = limitted. this anomaly behavior is not commonly seen in clean host. @@ -8541,7 +8444,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection identifies the loading of the mshtml.dll module into an Office product. This behavior is associated with CVE-2021-40444, where a malicious document loads ActiveX, thereby activating the MSHTML component. The vulnerability is found within the MSHTML component itself. During triage, it is important to identify concurrent processes and document any file modifications for further analysis. +explanation = The following analytic detects the loading of the mshtml.dll module into an Office product, which is indicative of CVE-2021-40444 exploitation. It leverages Sysmon EventID 7 to monitor image loads by specific Office processes. This activity is significant because it can indicate an attempt to exploit a vulnerability in the MSHTML component via a malicious document. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further network penetration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process names and image loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = Limited false positives will be present, however, tune as necessary. Some applications may legitimately load mshtml.dll. @@ -8551,13 +8454,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies `msi.dll` being loaded by a binary not located in `system32`, `syswow64`, `winsxs` or `windows` paths. This behavior is most recently related to InstallerFileTakeOver, or CVE-2021-41379, and DLL side-loading. CVE-2021-41379 requires a binary to be dropped and `msi.dll` to be loaded by it. To Successful exploitation of this issue happens in four parts \ - \ -1. Generation of an MSI that will trigger bad behavior. \ -1. Preparing a directory for MSI installation. \ -1. Inducing an error state. \ -1. Racing to introduce a junction and a symlink to trick msiexec.exe to modify the attacker specified file. \ -In addition, `msi.dll` has been abused in DLL side-loading attacks by being loaded by non-system binaries. +explanation = The following analytic detects the loading of `msi.dll` by a binary not located in `system32`, `syswow64`, `winsxs`, or `windows` directories. This is identified using Sysmon EventCode 7, which logs DLL loads, and filters out legitimate system paths. This activity is significant as it may indicate exploitation of CVE-2021-41379 or DLL side-loading attacks, both of which can lead to unauthorized system modifications. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]} known_false_positives = It is possible some Administrative utilities will load msi.dll outside of normal system paths, filter as needed. @@ -8567,7 +8464,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious creation of msmpeng.exe or mpsvc.dll in non default windows defender folder. This technique was seen with revil ransomware in Kaseya Supply chain. The approach is to drop an old version of msmpeng.exe to load the actual payload name as mspvc.dll which will load the revil ransomware to the compromise machine +explanation = The following analytic detects the suspicious creation of msmpeng.exe or mpsvc.dll in non-default Windows Defender folders. It leverages the Endpoint.Filesystem datamodel to identify instances where these files are created outside their expected directories. This activity is significant because it is associated with the REvil ransomware, which uses DLL side-loading to execute malicious payloads. If confirmed malicious, this could lead to ransomware deployment, resulting in data encryption, system compromise, and potential data loss or extortion. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]} known_false_positives = quite minimal false positive expected. @@ -8587,7 +8484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect modification of registry to bypass UAC windows feature. This technique is to add a payload dll path on .NET COR file path that will be loaded by mmc.exe as soon it was executed. This detection rely on monitoring the registry key and values in the detection area. It may happened that windows update some dll related to mmc.exe and add dll path in this registry. In this case filtering is needed. +explanation = The following analytic detects modifications to the registry aimed at bypassing the User Account Control (UAC) feature in Windows. It identifies changes to the .NET COR_PROFILER_PATH registry key, which can be exploited to load a malicious DLL via mmc.exe. This detection leverages data from the Endpoint.Registry datamodel, focusing on specific registry paths and values. Monitoring this activity is crucial as it can indicate an attempt to escalate privileges or persist within the environment. If confirmed malicious, this could allow an attacker to execute arbitrary code with elevated privileges, compromising system integrity. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = limited false positive. It may trigger by some windows update that will modify this registry. @@ -8607,7 +8504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` with command-line arguments utilized to get a listing of network connections on a compromised system. Red Teams and adversaries alike may use net.exe for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `net.exe` or `net1.exe` with command-line arguments used to list network connections on a compromised system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential network reconnaissance by adversaries or Red Teams, aiming to gather situational awareness and Active Directory information. If confirmed malicious, this behavior could allow attackers to map the network, identify critical assets, and plan further attacks, potentially leading to data exfiltration or lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -8617,7 +8514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `netstat.exe` with command-line arguments utilized to get a listing of network connections on a compromised system. Red Teams and adversaries alike may use netstat.exe for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `netstat.exe` with command-line arguments to list network connections on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as both Red Teams and adversaries use `netstat.exe` for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map network connections, identify critical systems, and plan further lateral movement or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -8627,7 +8524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic look for a spawned process of route.exe windows application. Adversaries and red teams alike abuse this application the recon or do a network discovery on a target host. but one possible false positive might be an automated tool used by a system administator or a powershell script in amazon ec2 config services. +explanation = The following analytic detects the execution of the `route.exe` Windows application, commonly used for network discovery. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events. This activity is significant because adversaries often use `route.exe` to map network routes and identify potential targets within a network. If confirmed malicious, this behavior could allow attackers to gain insights into network topology, facilitating lateral movement and further exploitation. Note that false positives may occur due to legitimate administrative tasks or automated scripts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016", "T1016.001"], "nist": ["DE.AE"]} known_false_positives = A network operator or systems administrator may utilize an automated host discovery application that may generate false positives or an amazon ec2 script that uses this application. Filter as needed. @@ -8637,7 +8534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies object access on Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The IcedID malware family also implements this behavior to try to infect other machines in the infected network. +explanation = The following analytic detects access to Windows administrative SMB shares (Admin$, IPC$, C$) using the 'dir' command. It leverages Windows Security Event Logs with EventCode 5140 to identify this activity. This behavior is significant as it is commonly used by tools like PsExec/PaExec for staging binaries before creating and starting services on remote endpoints, a technique often employed by adversaries for lateral movement and remote code execution. If confirmed malicious, this activity could allow attackers to propagate malware, such as IcedID, across the network, leading to widespread infection and potential data breaches. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5140 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.AE"]} known_false_positives = System Administrators may use looks like net.exe or "dir commandline" for troubleshooting or administrations tasks. However, this will typically come only from certain users and certain systems that can be added to an allow list. @@ -8647,7 +8544,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Network confidence = medium -explanation = The following analytic identifies network traffic to Active Directory Web Services Protocol. This protocol is used to manage Active Directory. The analytic is meant to be tuned and filtered to the specific environment. It will assist defenders in identifying suspicious processes accessing port 9389. +explanation = The following analytic identifies network traffic directed to the Active Directory Web Services Protocol (ADWS) on port 9389. It leverages network traffic logs, focusing on source and destination IP addresses, application names, and destination ports. This activity is significant as ADWS is used to manage Active Directory, and unauthorized access could indicate malicious intent. If confirmed malicious, an attacker could manipulate Active Directory, potentially leading to privilege escalation, unauthorized access, or persistent control over the environment. how_to_implement = The detection is based on data that originates from network traffic logs. The logs must contain the source and destination IP addresses, the application name, and the destination port. The logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network traffic data source. The logs must also be mapped to the `Network_Traffic` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited as the destination port is specific to Active Directory Web Services Protocol, however we recommend utilizing this analytic to hunt for non-standard processes querying the ADWS port. Filter by App or dest_ip to AD servers and remove known proceses querying ADWS. @@ -8657,7 +8554,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This query detects the Nishang Invoke-PowerShellTCPOneLine utility that spawns a call back to a remote Command And Control server. This is a powershell oneliner. In addition, this will capture on the command-line additional utilities used by Nishang. Triage the endpoint and identify any parallel processes that look suspicious. Review the reputation of the remote IP or domain contacted by the powershell process. +explanation = The following analytic detects the use of the Nishang Invoke-PowerShellTCPOneLine utility, which initiates a callback to a remote Command and Control (C2) server. It leverages Endpoint Detection and Response (EDR) data, focusing on PowerShell processes that include specific .NET classes like Net.Sockets.TCPClient and System.Text.ASCIIEncoding. This activity is significant as it indicates potential remote control or data exfiltration attempts by an attacker. If confirmed malicious, this could lead to unauthorized remote access, data theft, or further compromise of the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present. Filter as needed based on initial analysis. @@ -8667,7 +8564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for the execution of `nltest.exe` with command-line arguments utilized to query for Domain Trust information. Two arguments `/domain trusts`, returns a list of trusted domains, and `/all_trusts`, returns all trusted domains. Red Teams and adversaries alike use NLTest.exe to enumerate the current domain to assist with further understanding where to pivot next. +explanation = The following analytic identifies the execution of `nltest.exe` with command-line arguments `/domain_trusts` or `/all_trusts` to query Domain Trust information. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant as it indicates potential reconnaissance efforts by adversaries to understand domain trust relationships, which can inform their lateral movement strategies. If confirmed malicious, this activity could enable attackers to map out trusted domains, facilitating further compromise and pivoting within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} known_false_positives = Administrators may use nltest for troubleshooting purposes, otherwise, rarely used. @@ -8677,7 +8574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect an anomaly event of a non-chrome process accessing the files in chrome user default folder. This folder contains all the sqlite database of the chrome browser related to users login, history, cookies and etc. Most of the RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database to collect information on the compromised host. This SACL Event (4663) need to be enabled to tthe firefox profile directory to be eable to use this. Since you monitoring this access to the folder, we observed noise that needs to be filter out and hence added sqlite db browser and explorer .exe to make this detection more stable. +explanation = The following analytic detects a non-Chrome process accessing files in the Chrome user default folder. It leverages Windows Security Event logs, specifically event code 4663, to identify unauthorized access attempts. This activity is significant because the Chrome default folder contains sensitive user data such as login credentials, browsing history, and cookies. If confirmed malicious, this behavior could indicate an attempt to exfiltrate sensitive information, often associated with RATs, trojans, and advanced persistent threats like FIN7. Such access could lead to data theft and further compromise of the affected system. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555", "T1555.003"], "nist": ["DE.AE"]} known_false_positives = other browser not listed related to firefox may catch by this rule. @@ -8687,7 +8584,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect an anomaly event of a non-firefox process accessing the files in the profile folder. This folder contains all the sqlite database of the firefox browser related to users login, history, cookies and etc. Most of the RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database to collect information on the compromised host. This SACL Event (4663) needs to be enabled to the firefox profile directory to use this. Since this is monitoring the access to the folder, we have obsevered noise and hence added `sqlite db browser` and `explorer.exe` to make this detection more stable. +explanation = The following analytic detects non-Firefox processes accessing the Firefox profile directory, which contains sensitive user data such as login credentials, browsing history, and cookies. It leverages Windows Security Event logs, specifically event code 4663, to monitor access attempts. This activity is significant because it may indicate attempts by malware, such as RATs or trojans, to harvest user information. If confirmed malicious, this behavior could lead to data exfiltration, unauthorized access to user accounts, and further compromise of the affected system. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555", "T1555.003"], "nist": ["DE.AE"]} known_false_positives = other browser not listed related to firefox may catch by this rule. @@ -8697,7 +8594,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies behavior related to default SliverC2 framework where it will inject into Notepad.exe and spawn Notepad.exe with no command line arguments. In testing, this is a common procedure for SliverC2 usage, however may be modified or changed. From Microsoft, "The Sideload, SpawnDll, and Execute-Assembly commands spawn and inject into notepad.exe by default. The following query finds process creation events where the same process creates and injects into notepad.exe within 10 seconds." +explanation = The following analytic identifies instances where Notepad.exe is launched without any command line arguments, a behavior commonly associated with the SliverC2 framework. This detection leverages process creation events from Endpoint Detection and Response (EDR) agents, focusing on processes initiated by Notepad.exe within a short time frame. This activity is significant as it may indicate an attempt to inject malicious code into Notepad.exe, a known tactic for evading detection. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise and unauthorized access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering may need to occur based on organization endpoint behavior. @@ -8707,9 +8604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Monitor for signs that Ntdsutil is being used to Extract Active Directory database - NTDS.dit, typically used for offline password cracking. It may be used in normal circumstances with no command line arguments or shorthand variations of more common arguments. Ntdsutil.exe is typically seen run on a Windows Server. Typical command used to dump ntds.dit \ -ntdsutil "ac i ntds" "ifm" "create full C:\Temp" q q \ -This technique uses "Install from Media" (IFM), which will extract a copy of the Active Directory database. A successful export of the Active Directory database will yield a file modification named ntds.dit to the destination. +explanation = The following analytic detects the use of Ntdsutil to export the Active Directory database (NTDS.dit). It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because exporting NTDS.dit can be a precursor to offline password cracking, posing a severe security risk. If confirmed malicious, an attacker could gain access to sensitive credentials, potentially leading to unauthorized access and privilege escalation within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} known_false_positives = Highly possible Server Administrators will troubleshoot with ntdsutil.exe, generating false positives. @@ -8719,7 +8614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious MS office application that drops or creates executables or scripts in a Windows Operating System. This behavior is commonly seen in spear phishing office attachment where it drop malicious files or script to compromised the host. It might be some normal macro may drop script or tools as part of automation but still this behavior is reallly suspicious and not commonly seen in normal office application +explanation = The following analytic detects Microsoft Office applications dropping or creating executables or scripts on a Windows OS. It leverages process creation and file system events from the Endpoint data model to identify Office applications like Word or Excel generating files with extensions such as .exe, .dll, or .ps1. This behavior is significant as it is often associated with spear-phishing attacks where malicious files are dropped to compromise the host. If confirmed malicious, this activity could lead to code execution, privilege escalation, or persistent access, posing a severe threat to the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = office macro for automation may do this behavior @@ -8729,7 +8624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this detection was designed to identifies suspicious spawned process of known MS office application due to macro or malicious code. this technique can be seen in so many malware like IcedID that used MS office as its weapon or attack vector to initially infect the machines. +explanation = The following analytic identifies instances where an Office application spawns a Regsvr32 process, which is often indicative of macro execution or malicious code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is a known Office application. This activity is significant because it is a common technique used by malware, such as IcedID, to initiate infections. If confirmed malicious, this behavior could lead to code execution, allowing attackers to gain control over the affected system and potentially escalate privileges. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -8739,7 +8634,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection was designed to identify suspicious spawned processes of known MS office applications due to macro or malicious code. this technique can be seen in so many malware like trickbot that used MS office as its weapon or attack vector to initially infect the machines. +explanation = The following analytic identifies instances where an Office application spawns a rundll32 process, which is often indicative of macro execution or malicious code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is a known Office application. This activity is significant because it is a common technique used by malware, such as Trickbot, to initiate infections. If confirmed malicious, this behavior could lead to code execution, further system compromise, and potential data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -8749,7 +8644,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a potentially malicious office document that creates a scheduled task entry either through a macro VBA API or by loading taskschd.dll. This technique has been observed in numerous instances of malicious macro malware aiming to establish persistence or beaconing through task schedule entries. The analytic will return the first and last time the task was registered, as well as details such as the `Command` to be executed, `Task Name`, `Author`, `Enabled` status, and whether it is `Hidden`. schtasks.exe is natively located in `C:\Windows\system32` and `C:\Windows\syswow64`. The DLL(s) `taskschd.dll` are loaded when schtasks.exe or TaskService is initiated. If this DLL is found loaded by another process, it may indicate that a scheduled task is being registered within that process's context in memory. During triage, determine the source of the scheduled task. Was it schtasks.exe or via TaskService? Review the job created and the command to be executed. Capture any artifacts on disk for further review. Identify any parallel processes within the same timeframe to pinpoint the source.' +explanation = The following analytic detects an Office document creating a scheduled task, either through a macro VBA API or by loading `taskschd.dll`. This detection leverages Sysmon EventCode 7 to identify when Office applications load the `taskschd.dll` file. This activity is significant as it is a common technique used by malicious macro malware to establish persistence or initiate beaconing. If confirmed malicious, this could allow an attacker to maintain persistence, execute arbitrary commands, or schedule future malicious activities, posing a significant threat to the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Also be sure to include those monitored dll to your own sysmon config. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives may occur if legitimate office documents are creating scheduled tasks. Ensure to investigate the scheduled task and the command to be executed. If the task is benign, add the task name to the exclusion list. Some applications may legitimately load taskschd.dll. @@ -8759,7 +8654,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This detection is designed to identify suspicious office documents that utilize macro code. Macro code is known to be a prevalent weaponization or attack vector for threat actors. This malicious macro code can be embedded in an office document as an attachment, potentially executing a malicious payload, downloading malware, or other malicious components. It is a good practice to disable macros by default to prevent the automatic execution of macro code when opening or closing office document files. +explanation = The following analytic identifies office documents executing macro code. It leverages Sysmon EventCode 7 to detect when processes like WINWORD.EXE or EXCEL.EXE load specific DLLs associated with macros (e.g., VBE7.DLL). This activity is significant because macros are a common attack vector for delivering malicious payloads, such as malware. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the system. Disabling macros by default is recommended to mitigate this risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Also be sure to include those monitored dll to your own sysmon config. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives may occur if legitimate office documents are executing macro code. Ensure to investigate the macro code and the command to be executed. If the macro code is benign, add the document name to the exclusion list. Some applications may legitimately load VBE7INTL.DLL, VBE7.DLL, or VBEUI.DLL. @@ -8769,7 +8664,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect potential malicious office document executing lolbin child process to download payload or other malware. Since most of the attacker abused the capability of office document to execute living on land application to blend it to the normal noise in the infected machine to cover its track. +explanation = The following analytic identifies Office applications spawning child processes to download content via HTTP/HTTPS. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where Office applications like Word or Excel initiate network connections, excluding common browsers. This activity is significant as it often indicates the use of malicious documents to execute living-off-the-land binaries (LOLBins) for payload delivery. If confirmed malicious, this behavior could lead to unauthorized code execution, data exfiltration, or further malware deployment, posing a severe threat to the organization's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = Default browser not in the filter list. @@ -8779,7 +8674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this search is to detect a suspicious office product process that spawn cmd child process. This is commonly seen in a ms office product having macro to execute shell command to download or execute malicious lolbin relative to its malicious code. This is seen in trickbot spear phishing doc where it execute shell cmd to run mshta payload. +explanation = The following analytic detects an Office product spawning a CMD process, which is indicative of a macro executing shell commands to download or run malicious code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process names. This activity is significant as it often signals the execution of malicious payloads, such as those seen in Trickbot spear-phishing campaigns. If confirmed malicious, this behavior could lead to unauthorized code execution, potentially compromising the system and allowing further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = IT or network admin may create an document automation that will run shell script. @@ -8789,7 +8684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `bitsadmin.exe`. In malicious instances, the command-line of `bitsadmin.exe` will contain a URL to a remote destination or similar command-line arguments as transfer, Download, priority, Foreground. In addition, Threat Research has released a detections identifying suspicious use of `bitsadmin.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `bitsadmin.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic detects any Windows Office Product spawning `bitsadmin.exe`, a behavior often associated with malware families like TA551 and IcedID. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant because `bitsadmin.exe` is commonly used for malicious file transfers, potentially indicating a malware infection. If confirmed malicious, this activity could allow attackers to download additional payloads, escalate privileges, or establish persistence, leading to further compromise of the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = No false positives known. Filter as needed. @@ -8799,7 +8694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `certutil.exe`. In malicious instances, the command-line of `certutil.exe` will contain a URL to a remote destination. In addition, Threat Research has released a detections identifying suspicious use of `certutil.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `certutil.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic detects any Windows Office Product spawning `certutil.exe`, a behavior often associated with malware families like TA551 and IcedID. This detection leverages Endpoint Detection and Response (EDR) data, focusing on process relationships and command-line executions. The significance lies in the fact that `certutil.exe` is frequently used for downloading malicious payloads from remote URLs. If confirmed malicious, this activity could lead to unauthorized code execution, data exfiltration, or further system compromise. Immediate investigation and containment are crucial to prevent potential damage. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = No false positives known. Filter as needed. @@ -8809,7 +8704,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `mshta.exe`. In malicious instances, the command-line of `mshta.exe` will contain the `hta` file locally, or a URL to the remote destination. In addition, Threat Research has released a detections identifying suspicious use of `mshta.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `mshta.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic identifies instances where a Microsoft Office product spawns `mshta.exe`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is an Office application. This activity is significant because it is a common technique used by malware families like TA551 and IcedID to execute malicious scripts or payloads. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to data exfiltration, system compromise, or further malware deployment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = No false positives known. Filter as needed. @@ -8819,7 +8714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by IcedID malware family. This detection identifies any Windows Office Product spawning `rundll32.exe` without a `.dll` file extension. In malicious instances, the command-line of `rundll32.exe` will look like `rundll32 ..\oepddl.igk2,DllRegisterServer`. In addition, Threat Research has released a detection identifying the use of `DllRegisterServer` on the command-line of `rundll32.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze the `DLL` that was dropped to disk. The Office Product will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic detects any Windows Office Product spawning `rundll32.exe` without a `.dll` file extension. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process and parent process relationships. This activity is significant as it is a known tactic of the IcedID malware family, which can lead to unauthorized code execution. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to data exfiltration, system compromise, or further malware deployment. Immediate investigation and containment are recommended. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if any are present, filter as needed. @@ -8839,7 +8734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by Ursnif malware family. This detection identifies any Windows Office Product spawning `wmic.exe`. In malicious instances, the command-line of `wmic.exe` will contain `wmic process call create`. In addition, Threat Research has released a detection identifying the use of `wmic process call create` on the command-line of `wmic.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `wmic.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic detects any Windows Office Product spawning `wmic.exe`, specifically when the command-line of `wmic.exe` contains `wmic process call create`. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant as it is commonly associated with the Ursnif malware family, indicating potential malicious activity. If confirmed malicious, this could allow an attacker to execute arbitrary commands, leading to further system compromise, data exfiltration, or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = No false positives known. Filter as needed. @@ -8849,7 +8744,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies behavior related to CVE-2021-40444. Whereas the malicious document will load ActiveX and download the remote payload (.inf, .cab). During triage, review parallel processes and further activity on endpoint to identify additional patterns. Retrieve the file modifications and analyze further. +explanation = The following analytic detects Office products writing .cab or .inf files, indicative of CVE-2021-40444 exploitation. It leverages the Endpoint.Processes and Endpoint.Filesystem data models to identify Office applications creating these file types. This activity is significant as it may signal an attempt to load malicious ActiveX controls and download remote payloads, a known attack vector. If confirmed malicious, this could lead to remote code execution, allowing attackers to gain control over the affected system and potentially compromise sensitive data. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. @@ -8859,7 +8754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies control.exe spawning from an office product. This detection identifies any Windows Office Product spawning `control.exe`. In malicious instances, the command-line of `control.exe` will contain a file path to a .cpl or .inf, related to CVE-2021-40444. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. review parallel and child processes to identify further suspicious behavior +explanation = The following analytic identifies instances where `control.exe` is spawned by a Microsoft Office product. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant because it can indicate exploitation attempts related to CVE-2021-40444, where `control.exe` is used to execute malicious .cpl or .inf files. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present. @@ -8869,7 +8764,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = A required step while exploiting the CVE-2021-44228-Log4j vulnerability is that the victim server will perform outbound connections to attacker-controlled infrastructure. This is required as part of the JNDI lookup as well as for retrieving the second stage .class payload. The following analytic identifies the Java process reaching out to default ports used by the LDAP and RMI protocols. This behavior could represent successfull exploitation. Note that adversaries can easily decide to use arbitrary ports for these protocols and potentially bypass this detection. +explanation = The following analytic detects outbound network connections from Java processes to default ports used by LDAP and RMI protocols, which may indicate exploitation of the CVE-2021-44228-Log4j vulnerability. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and network traffic logs. Monitoring this activity is crucial as it can signify an attacker’s attempt to perform JNDI lookups and retrieve malicious payloads. If confirmed malicious, this activity could lead to remote code execution and further compromise of the affected server. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Legitimate Java applications may use perform outbound connections to these ports. Filter as needed @@ -8879,7 +8774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Microsoft Windows contains accessibility features that can be launched with a key combination before a user has logged in. An adversary can modify or replace these programs so they can get a command prompt or backdoor without logging in to the system. This search looks for modifications to these binaries. +explanation = The following analytic detects modifications to Windows accessibility binaries such as sethc.exe, utilman.exe, osk.exe, Magnify.exe, Narrator.exe, DisplaySwitch.exe, and AtBroker.exe. It leverages filesystem activity data from the Endpoint.Filesystem data model to identify changes to these specific files. This activity is significant because adversaries can exploit these binaries to gain unauthorized access or execute commands without logging in. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized system access and further compromise of the environment. how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546", "T1546.008"], "nist": ["DE.CM"]} known_false_positives = Microsoft may provide updates to these binaries. Verify that these changes do not correspond with your normal software update cycle. @@ -8889,7 +8784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Web Server confidence = medium -explanation = The following hunting analytic is designed to monitor and detect potential exploitation attempts targeting a PaperCut NG server by analyzing its debug log data. By focusing on public IP addresses accessing the PaperCut NG instance, this analytic aims to identify unauthorized or suspicious access attempts. Furthermore, it searches for specific URIs that have been discovered in the proof of concept code, which are associated with known exploits or vulnerabilities. The analytic is focused on the user admin. Regex is used mainly because the log is not parsed by Splunk and there is no TA for this debug log. +explanation = The following analytic identifies potential exploitation attempts on a PaperCut NG server by analyzing its debug log data. It detects unauthorized or suspicious access attempts from public IP addresses and searches for specific URIs associated with known exploits. The detection leverages regex to parse unstructured log data, focusing on admin login activities. This activity is significant as it can indicate an active exploitation attempt on the server. If confirmed malicious, attackers could gain unauthorized access, potentially leading to data breaches or further compromise of the server. how_to_implement = Debug logs must be enabled and shipped to Splunk in order to properly identify behavior with this analytic. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, as this is based on the admin user accessing the Papercut NG instance from a public IP address. Filter as needed. @@ -8919,11 +8814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes Windows Event Code 5145, "A network share object was checked to see whether client can be granted desired access". During our research into PetitPotam, CVE-2021-36942, we identified the ocurrence of this event on the target host with specific values. \ -To enable 5145 events via Group Policy - Computer Configuration->Polices->Windows Settings->Security Settings->Advanced Audit Policy Configuration. Expand this node, go to Object Access (Audit Polices->Object Access), then select the Setting Audit Detailed File Share Audit \ -It is possible this is not enabled by default and may need to be reviewed and enabled. \ - \ -During triage, review parallel security events to identify further suspicious activity. +explanation = The following analytic detects network share access requests indicative of the PetitPotam attack (CVE-2021-36942). It leverages Windows Event Code 5145, which logs attempts to access network share objects. This detection is significant as PetitPotam can coerce authentication from domain controllers, potentially leading to unauthorized access. If confirmed malicious, this activity could allow attackers to escalate privileges or move laterally within the network, posing a severe security risk. Ensure Event Code 5145 is enabled via Group Policy to utilize this analytic effectively. how_to_implement = Windows Event Code 5145 is required to utilize this analytic and it may not be enabled in most environments. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1187"], "nist": ["DE.CM"]} known_false_positives = False positives have been limited when the Anonymous Logon is used for Account Name. @@ -8933,7 +8824,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifes Event Code 4768, A `Kerberos authentication ticket (TGT) was requested`, successfull occurs. This behavior has been identified to assist with detecting PetitPotam, CVE-2021-36942. Once an attacer obtains a computer certificate by abusing Active Directory Certificate Services in combination with PetitPotam, the next step would be to leverage the certificate for malicious purposes. One way of doing this is to request a Kerberos Ticket Granting Ticket using a tool like Rubeus. This request will generate a 4768 event with some unusual fields depending on the environment. This analytic will require tuning, we recommend filtering Account_Name to Domain Controllers for your environment. +explanation = The following analytic detects a suspicious Kerberos Ticket Granting Ticket (TGT) request, identified by Event Code 4768. This detection leverages Windows Security Event Logs to identify TGT requests with unusual fields, which may indicate the use of tools like Rubeus following the exploitation of CVE-2021-36942 (PetitPotam). This activity is significant as it can signal an attacker leveraging a compromised certificate to request Kerberos tickets, potentially leading to unauthorized access. If confirmed malicious, this could allow attackers to escalate privileges and persist within the environment, posing a severe security risk. how_to_implement = The following analytic requires Event Code 4768. Ensure that it is logging no Domain Controllers and appearing in Splunk. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003"], "nist": ["DE.CM"]} known_false_positives = False positives are possible if the environment is using certificates for authentication. @@ -8943,7 +8834,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify the possible execution of ping sleep batch commands. This technique was seen in several malware samples and is used to trigger sleep times without explicitly calling sleep functions or commandlets. The goal is to delay the execution of malicious code and bypass detection or sandbox analysis. This detection can be a good indicator of a process delaying its execution for malicious purposes. +explanation = The following analytic identifies the execution of ping sleep batch commands. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process command-line details. This activity is significant as it indicates an attempt to delay malicious code execution, potentially evading detection or sandbox analysis. If confirmed malicious, this technique allows attackers to bypass security measures, making it harder to detect and analyze their activities, thereby increasing the risk of prolonged unauthorized access and potential data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497", "T1497.003"], "nist": ["DE.AE"]} known_false_positives = Administrator or network operator may execute this command. Please update the filter macros to remove false positives. @@ -8953,7 +8844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect if a suspicious process contains a commandline parameter related to a web browser credential dumper. This technique is used by Remcos RAT malware which uses the Nirsoft webbrowserpassview.exe application to dump web browser credentials. Remcos uses the "/stext" command line to dump the credentials in text format. This Hunting query is a good indicator of hosts suffering from possible Remcos RAT infection. Since the hunting query is based on the parameter command and the possible path where it will save the text credential information, it may catch normal tools that are using the same command and behavior. +explanation = The following analytic identifies processes with command-line parameters associated with web browser credential dumping tools, specifically targeting behaviors used by Remcos RAT malware. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and specific file paths. This activity is significant as it indicates potential credential theft, a common tactic in broader cyber-espionage campaigns. If confirmed malicious, attackers could gain unauthorized access to sensitive web credentials, leading to further system compromise and data breaches. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555.003", "T1555"], "nist": ["DE.AE"]} known_false_positives = False positive is quite limited. Filter is needed @@ -8963,8 +8854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to identify possible lateral movement attacks that involve the spawning of a PowerShell process as a child or grandchild process of commonly abused processes. These processes include services.exe, wmiprsve.exe, svchost.exe, wsmprovhost.exe, and mmc.exe. \ -Such behavior is indicative of legitimate Windows features such as the Service Control Manager, Windows Management Instrumentation, Task Scheduler, Windows Remote Management, and the DCOM protocol being abused to start a process on a remote endpoint. This behavior is often seen during lateral movement techniques where adversaries or red teams abuse these services for lateral movement and remote code execution. +explanation = The following analytic detects the spawning of a PowerShell process as a child or grandchild of commonly abused processes like services.exe, wmiprsve.exe, svchost.exe, wsmprovhost.exe, and mmc.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process names, as well as command-line executions. This activity is significant as it often indicates lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this behavior could allow attackers to execute code remotely, escalate privileges, or persist within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.003", "T1021.006", "T1047", "T1053.005", "T1543.003", "T1059.001", "T1218.014"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may spawn PowerShell as a child process of the the identified processes. Filter as needed. @@ -8974,7 +8864,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search identifies users who have entered their passwords in username fields. This is done by looking for failed authentication attempts using usernames with a length longer than 7 characters and a high Shannon entropy, and looks for the next successful authentication attempt from the same source system to the same destination system as the failed attempt. +explanation = The following analytic identifies instances where users may have mistakenly entered their passwords in the username field during authentication attempts. It detects this by analyzing failed authentication events with usernames longer than 7 characters and high Shannon entropy, followed by a successful authentication from the same source to the same destination. This activity is significant as it can indicate potential security risks, such as password exposure. If confirmed malicious, attackers could exploit this to gain unauthorized access, leading to potential data breaches or further compromise of the system. how_to_implement = To successfully implement this search, you need to have relevant authentication logs mapped to the Authentication data model. You also need to have the Splunk TA URL Toolbox (https://splunkbase.splunk.com/app/2734/) installed. The detection must run with a time interval shorter than endtime+1000. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.003", "T1552.001"], "nist": ["DE.AE"]} known_false_positives = Valid usernames with high entropy or source/destination system pairs with multiple authenticating users will make it difficult to identify the real user authenticating. @@ -8984,7 +8874,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses a pretrained machine learning text classifier to detect potentially malicious commandlines. The model identifies unusual combinations of keywords found in samples of commandlines where adversaries executed powershell code, primarily for C2 communication. For example, adversaries will leverage IO capabilities such as "streamreader" and "webclient", threading capabilties such as "mutex" locks, programmatic constructs like "function" and "catch", and cryptographic operations like "computehash". Although observing one of these keywords in a commandline script is possible, combinations of keywords observed in attack data are not typically found in normal usage of the commandline. The model will output a score where all values above zero are suspicious, anything greater than one particularly so. +explanation = The following analytic detects potentially malicious command lines using a pretrained machine learning text classifier. It identifies unusual keyword combinations in command lines, such as "streamreader," "webclient," "mutex," "function," and "computehash," which are often associated with adversarial PowerShell code execution for C2 communication. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command lines longer than 200 characters. This activity is significant as it can indicate an attempt to execute malicious scripts, potentially leading to unauthorized code execution, data exfiltration, or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003"], "nist": ["DE.AE"]} known_false_positives = This model is an anomaly detector that identifies usage of APIs and scripting constructs that are correllated with malicious activity. These APIs and scripting constructs are part of the programming langauge and advanced scripts may generate false positives. @@ -8994,7 +8884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following Hunting analytic assists with identifying suspicious PowerShell execution using Script Block Logging, or EventCode 4104. This analytic is not meant to be ran hourly, but occasionally to identify malicious or suspicious PowerShell. This analytic is a combination of work completed by Alex Teixeira and Splunk Threat Research Team. +explanation = The following analytic identifies suspicious PowerShell execution using Script Block Logging (EventCode 4104). It leverages specific patterns and keywords within the ScriptBlockText field to detect potentially malicious activities. This detection is significant for SOC analysts as PowerShell is commonly used by attackers for various malicious purposes, including code execution, privilege escalation, and persistence. If confirmed malicious, this activity could allow attackers to execute arbitrary commands, exfiltrate data, or maintain long-term access to the compromised system, posing a severe threat to the organization's security. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.AE"]} known_false_positives = Limited false positives. May filter as needed. @@ -9004,7 +8894,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies PowerShell commands utilizing the WindowStyle parameter to hide the window on the compromised endpoint. This combination of command-line options is suspicious because it is overriding the default PowerShell execution policy, attempts to hide its activity from the user, and connects to the Internet. Removed in this version of the query is New-Object. The analytic identifies all variations of WindowStyle, as PowerShell allows the ability to shorten the parameter. For example w, win, windowsty and so forth. In addition, through our research it was identified that PowerShell will interpret different command switch types beyond the hyphen. We have added endash, emdash, horizontal bar, and forward slash. +explanation = The following analytic detects PowerShell commands using the WindowStyle parameter to hide the window while connecting to the Internet. This behavior is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions that include variations of the WindowStyle parameter. This activity is significant because it attempts to bypass default PowerShell execution policies and conceal its actions, which is often indicative of malicious intent. If confirmed malicious, this could allow an attacker to execute commands stealthily, potentially leading to unauthorized data exfiltration or further compromise of the endpoint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]} known_false_positives = Legitimate process can have this combination of command-line options, but it's not common. @@ -9024,7 +8914,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using the `mutex` function. This function is commonly seen in some obfuscated PowerShell scripts to make sure that only one instance of there process is running on a compromise machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic detects the execution of PowerShell scripts using the `mutex` function via EventCode 4104. This detection leverages PowerShell Script Block Logging to identify scripts that create thread mutexes, a technique often used in obfuscated scripts to ensure only one instance runs on a compromised machine. This activity is significant as it may indicate the presence of sophisticated malware or persistence mechanisms. If confirmed malicious, the attacker could maintain exclusive control over a process, potentially leading to further exploitation or persistence within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1027", "T1027.005", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = powershell developer may used this function in their script for instance checking too. @@ -9044,10 +8934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies specific PowerShell modules typically used to enumerate an organizations domain or users. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of PowerShell commands used for domain enumeration, such as `get-netdomaintrust` and `get-adgroupmember`. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as it often indicates reconnaissance efforts by an attacker to map out the domain structure and identify key users and groups. If confirmed malicious, this behavior could lead to further targeted attacks, privilege escalation, and unauthorized access to sensitive information within the domain. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = It is possible there will be false positives, filter as needed. @@ -9057,7 +8944,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic utilizes PowerShell Script Block Logging (EventCode 4104) to identify the use of Enable-PSRemoting cmdlet. This cmdlet allows users to enable PowerShell remoting on a local or remote computer, which allows other computers to run commands on the target computer. The ability to remotely execute commands can be abused by attackers to take control of compromised systems and pivot to other systems on the network. By detecting the use of Enable-PSRemoting cmdlet via script block logging, this analytic can help organizations identify potential malicious activity related to attackers attempting to gain remote control of compromised systems. +explanation = The following analytic detects the use of the Enable-PSRemoting cmdlet, which allows PowerShell remoting on a local or remote computer. This detection leverages PowerShell Script Block Logging (EventCode 4104) to identify when this cmdlet is executed. Monitoring this activity is crucial as it can indicate an attacker enabling remote command execution capabilities on a compromised system. If confirmed malicious, this activity could allow an attacker to take control of the system remotely, execute commands, and potentially pivot to other systems within the network, leading to further compromise and lateral movement. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]} known_false_positives = Note that false positives may occur due to the use of the Enable-PSRemoting cmdlet by legitimate users, such as system administrators. It is recommended to apply appropriate filters as needed to minimize the number of false positives. @@ -9067,7 +8954,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious enabling of smb1protocol through `powershell.exe`. This technique was seen in some ransomware (like reddot) where it enable smb share to do the lateral movement and encrypt other files within the compromise network system. +explanation = The following analytic detects the enabling of the SMB1 protocol via `powershell.exe`. It leverages PowerShell script block logging (EventCode 4104) to identify the execution of the `Enable-WindowsOptionalFeature` cmdlet with the `SMB1Protocol` parameter. This activity is significant because enabling SMB1 can facilitate lateral movement and file encryption by ransomware, such as RedDot. If confirmed malicious, this action could allow an attacker to propagate through the network, encrypt files, and potentially disrupt business operations. how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027", "T1027.005"], "nist": ["DE.CM"]} known_false_positives = network operator may enable or disable this windows feature. @@ -9077,7 +8964,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a COM CLSID execution through powershell. This technique was seen in several adversaries and malware like ransomware conti where it has a feature to execute command using COM Object. This technique may use by network operator at some cases but a good indicator if some application want to gain privilege escalation or bypass uac. +explanation = The following analytic detects the execution of a COM CLSID through PowerShell. It leverages EventCode 4104 and searches for specific script block text indicating the creation of a COM object. This activity is significant as it is commonly used by adversaries and malware, such as the Conti ransomware, to execute commands, potentially for privilege escalation or bypassing User Account Control (UAC). If confirmed malicious, this technique could allow attackers to gain elevated privileges or persist within the environment, posing a significant security risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.015", "T1546", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = network operrator may use this command. @@ -9087,11 +8974,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies `GetProcAddress` in the script block. This is not normal to be used by most PowerShell scripts and is typically unsafe/malicious. Many attack toolkits use GetProcAddress to obtain code execution. \ -In use, `$var_gpa = $var_unsafe_native_methods.GetMethod(GetProcAddress` and later referenced/executed elsewhere. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the use of `GetProcAddress` in PowerShell script blocks, leveraging PowerShell Script Block Logging (EventCode=4104). This method captures the full command sent to PowerShell, which is then logged in Windows event logs. The presence of `GetProcAddress` is unusual for typical PowerShell scripts and often indicates malicious activity, as many attack toolkits use it to achieve code execution. If confirmed malicious, this activity could allow an attacker to execute arbitrary code, potentially leading to system compromise. Analysts should review parallel processes and the entire logged script block for further investigation. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059", "T1055", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = Limited false positives. Filter as needed. @@ -9101,12 +8984,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies `FromBase64String` within the script block. A typical malicious instance will include additional code. \ -Command example - `[Byte[]]$var_code = [System.Convert]::FromBase64String(38uqIyMjQ6rG....` \ - \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of PowerShell scripts containing Base64 encoded content, specifically identifying the use of `FromBase64String`. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as Base64 encoding is often used by attackers to obfuscate malicious payloads, making it harder to detect. If confirmed malicious, this could lead to code execution, allowing attackers to run arbitrary commands and potentially compromise the system. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059", "T1027", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited. Filter as needed. @@ -9126,10 +9004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies PowerShell cmdlet - `get-localgroup` being ran. Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of the PowerShell cmdlet `get-localgroup` using PowerShell Script Block Logging (EventCode=4104). This method captures the full command sent to PowerShell, providing detailed visibility into script execution. Monitoring this activity is significant as it can indicate an attempt to enumerate local groups, which may be a precursor to privilege escalation or lateral movement. If confirmed malicious, an attacker could gain insights into group memberships, potentially leading to unauthorized access or privilege abuse. Review parallel processes and the entire script block for comprehensive analysis. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]} known_false_positives = False positives may be present. Tune as needed. @@ -9139,7 +9014,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the use of the New-CIMSession cmdlet being created along with the Invoke-CIMMethod cmdlet being used within PowerShell. This particular behavior is similar to the usage of the Invoke-WMIMethod cmdlet, which is known for executing WMI commands on targets using NTLMv2 pass-the-hash authentication. The New-CIMSession cmdlet allows users to create a new CIM session object for a specified computer system, which can then be used to execute CIM operations remotely. Similarly, the Invoke-CIMMethod cmdlet is used to invoke a specified method on one or more CIM objects. Therefore, the combination of New-CIMSession and Invoke-CIMMethod cmdlets in PowerShell can potentially indicate malicious behavior, and this analytic can help detect such activity. +explanation = The following analytic detects the creation of a New-CIMSession cmdlet followed by the use of the Invoke-CIMMethod cmdlet within PowerShell. It leverages PowerShell Script Block Logging to identify these specific cmdlets in the ScriptBlockText field. This activity is significant because it mirrors the behavior of the Invoke-WMIMethod cmdlet, often used for remote code execution via NTLMv2 pass-the-hash authentication. If confirmed malicious, this could allow an attacker to execute commands remotely, potentially leading to unauthorized access and control over targeted systems. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on third-party applications or administrators using CIM. It is recommended to apply appropriate filters as needed to minimize the number of false positives. @@ -9159,10 +9034,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies "MSF.Powershell","MSF.Powershell.Meterpreter","MSF.Powershell.Meterpreter.Kiwi","MSF.Powershell.Meterpreter.Transport" being used. This behavior is related to when a Meterpreter session is started and the operator runs load_kiwi. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the execution of suspicious PowerShell commands associated with Meterpreter modules, such as "MSF.Powershell" and "MSF.Powershell.Meterpreter". It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as it indicates potential post-exploitation actions, including credential dumping and persistence mechanisms. If confirmed malicious, an attacker could gain extensive control over the compromised system, escalate privileges, and maintain long-term access, posing a severe threat to the environment. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be very limited as this is strict to MetaSploit behavior. @@ -9172,10 +9044,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies the use of PowerShell loading .net assembly via reflection. This is commonly found in malicious PowerShell usage, including Empire and Cobalt Strike. In addition, the `load(` value may be modifed by removing `(` and it will identify more events to review. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the use of PowerShell to load .NET assemblies into memory via reflection, a technique often used in malicious activities such as those by Empire and Cobalt Strike. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command executed. This behavior is significant as it can indicate advanced attack techniques aiming to execute code in memory, bypassing traditional defenses. If confirmed malicious, this activity could lead to unauthorized code execution, privilege escalation, and persistent access within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as day to day scripts do not use this method. @@ -9185,7 +9054,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is processing compressed stream data. This is typically found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are stream flattened and will be deflated durnig execution. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic detects suspicious PowerShell script execution involving compressed stream data processing, identified via EventCode 4104. It leverages PowerShell Script Block Logging to flag scripts using `IO.Compression`, `IO.StreamReader`, or decompression methods. This activity is significant as it often indicates obfuscated PowerShell or embedded .NET/binary execution, which are common tactics for evading detection. If confirmed malicious, this behavior could allow attackers to execute hidden code, escalate privileges, or maintain persistence within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} known_false_positives = powershell may used this function to process compressed data. @@ -9195,7 +9064,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 that contains command to add or modify the trustedhost configuration in Windows OS. This behavior raises concerns due to the nature of modifications made to the 'TrustedHost' configuration, which typically involves adjusting settings crucial for remote connections and security protocols. Alterations in this area could potentially indicate attempts to manipulate trusted hosts or systems for unauthorized remote access, a tactic commonly observed in various unauthorized access or compromise attempts. +explanation = The following analytic detects the execution of a PowerShell script that modifies the 'TrustedHosts' configuration via EventCode 4104. It leverages PowerShell Script Block Logging to identify commands targeting WSMan settings, specifically those altering or concatenating trusted hosts. This activity is significant as it can indicate attempts to manipulate remote connection settings, potentially allowing unauthorized remote access. If confirmed malicious, this could enable attackers to establish persistent remote connections, bypass security protocols, and gain unauthorized access to sensitive systems and data. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.006", "T1021"], "nist": ["DE.CM"]} known_false_positives = user and network administrator may used this function to add trusted host. @@ -9205,7 +9074,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = this search is designed to detect suspicious powershell process that tries to inject code and to known/critical windows process and execute it using CreateRemoteThread. This technique is seen in several malware like trickbot and offensive tooling like cobaltstrike where it load a shellcode to svchost.exe to execute reverse shell to c2 and download another payload +explanation = The following analytic detects suspicious PowerShell processes attempting to inject code into critical Windows processes using CreateRemoteThread. It leverages Sysmon EventCode 8 to identify instances where PowerShell spawns threads in processes like svchost.exe, csrss.exe, and others. This activity is significant as it is commonly used by malware such as TrickBot and offensive tools like Cobalt Strike to execute malicious payloads, establish reverse shells, or download additional malware. If confirmed malicious, this behavior could lead to unauthorized code execution, privilege escalation, and persistent access within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, Create Remote thread from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of create remote thread may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9215,7 +9084,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify a suspicious PowerShell command used to delete the Windows Defender folder. This technique was seen used by the WhisperGate malware campaign where it used Nirsofts advancedrun.exe to gain administrative privileges to then execute a PowerShell command to delete the Windows Defender folder. This is a good indicator the offending process is trying corrupt a Windows Defender installation. +explanation = The following analytic detects a suspicious PowerShell command attempting to delete the Windows Defender directory. It leverages PowerShell Script Block Logging to identify commands containing "rmdir" and targeting the Windows Defender path. This activity is significant as it may indicate an attempt to disable or corrupt Windows Defender, a key security component. If confirmed malicious, this action could allow an attacker to bypass endpoint protection, facilitating further malicious activities without detection. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9225,7 +9094,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 that contains multiple URLs within a function or array. This is typically found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are attempting to download 2nd stage payloads. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that contains multiple URLs within a function or array. It leverages PowerShell operational logs to detect script blocks with embedded URLs, often indicative of obfuscated scripts or those attempting to download secondary payloads. This activity is significant as it may signal an attempt to execute malicious code or download additional malware. If confirmed malicious, this could lead to code execution, further system compromise, or data exfiltration. Review parallel processes and the full script block for additional context and related artifacts. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059.001", "T1105"], "nist": ["DE.CM"]} known_false_positives = Unknown, possible custom scripting. @@ -9235,7 +9104,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = Start-BitsTransfer is the PowerShell "version" of BitsAdmin.exe. Similar functionality is present. This technique variation is not as commonly used by adversaries, but has been abused in the past. Lesser known uses include the ability to set the `-TransferType` to `Upload` for exfiltration of files. In an instance where `Upload` is used, it is highly possible files will be archived. During triage, review parallel processes and process lineage. Capture any files on disk and review. For the remote domain or IP, what is the reputation? +explanation = The following analytic detects the execution of the PowerShell command `Start-BitsTransfer`, which can be used for file transfers, including potential data exfiltration. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line arguments. This activity is significant because `Start-BitsTransfer` can be abused by adversaries to upload sensitive files to remote locations, posing a risk of data loss. If confirmed malicious, this could lead to unauthorized data exfiltration, compromising sensitive information and potentially leading to further exploitation of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"]} known_false_positives = Limited false positives. It is possible administrators will utilize Start-BitsTransfer for administrative tasks, otherwise filter based parent process or command-line arguments. @@ -9245,7 +9114,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the use of PowerShell's Start-Service or Stop-Service cmdlets on an endpoint. These cmdlets allow users to start or stop a specified Windows service. The ability to manipulate services can be leveraged by attackers to disable or stop critical services, which can cause system instability or disrupt business operations. By detecting the use of Start-Service or Stop-Service cmdlets via PowerShell, this analytic can help organizations identify potential malicious activity related to attackers attempting to manipulate services on compromised systems. However, note that this behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats. +explanation = The following analytic identifies the use of PowerShell's Start-Service or Stop-Service cmdlets on an endpoint. It leverages PowerShell Script Block Logging to detect these commands. This activity is significant because attackers can manipulate services to disable or stop critical functions, causing system instability or disrupting business operations. If confirmed malicious, this behavior could allow attackers to disable security services, evade detection, or disrupt essential services, leading to potential system downtime and compromised security. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001"], "nist": ["DE.AE"]} known_false_positives = This behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats. @@ -9255,7 +9124,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using memory stream as new object backstore. The malicious PowerShell script will contain stream flate data and will be decompressed in memory to run or drop the actual payload. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic detects suspicious PowerShell script execution using memory streams as a backing store, identified via EventCode 4104. It leverages PowerShell Script Block Logging to capture scripts that create new objects with memory streams, often used to decompress and execute payloads in memory. This activity is significant as it indicates potential in-memory execution of malicious code, bypassing traditional file-based detection. If confirmed malicious, this technique could allow attackers to execute arbitrary code, maintain persistence, or escalate privileges without leaving a trace on the disk. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.CM"]} known_false_positives = powershell may used this function to store out object into memory. @@ -9275,7 +9144,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect a suspicious process commandline related to windows defender exclusion feature. This command is abused by adversaries, malware author and red teams to bypassed Windows Defender Anti-Virus product by excluding folder path, file path, process, extensions and etc. from its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior. +explanation = The following analytic detects the use of PowerShell commands to add or set Windows Defender exclusions. It leverages EventCode 4104 to identify suspicious `Add-MpPreference` or `Set-MpPreference` commands with exclusion parameters. This activity is significant because adversaries often use it to bypass Windows Defender, allowing malicious code to execute without detection. If confirmed malicious, this behavior could enable attackers to evade antivirus defenses, maintain persistence, and execute further malicious activities undetected. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to use this windows features. @@ -9295,7 +9164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious modification or new registry entry regarding print processor. This registry is known to be abuse by turla or other APT to gain persistence and privilege escalation to the compromised machine. This is done by adding the malicious dll payload on the new created key in this registry that will be executed as it restarted the spoolsv.exe process and services. +explanation = The following analytic detects suspicious modifications or new entries in the Print Processor registry path. It leverages registry activity data from the Endpoint data model to identify changes in the specified registry path. This activity is significant because the Print Processor registry is known to be exploited by APT groups like Turla for persistence and privilege escalation. If confirmed malicious, this could allow an attacker to execute a malicious DLL payload by restarting the spoolsv.exe process, leading to potential control over the compromised machine. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = possible new printer installation may add driver component on this registry. @@ -9305,10 +9174,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies new printer drivers being load by utilizing the Windows PrintService operational logs, EventCode 316. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. \ - \ -Within the proof of concept code, the following event will occur - "Printer driver 1234 for Windows x64 Version-3 was added or updated. Files:- UNIDRV.DLL, kernelbase.dll, evil.dll. No user action is required." \ -During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events and review the source of where the exploitation began. +explanation = The following analytic detects the addition of new printer drivers by monitoring Windows PrintService operational logs, specifically EventCode 316. This detection leverages log data to identify messages indicating the addition or update of printer drivers, such as "kernelbase.dll" and "UNIDRV.DLL." This activity is significant as it may indicate exploitation attempts related to vulnerabilities like CVE-2021-34527 (PrintNightmare). If confirmed malicious, attackers could gain code execution or escalate privileges, potentially compromising the affected system. Immediate isolation and investigation of the endpoint are recommended. how_to_implement = You will need to ensure PrintService Admin and Operational logs are being logged to Splunk from critical or all systems. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = Unknown. This may require filtering. @@ -9318,10 +9184,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies driver load errors utilizing the Windows PrintService Admin logs. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. \ -Within the proof of concept code, the following error will occur - "The print spooler failed to load a plug-in module C:\Windows\system32\spool\DRIVERS\x64\3\meterpreter.dll, error code 0x45A. See the event user data for context information." \ -The analytic is based on file path and failure to load the plug-in. \ -During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events. +explanation = The following analytic detects driver load errors in the Windows PrintService Admin logs, specifically identifying issues related to CVE-2021-34527 (PrintNightmare). It triggers on error messages indicating the print spooler failed to load a plug-in module, such as "meterpreter.dll," with error code 0x45A. This detection method leverages specific event codes and error messages. This activity is significant as it may indicate an exploitation attempt of a known vulnerability. If confirmed malicious, an attacker could gain unauthorized code execution on the affected system, leading to potential system compromise. how_to_implement = You will need to ensure PrintService Admin and Operational logs are being logged to Splunk from critical or all systems. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = False positives are unknown and filtering may be required. @@ -9341,7 +9204,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection is to identify a suspicious process that tries to delete the process file path related to its process. This technique is known to be defense evasion once a certain condition of malware is satisfied or not. Clop ransomware use this technique where it will try to delete its process file path using a .bat command if the keyboard layout is not the layout it tries to infect. +explanation = The following analytic identifies a process attempting to delete its own file path, a behavior often associated with defense evasion techniques. This detection leverages Sysmon EventCode 1 logs, focusing on command lines executed via cmd.exe that include deletion commands. This activity is significant as it may indicate malware, such as Clop ransomware, trying to evade detection by removing its executable file if certain conditions are met. If confirmed malicious, this could allow the attacker to persist undetected, complicating incident response and remediation efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9351,7 +9214,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `WmiPrvSE.exe` spawning a process. This typically occurs when a process is instantiated from a local or remote process using `wmic.exe`. During triage, review parallel processes for suspicious behavior or commands executed. Review the process and command-line spawning from `wmiprvse.exe`. Contain and remediate the endpoint as necessary. +explanation = The following analytic detects the execution of a process by `WmiPrvSE.exe`, indicating potential use of WMI (Windows Management Instrumentation) for process creation. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant as WMI can be used for lateral movement, remote code execution, or persistence by attackers. If confirmed malicious, this could allow an attacker to execute arbitrary commands or scripts, potentially leading to further compromise of the affected system or network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, administrators may use wmi to execute commands for legitimate purposes. @@ -9371,7 +9234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = DynamicWrapperX is an ActiveX component that can be used in a script to call Windows API functions, but it requires the dynwrapx.dll to be installed and registered. With that, a binary writing dynwrapx.dll to disk and registering it into the registry is highly suspect. Why is it needed? In most malicious instances, it will be written to disk at a non-standard location. During triage, review parallel processes and pivot on the process_guid. Review the registry for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious module loads of dynwrapx.dll. This will identify the process that will invoke vbs/wscript/cscript. +explanation = The following analytic detects a process writing the dynwrapx.dll file to disk and registering it in the registry. It leverages data from the Endpoint datamodel, specifically monitoring process and filesystem events. This activity is significant because DynamicWrapperX is an ActiveX component often used in scripts to call Windows API functions, and its presence in non-standard locations is highly suspicious. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment. Immediate investigation of parallel processes and registry modifications is recommended. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1559.001"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited, however it is possible to filter by Processes.process_name and specific processes (ex. wscript.exe). Filter as needed. This may need modification based on EDR telemetry and how it brings in registry data. For example, removal of (Default). @@ -9381,7 +9244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for processes launching netsh.exe. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line. +explanation = The following analytic identifies processes launching netsh.exe, a command-line utility used to modify network configurations. It detects this activity by analyzing data from Endpoint Detection and Response (EDR) agents, focusing on process GUIDs, names, parent processes, and command-line executions. This behavior is significant because netsh.exe can be exploited to execute malicious helper DLLs, serving as a persistence mechanism. If confirmed malicious, an attacker could gain persistent access, modify network settings, and potentially escalate privileges, posing a severe threat to the network's integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]} known_false_positives = Some VPN applications are known to launch netsh.exe. Outside of these instances, it is unusual for an executable to launch netsh.exe and run commands. @@ -9391,7 +9254,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for processes in an MacOS system that is tapping keyboard events in MacOS, and essentially monitoring all keystrokes made by a user. This is a common technique used by RATs to log keystrokes from a victim, although it can also be used by legitimate processes like Siri to react on human input +explanation = The following analytic detects processes on macOS systems that are tapping keyboard events, potentially monitoring all keystrokes made by a user. It leverages data from osquery results within the Alerts data model, focusing on specific process names and command lines. This activity is significant as it is a common technique used by Remote Access Trojans (RATs) to log keystrokes, posing a serious security risk. If confirmed malicious, this could lead to unauthorized access to sensitive information, including passwords and personal data, compromising the integrity and confidentiality of the system. how_to_implement = In order to properly run this search, Splunk needs to ingest data from your osquery deployed agents with the [osx-attacks.conf](https://github.com/facebook/osquery/blob/experimental/packs/osx-attacks.conf#L599) pack enabled. Also the [TA-OSquery](https://github.com/d1vious/TA-osquery) must be deployed across your indexers and universal forwarders in order to have the osquery data populate the Alerts data model. annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]} known_false_positives = There might be some false positives as keyboard event taps are used by processes like Siri and Zoom video chat, for some good examples of processes to exclude please see [this](https://github.com/facebook/osquery/pull/5345#issuecomment-454639161) comment. @@ -9401,7 +9264,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic leverages Event ID 4698, `A scheduled task was created`, to identify the creation of a Scheduled Task with a suspicious, high entropy, Task Name. To achieve this, this analytic also leverages the `ut_shannon` function from the URL ToolBox Splunk application. Red teams and adversaries alike may abuse the Task Scheduler to create and start a remote Scheduled Task and obtain remote code execution. To achieve this goal, tools like Impacket or Crapmapexec, typically create a Scheduled Task with a random task name on the victim host. This hunting analytic may help defenders identify Scheduled Tasks created as part of a lateral movement attack. The entropy threshold `ut_shannon > 3` should be customized by users. The Command field can be used to determine if the task has malicious intent or not. +explanation = The following analytic detects the creation of a Scheduled Task with a high entropy, randomly generated name, leveraging Event ID 4698. It uses the `ut_shannon` function from the URL ToolBox Splunk application to measure the entropy of the Task Name. This activity is significant as adversaries often use randomly named Scheduled Tasks for lateral movement and remote code execution, employing tools like Impacket or CrackMapExec. If confirmed malicious, this could allow attackers to execute arbitrary code remotely, potentially leading to further compromise and persistence within the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA as well as the URL ToolBox application are also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.AE"]} known_false_positives = Legitimate applications may use random Scheduled Task names. @@ -9411,7 +9274,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic leverages Event ID 7045, `A new service was installed in the system`, to identify the installation of a Windows Service with a suspicious, high entropy, Service Name. To achieve this, this analytic also leverages the `ut_shannon` function from the URL ToolBox Splunk application. Red teams and adversaries alike may abuse the Service Control Manager to create and start a remote Windows Service and obtain remote code execution. To achieve this goal, some tools like Metasploit, Cobalt Strike and Impacket, typically create a Windows Service with a random service name on the victim host. This hunting analytic may help defenders identify Windows Services installed as part of a lateral movement attack. The entropy threshold `ut_shannon > 3` should be customized by users. The Service_File_Name field can be used to determine if the Windows Service has malicious intent or not. +explanation = The following analytic detects the installation of a Windows Service with a suspicious, high-entropy name, indicating potential malicious activity. It leverages Event ID 7045 and the `ut_shannon` function from the URL ToolBox Splunk application to identify services with random names. This behavior is significant as adversaries often use randomly named services for lateral movement and remote code execution. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. The Windows TA as well as the URL ToolBox application are also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.AE"]} known_false_positives = Legitimate applications may use random Windows Service names. @@ -9421,7 +9284,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytics identifies a big number of instance of ransomware notes (filetype e.g .txt, .html, .hta) file creation to the infected machine. This behavior is a good sensor if the ransomware note filename is quite new for security industry or the ransomware note filename is not in your ransomware lookup table list for monitoring. +explanation = The following analytic identifies the bulk creation of ransomware notes (e.g., .txt, .html, .hta files) on an infected machine. It leverages Sysmon EventCode 11 to detect multiple instances of these file types being created within a short time frame. This activity is significant as it often indicates an active ransomware attack, where the attacker is notifying the victim of the encryption. If confirmed malicious, this behavior could lead to widespread data encryption, rendering critical files inaccessible and potentially causing significant operational disruption. how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -9431,7 +9294,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 performing checks to identify anti-virus products installed on the endpoint. This technique is commonly found in malware and APT events where the adversary will map all running security applications or services. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic detects suspicious PowerShell script execution via EventCode 4104, specifically targeting checks for installed anti-virus products using WMI or PowerShell commands. This detection leverages PowerShell Script Block Logging to identify scripts containing keywords like "SELECT," "WMIC," "AntiVirusProduct," or "AntiSpywareProduct." This activity is significant as it is commonly used by malware and APT actors to map running security applications or services, potentially aiding in evasion techniques. If confirmed malicious, this could allow attackers to disable or bypass security measures, leading to further compromise of the endpoint. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.CM"]} known_false_positives = network administrator may used this command for checking purposes @@ -9441,7 +9304,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found where the adversary will identify services and system information on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic detects suspicious PowerShell activity via EventCode 4104, where WMI performs event queries to gather information on running processes or services. This detection leverages PowerShell Script Block Logging to identify specific WMI queries targeting system information classes like Win32_Bios and Win32_OperatingSystem. This activity is significant as it often indicates reconnaissance efforts by an adversary to profile the compromised machine. If confirmed malicious, the attacker could gain detailed system information, aiding in further exploitation or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Reconnaissance"], "mitre_attack": ["T1592", "T1059.001"], "nist": ["DE.AE"]} known_false_positives = network administrator may used this command for checking purposes @@ -9451,7 +9314,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious commandline designed to delete files or directory recursive using batch command. This technique was seen in ransomware (reddot) where it it tries to delete the files in recycle bin to impaire user from recovering deleted files. +explanation = The following analytic detects the execution of a batch command designed to recursively delete files or directories, a technique often used by ransomware like Reddot to delete files in the recycle bin and prevent recovery. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include specific flags for recursive and quiet deletions. This activity is significant as it indicates potential ransomware behavior aimed at data destruction. If confirmed malicious, it could lead to significant data loss and hinder recovery efforts, severely impacting business operations. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.004", "T1070"], "nist": ["DE.CM"]} known_false_positives = network operator may use this batch command to delete recursively a directory or files within directory @@ -9481,7 +9344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The search looks for modifications or alterations made to registry keys that have the potential to initiate the launch of an application or service during system startup. By monitoring and detecting modifications in these registry keys, we can identify suspicious or unauthorized changes that could be indicative of malicious activity. This proactive approach helps in safeguarding the system's integrity and security by promptly identifying and mitigating potential threats that aim to gain persistence or execute malicious actions during the startup process. +explanation = The following analytic identifies modifications to registry keys commonly used for persistence mechanisms. It leverages data from endpoint detection sources like Sysmon or Carbon Black, focusing on specific registry paths known to initiate applications or services during system startup. This activity is significant as unauthorized changes to these keys can indicate attempts to maintain persistence or execute malicious actions upon system boot. If confirmed malicious, this could allow attackers to achieve persistent access, execute arbitrary code, or maintain control over compromised systems, posing a severe threat to system integrity and security. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.CM"]} known_false_positives = There are many legitimate applications that must execute on system startup and will use these registry keys to accomplish that task. @@ -9491,7 +9354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for modifications to registry keys that can be used to elevate privileges. The registry keys under "Image File Execution Options" are used to intercept calls to an executable and can be used to attach malicious binaries to benign system binaries. +explanation = The following analytic detects modifications to registry keys under "Image File Execution Options" that can be used for privilege escalation. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths and values like GlobalFlag and Debugger. This activity is significant because attackers can use these modifications to intercept executable calls and attach malicious binaries to legitimate system binaries. If confirmed malicious, this could allow attackers to execute arbitrary code with elevated privileges, leading to potential system compromise and persistent access. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.012", "T1546"], "nist": ["DE.CM"]} known_false_positives = There are many legitimate applications that must execute upon system startup and will use these registry keys to accomplish that task. @@ -9501,7 +9364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a loading of dll using regsvr32 application with silent parameter and dllinstall execution. This technique was seen in several RAT malware similar to remcos, njrat and adversaries to load their malicious DLL on the compromised machine. This TTP may executed by normal 3rd party application so it is better to pivot by the parent process, parent command-line and command-line of the file that execute this regsvr32. +explanation = The following analytic detects the loading of a DLL using the regsvr32 application with the silent parameter and DLLInstall execution. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments and parent process details. This activity is significant as it is commonly used by RAT malware like Remcos and njRAT to load malicious DLLs on compromised machines. If confirmed malicious, this technique could allow attackers to execute arbitrary code, maintain persistence, and further compromise the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.AE"]} known_false_positives = Other third part application may used this parameter but not so common in base windows environment. @@ -9511,7 +9374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies Regsvr32.exe utilizing the silent switch to load DLLs. This technique has most recently been seen in IcedID campaigns to load its initial dll that will download the 2nd stage loader that will download and decrypt the config payload. The switch type may be either a hyphen `-` or forward slash `/`. This behavior is typically found with `-s`, and it is possible there are more switch types that may be used. \ During triage, review parallel processes and capture any artifacts that may have landed on disk. Isolate and contain the endpoint as necessary. +explanation = The following analytic detects the execution of Regsvr32.exe with the silent switch to load DLLs. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions containing the `-s` or `/s` switches. This activity is significant as it is commonly used in malware campaigns, such as IcedID, to stealthily load malicious DLLs. If confirmed malicious, this could allow an attacker to execute arbitrary code, download additional payloads, and potentially compromise the system further. Immediate investigation and endpoint isolation are recommended. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.AE"]} known_false_positives = minimal. but network operator can use this application to load dll. @@ -9521,7 +9384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the presence of a registry key related to the Remcos RAT agent on a host. This detection is made by a Splunk query to search for instances where the registry key "license" is found in the "Software\Remcos" path. This analytic combines information from two data models: Endpoint.Processes and Endpoint.Registry and retrieves process information such as user, process ID, process name, process path, destination, parent process name, parent process, and process GUID. This analytic also retrieves registry information such as registry path, registry key name, registry value name, registry value data, and process GUID. By joining the process GUID from the Endpoint.Processes data model with the process GUID from the Endpoint.Registry data model, the analytic identifies instances where the "license" registry key is found in the "Software\Remcos" path. This detection is important because it suggests that the host has been compromised by the Remcos RAT agent. Remcos is a well-known remote access Trojan that can be used by attackers to gain unauthorized access to systems and exfiltrate sensitive data. Identifying this behavior allows the SOC to take immediate action to remove the RAT agent and prevent further compromise. The impact of this attack can be severe, as the attacker can gain unauthorized access to the system, steal sensitive information, or use the compromised system as a launching point for further attacks. Next steps include using this analytic in conjunction with other security measures and threat intelligence to ensure accurate detection and response. +explanation = The following analytic detects the presence of a registry key associated with the Remcos RAT agent on a host. It leverages data from the Endpoint.Processes and Endpoint.Registry data models in Splunk, focusing on instances where the "license" key is found in the "Software\Remcos" path. This behavior is significant as it indicates potential compromise by the Remcos RAT, a remote access Trojan used for unauthorized access and data exfiltration. If confirmed malicious, the attacker could gain control over the system, steal sensitive information, or use the compromised host for further attacks. Immediate investigation and remediation are required. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9531,7 +9394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect file creation in remcos folder in appdata which is the keylog and clipboard logs that will be send to its c2 server. This is really a good TTP indicator that there is a remcos rat in the system that do keylogging, clipboard grabbing and audio recording. +explanation = The following analytic detects the creation of files in the Remcos folder within the AppData directory, specifically targeting keylog and clipboard log files. It leverages the Endpoint.Filesystem data model to identify .dat files created in paths containing "remcos." This activity is significant as it indicates the presence of the Remcos RAT, which performs keylogging, clipboard capturing, and audio recording. If confirmed malicious, this could lead to unauthorized data exfiltration and extensive surveillance capabilities for the attacker. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9541,7 +9404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for the remote desktop process mstsc.exe running on systems upon which it doesn't typically run. This is accomplished by filtering out all systems that are noted in the `common_rdp_source category` in the Assets and Identity framework. +explanation = The following analytic detects the execution of the remote desktop process (mstsc.exe) on systems where it is not typically run. This detection leverages data from Endpoint Detection and Response (EDR) agents, filtering out systems categorized as common RDP sources. This activity is significant because unauthorized use of mstsc.exe can indicate lateral movement or unauthorized remote access attempts. If confirmed malicious, this could allow an attacker to gain remote control of a system, potentially leading to data exfiltration, privilege escalation, or further network compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]} known_false_positives = Remote Desktop may be used legitimately by users on the network. @@ -9551,7 +9414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with arguments utilized to start a process on a remote endpoint by abusing the DCOM protocol. Specifically, this search looks for the abuse of ShellExecute and ExecuteShellCommand. Red Teams and adversaries alike may abuse DCOM and `powershell.exe` for lateral movement and remote code execution. +explanation = The following analytic detects the execution of `powershell.exe` with arguments used to start a process on a remote endpoint by abusing the DCOM protocol, specifically targeting ShellExecute and ExecuteShellCommand. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This activity is significant as it indicates potential lateral movement and remote code execution attempts by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary code remotely, escalate privileges, and move laterally within the network, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage DCOM to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9561,7 +9424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of PowerShell with arguments utilized to start a process on a remote endpoint by abusing the DCOM protocol. Specifically, this search looks for the abuse of ShellExecute and ExecuteShellCommand. Red Teams and adversaries alike may abuse DCOM for lateral movement and remote code execution. +explanation = The following analytic detects the execution of PowerShell commands that initiate a process on a remote endpoint via the DCOM protocol. It leverages PowerShell Script Block Logging (EventCode=4104) to identify the use of ShellExecute and ExecuteShellCommand. This activity is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this behavior could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and persistence within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage DCOM to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9571,7 +9434,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with arguments utilized to start a process on a remote endpoint by abusing the WinRM protocol. Specifically, this search looks for the abuse of the `Invoke-Command` commandlet. Red Teams and adversaries alike may abuse WinRM and `powershell.exe` for lateral movement and remote code execution. +explanation = The following analytic detects the execution of `powershell.exe` with arguments used to start a process on a remote endpoint via the WinRM protocol, specifically targeting the `Invoke-Command` cmdlet. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process telemetry. This activity is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and lateral spread within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WinRM and `Invoke-Command` to start a process on remote systems for system administration or automation use cases. However, this activity is usually limited to a small set of hosts or users. @@ -9581,7 +9444,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of PowerShell with arguments utilized to start a process on a remote endpoint by abusing the WinRM protocol. Specifically, this search looks for the abuse of the `Invoke-Command` commandlet. Red Teams and adversaries alike may abuse WinRM for lateral movement and remote code execution. +explanation = The following analytic detects the execution of PowerShell commands that use the `Invoke-Command` cmdlet to start a process on a remote endpoint via the WinRM protocol. It leverages PowerShell Script Block Logging (EventCode=4104) to identify such activities. This behavior is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this activity could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and persistence within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WinRM and `Invoke-Command` to start a process on remote systems for system administration or automation use cases. This activity is usually limited to a small set of hosts or users. In certain environments, tuning may not be possible. @@ -9591,7 +9454,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `winrs.exe` with command-line arguments utilized to start a process on a remote endpoint. Red Teams and adversaries alike may abuse the WinRM protocol and this binary for lateral movement and remote code execution. +explanation = The following analytic detects the execution of `winrs.exe` with command-line arguments used to start a process on a remote endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and lateral spread within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WinRM and WinRs to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9611,7 +9474,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` leveraging the `Invoke-WmiMethod` commandlet complemented with arguments utilized to start a process on a remote endpoint by abusing WMI. Red Teams and adversaries alike may abuse WMI and `powershell.exe` for lateral movement and remote code execution. +explanation = The following analytic detects the execution of `powershell.exe` using the `Invoke-WmiMethod` cmdlet to start a process on a remote endpoint via WMI. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process telemetry. This activity is significant as it indicates potential lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary code on remote systems, leading to further compromise and persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WWMI and powershell.exe to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9621,7 +9484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Invoke-WmiMethod` commandlet with arguments utilized to start a process on a remote endpoint by abusing WMI. Red Teams and adversaries alike may abuse WMI and this commandlet for lateral movement and remote code execution. +explanation = The following analytic detects the execution of the `Invoke-WmiMethod` commandlet with parameters used to start a process on a remote endpoint via WMI, leveraging PowerShell Script Block Logging (EventCode=4104). This method identifies specific script block text patterns associated with remote process instantiation. This activity is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and persistence within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage WWMI and powershell.exe to start a process on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9631,7 +9494,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain computers. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain computers for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell scripts to query Active Directory for domain computers. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `adsisearcher` and `objectcategory=computer` with methods like `findAll()` or `findOne()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to perform Active Directory discovery and gain situational awareness. If confirmed malicious, this could lead to further reconnaissance and potential lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use Adsisearcher for troubleshooting. @@ -9641,7 +9504,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover remote systems. The `computer` argument returns a list of all computers registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `dsquery.exe` with the `computer` argument, which is used to discover remote systems within a domain. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Remote system discovery is significant as it indicates potential reconnaissance activities by adversaries or Red Teams to map out network resources and Active Directory structures. If confirmed malicious, this activity could lead to further exploitation, lateral movement, and unauthorized access to critical systems within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -9651,7 +9514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to discover remote systems. The argument `domain computers /domain` returns a list of all domain computers. Red Teams and adversaries alike use net.exe to identify remote systems for situational awareness and Active Directory Discovery. +explanation = The following analytic identifies the execution of `net.exe` or `net1.exe` with command-line arguments used to discover remote systems, such as `domain computers /domain`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it indicates potential reconnaissance efforts by adversaries or Red Teams to map out networked systems and Active Directory structures. If confirmed malicious, this behavior could lead to further network exploitation, privilege escalation, or lateral movement within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -9661,7 +9524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command return a list of all the systems registered in the domain. Red Teams and adversaries alike may leverage WMI and wmic.exe to identify remote systems for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `wmic.exe` with specific command-line arguments used to discover remote systems within a domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to map out network resources and Active Directory structures. If confirmed malicious, this behavior could allow attackers to gain situational awareness, identify critical systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -9671,7 +9534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies usage of `wmic.exe` spawning a local or remote process, identified by the `node` switch. During triage, review parallel processes for additional commands executed. Look for any file modifications before and after `wmic.exe` execution. In addition, identify the remote endpoint and confirm execution or file modifications. Contain and isolate the endpoint as needed. +explanation = The following analytic detects the execution of `wmic.exe` with the `node` switch, indicating an attempt to spawn a local or remote process. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line arguments. This activity is significant as it may indicate lateral movement or remote code execution attempts by an attacker. If confirmed malicious, the attacker could gain remote control over the targeted system, execute arbitrary commands, and potentially escalate privileges or persist within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Administrators may use this legitimately to gather info from remote systems. Filter as needed. @@ -9681,7 +9544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytics identifies the resizing of shadowstorage by ransomware malware to avoid the shadow volumes being made again. this technique is an alternative by ransomware attacker than deleting the shadowstorage which is known alert in defensive team. one example of ransomware that use this technique is CLOP ransomware where it drops a .bat file that will resize the shadowstorage to minimum size as much as possible +explanation = The following analytic identifies the resizing of shadow storage volumes, a technique used by ransomware like CLOP to prevent the recreation of shadow volumes. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "vssadmin.exe" with parameters related to resizing shadow storage. This activity is significant as it indicates an attempt to hinder recovery efforts by manipulating shadow copies. If confirmed malicious, this could lead to successful ransomware deployment, making data recovery difficult and increasing the potential for data loss. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} known_false_positives = network admin can resize the shadowstorage for valid purposes. @@ -9701,7 +9564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious modification in registry entry to keep some malware data during its infection. This technique seen in several apt implant, malware and ransomware like REVIL where it keep some information like the random generated file extension it uses for all the encrypted files and ransomware notes file name in the compromised host. +explanation = The following analytic identifies suspicious modifications in the registry entry, specifically targeting paths used by malware like REVIL. It detects changes in registry paths such as `SOFTWARE\\WOW6432Node\\Facebook_Assistant` and `SOFTWARE\\WOW6432Node\\BlackLivesMatter`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry modifications linked to process GUIDs. This activity is significant as it indicates potential malware persistence mechanisms, often used by advanced persistent threats (APTs) and ransomware. If confirmed malicious, this could allow attackers to maintain persistence, encrypt files, and store critical ransomware-related information on compromised hosts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9711,7 +9574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Rubeus is a C# toolset for raw Kerberos interaction and abuses. It is heavily adapted from Benjamin Delpys Kekeo project and Vincent LE TOUXs MakeMeEnterpriseAdmin project. This analytic looks for the use of Rubeus command line arguments utilized in common Kerberos attacks like exporting and importing tickets, forging silver and golden tickets, requesting a TGT or TGS, kerberoasting, password spraying, etc. Red teams and adversaries alike use Rubeus for Kerberos attacks within Active Directory networks. Defenders should be aware that adversaries may customize the source code of Rubeus and modify the command line parameters. This would effectively bypass this analytic. +explanation = The following analytic detects the use of Rubeus command line parameters, a toolset for Kerberos attacks within Active Directory environments. It leverages Endpoint Detection and Response (EDR) data to identify specific command-line arguments associated with actions like ticket manipulation, kerberoasting, and password spraying. This activity is significant as Rubeus is commonly used by adversaries to exploit Kerberos for privilege escalation and lateral movement. If confirmed malicious, this could lead to unauthorized access, persistence, and potential compromise of sensitive information within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003", "T1558", "T1558.003", "T1558.004"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, legitimate applications may use the same command line parameters as Rubeus. Filter as needed. @@ -9721,7 +9584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic looks for a process accessing the winlogon.exe system process. The Splunk Threat Research team identified this behavior when using the Rubeus tool to monitor for and export kerberos tickets from memory. Before being able to export tickets. Rubeus will try to escalate privileges to SYSTEM by obtaining a handle to winlogon.exe before trying to monitor for kerberos tickets. Exporting tickets from memory is typically the first step for pass the ticket attacks. Red teams and adversaries alike may use the pass the ticket technique using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Defenders should be aware that adversaries may customize the source code of Rubeus to potentially bypass this analytic. +explanation = The following analytic detects a process accessing the winlogon.exe system process, indicative of the Rubeus tool attempting to export Kerberos tickets from memory. This detection leverages Sysmon EventCode 10 logs, focusing on processes obtaining a handle to winlogon.exe with specific access rights. This activity is significant as it often precedes pass-the-ticket attacks, where adversaries use stolen Kerberos tickets to move laterally within an environment. If confirmed malicious, this could allow attackers to bypass normal access controls, escalate privileges, and persist within the network, posing a severe security risk. how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may obtain a handle for winlogon.exe. Filter as needed @@ -9731,7 +9594,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic look for a spawned runas.exe process with a administrator user option parameter. This parameter was abused by adversaries, malware author or even red teams to gain elevated privileges in target host. This is a good hunting query to figure out privilege escalation tactics that may used for different stages like lateral movement but take note that administrator may use this command in purpose so its better to see other event context before and after this analytic. +explanation = The following analytic detects the execution of the runas.exe process with administrator user options. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it may indicate an attempt to gain elevated privileges, a common tactic in privilege escalation and lateral movement. If confirmed malicious, this could allow an attacker to execute commands with higher privileges, potentially leading to unauthorized access, data exfiltration, or further compromise of the target host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134", "T1134.001"], "nist": ["DE.AE"]} known_false_positives = A network operator or systems administrator may utilize an automated or manual execute this command that may generate false positives. filter is needed. @@ -9741,7 +9604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting detection identifies rundll32.exe with `control_rundll` within the command-line, loading a .cpl or another file type. Developed in relation to CVE-2021-40444. Rundll32.exe can also be used to execute Control Panel Item files (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a .cpl file also causes rundll32.exe to execute. \ This is written to be a bit more broad by not including .cpl. \ During triage, review parallel processes to identify any further suspicious behavior. +explanation = The following analytic identifies instances of rundll32.exe executing with `Control_RunDLL` in the command line, which is indicative of loading a .cpl or other file types. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant as rundll32.exe can be exploited to execute malicious Control Panel Item files, potentially linked to CVE-2021-40444. If confirmed malicious, this could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.AE"]} known_false_positives = This is a hunting detection, meant to provide a understanding of how voluminous control_rundll is within the environment. @@ -9751,7 +9614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies rundll32.exe with `control_rundll` within the command-line, loading a .cpl or another file type from windows\temp, programdata, or appdata. Developed in relation to CVE-2021-40444. Rundll32.exe can also be used to execute Control Panel Item files (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a .cpl file also causes rundll32.exe to execute. This is written to be a bit more broad by not including .cpl. The paths are specified, add more as needed. During triage, review parallel processes to identify any further suspicious behavior. +explanation = The following analytic detects the execution of rundll32.exe with the `Control_RunDLL` command, loading files from world-writable directories such as windows\temp, programdata, or appdata. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process command-line data and specific directory paths. This activity is significant as it may indicate an attempt to exploit CVE-2021-40444 or similar vulnerabilities, allowing attackers to execute arbitrary code. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, or persistent access within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = This may be tuned, or a new one related, by adding .cpl to command-line. However, it's important to look for both. Tune/filter as needed. @@ -9761,7 +9624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the suspicious Remote Thread execution of rundll32.exe to any process. This technique was seen in IcedID malware to execute its malicious code in normal process for defense evasion and to steal sensitive information in the compromised host. +explanation = The following analytic detects the creation of a remote thread by rundll32.exe into another process. It leverages Sysmon EventCode 8 logs, specifically monitoring SourceImage and TargetImage fields. This activity is significant as it is a common technique used by malware, such as IcedID, to execute malicious code within legitimate processes, aiding in defense evasion and data theft. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, and exfiltrate sensitive information from the compromised host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9771,7 +9634,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the suspicious Remote Thread execution of rundll32.exe process to "firefox.exe" and "chrome.exe" browser. This technique was seen in IcedID malware where it hooks the browser to parse banking information as user used the targetted browser process. +explanation = The following analytic detects the suspicious creation of a remote thread by rundll32.exe targeting browser processes such as firefox.exe, chrome.exe, iexplore.exe, and microsoftedgecp.exe. This detection leverages Sysmon EventCode 8, focusing on SourceImage and TargetImage fields to identify the behavior. This activity is significant as it is commonly associated with malware like IcedID, which hooks browsers to steal sensitive information such as banking details. If confirmed malicious, this could allow attackers to intercept and exfiltrate sensitive user data, leading to potential financial loss and privacy breaches. how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9781,7 +9644,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious rundll32.exe process having a http connection and do a dns query in some web domain. This technique was seen in IcedID malware where the rundll32 that execute its payload will contact amazon.com to check internet connect and to communicate to its C&C server to download config and other file component. +explanation = The following analytic detects a suspicious `rundll32.exe` process making HTTP connections and performing DNS queries to web domains. It leverages Sysmon EventCode 22 logs to identify these activities. This behavior is significant as it is commonly associated with IcedID malware, where `rundll32.exe` checks internet connectivity and communicates with C&C servers to download configurations and other components. If confirmed malicious, this activity could allow attackers to establish persistence, download additional payloads, and exfiltrate sensitive data, posing a severe threat to the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and eventcode = 22 dnsquery executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9791,7 +9654,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious rundll32 commandline to lock the workstation through command line. This technique was seen in CONTI leak tooling and script as part of its defense evasion. This technique is not a common practice to lock a screen and maybe a good indicator of compromise. +explanation = The following analytic detects the execution of the rundll32.exe command with the user32.dll,LockWorkStation parameter, which is used to lock the workstation via command line. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it is an uncommon method to lock a screen and has been observed in CONTI ransomware tooling for defense evasion. If confirmed malicious, this technique could indicate an attempt to evade detection and hinder incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -9801,7 +9664,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious rundll32 process that drops executable (.exe or .dll) files. This behavior seen in rundll32 process of IcedID that tries to drop copy of itself in temp folder or download executable drop it either appdata or programdata as part of its execution. +explanation = The following analytic detects a rundll32 process creating executable (.exe) or dynamic link library (.dll) files. It leverages Sysmon EventCode 11 to identify instances where rundll32.exe generates these file types. This activity is significant because rundll32 is often exploited by malware, such as IcedID, to drop malicious payloads in directories like Temp, AppData, or ProgramData. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, establish persistence, or escalate privileges within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, TargetFilename, and eventcode 11 executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9811,7 +9674,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious rundll32 commandline to clear shim cache. This technique is a anti-forensic technique to clear the cache taht are one important artifacts in terms of digital forensic during attacks or incident. This TTP is a good indicator that someone tries to evade some tools and clear foothold on the machine. +explanation = The following analytic detects the execution of a suspicious rundll32 command line used to clear the shim cache. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because clearing the shim cache is an anti-forensic technique aimed at evading detection and removing forensic artifacts. If confirmed malicious, this action could hinder incident response efforts, allowing an attacker to cover their tracks and maintain persistence on the compromised machine. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9821,7 +9684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe with no command line arguments and performing a network connection. It is unusual for rundll32.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of rundll32.exe without command line arguments, followed by a network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry and network traffic data. It is significant because rundll32.exe typically requires arguments to function, and its absence is often associated with malicious activity, such as Cobalt Strike. If confirmed malicious, this activity could indicate an attempt to establish unauthorized network connections, potentially leading to data exfiltration or further compromise of the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use a moved copy of rundll32, triggering a false positive. @@ -9831,7 +9694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe loading an export function by ordinal value. Adversaries may abuse rundll32.exe to proxy execution of malicious code. Using rundll32.exe, vice executing directly, may avoid triggering security tools that may not monitor execution of the rundll32.exe process because of allowlists or false positives from normal operations. Utilizing ordinal values makes it a bit more complicated for analysts to understand the behavior until the DLL is reviewed. +explanation = The following analytic detects rundll32.exe loading a DLL export function by ordinal value. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line executions. This behavior is significant because adversaries may use rundll32.exe to execute malicious code while evading security tools that do not monitor this process. If confirmed malicious, this activity could allow attackers to execute arbitrary code, potentially leading to system compromise, privilege escalation, or persistent access within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = False positives are possible with native utilities and third party applications. Filtering may be needed based on command-line, or add world writeable paths to restrict query. @@ -9851,7 +9714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This Splunk query identifies the use of Wake-on-LAN utilized by Ryuk ransomware. The Ryuk Ransomware uses the Wake-on-Lan feature to turn on powered off devices on a compromised network to have greater success encrypting them. This is a high fidelity indicator of Ryuk ransomware executing on an endpoint. Upon triage, isolate the endpoint. Additional file modification events will be within the users profile (\appdata\roaming) and in public directories (users\public\). Review all Scheduled Tasks on the isolated endpoint and across the fleet. Suspicious Scheduled Tasks will include a path to a unknown binary and those endpoints should be isolated until triaged. +explanation = The following analytic detects the use of Wake-on-LAN commands associated with Ryuk ransomware. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific process and command-line activities. This behavior is significant as Ryuk ransomware uses Wake-on-LAN to power on devices in a compromised network, increasing its encryption success rate. If confirmed malicious, this activity could lead to widespread ransomware encryption across multiple endpoints, causing significant operational disruption and data loss. Immediate isolation and thorough investigation of the affected endpoints are crucial to mitigate the impact. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"]} known_false_positives = Limited to no known false positives. @@ -9861,7 +9724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies access to SAM, SYSTEM or SECURITY databases' within the file path of `windows\system32\config` using Windows Security EventCode 4663. This particular behavior is related to credential access, an attempt to either use a Shadow Copy or recent CVE-2021-36934 to access the SAM database. The Security Account Manager (SAM) is a database file in Windows XP, Windows Vista, Windows 7, 8.1 and 10 that stores users' passwords. +explanation = The following analytic detects attempts to access the SAM, SYSTEM, or SECURITY database files within the `windows\system32\config` directory using Windows Security EventCode 4663. This detection leverages Windows Security Event logs to identify unauthorized access attempts. Monitoring this activity is crucial as it indicates potential credential access attempts, possibly exploiting vulnerabilities like CVE-2021-36934. If confirmed malicious, an attacker could extract user passwords, leading to unauthorized access, privilege escalation, and further compromise of the system. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"]} known_false_positives = Natively, `dllhost.exe` will access the files. Every environment will have additional native processes that do as well. Filter by process_name. As an aside, one can remove process_name entirely and add `Object_Name=*ShadowCopy*`. @@ -9891,7 +9754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect an application try to connect and create ADSI Object to do LDAP query. Every time an application connects to the directory and attempts to create an ADSI object, the Active Directory Schema is checked for changes. If it has changed since the last connection, the schema is downloaded and stored in a cache on the local computer either in %LOCALAPPDATA%\Microsoft\Windows\SchCache or %systemroot%\SchCache. We found this a good anomaly use case to detect suspicious application like blackmatter ransomware that use ADS object api to execute ldap query. having a good list of ldap or normal AD query tool used within the network is a good start to reduce the noise. +explanation = The following analytic detects an application attempting to connect and create an ADSI object to perform an LDAP query. It leverages Sysmon EventCode 11 to identify changes in the Active Directory Schema cache files located in %LOCALAPPDATA%\Microsoft\Windows\SchCache or %systemroot%\SchCache. This activity is significant as it can indicate the presence of suspicious applications, such as ransomware, using ADSI object APIs for LDAP queries. If confirmed malicious, this behavior could allow attackers to gather sensitive directory information, potentially leading to further exploitation or lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = normal application like mmc.exe and other ldap query tool may trigger this detections. @@ -9901,10 +9764,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the registration of suspicious tasks on Windows using the Windows Security EventCode 4698, "A scheduled task was created." It specifically looks for tasks registered through schtasks.exe or TaskService that have command arguments containing the string "HTTP." This behavior is often associated with malware or attacks that utilize Living off the Land binaries (lolbins) to download additional files or payloads to the compromised machine. \ -The search returns information about the task, such as the task name, command, author, enabled status, hidden status, and arguments. Upon triage, it is important to identify the source of the scheduled task, whether it was registered through schtasks.exe or TaskService. Review the details of the created task and the command to be executed. Capture relevant artifacts on disk and examine them. Additionally, identify any parallel processes occurring within the same timeframe to determine the source of the attack. \ -Implementing this analytic requires ingesting logs with information about task schedules, specifically Windows Security Log EventCode 4698, from your endpoints. It is recommended to tune and filter known instances of task schedules used in your environment to minimize false positives. \ -Detecting the registration of suspicious tasks with HTTP command arguments is valuable for a SOC as it indicates potential malicious activity or an attempt to establish persistence on the system. If a true positive is found, further investigation is warranted to analyze the nature and purpose of the scheduled task, identify any downloaded files or payloads, and mitigate the associated risks. The impact of a true positive can vary but may include data exfiltration, malware propagation, or unauthorized access to sensitive information. +explanation = The following analytic detects the creation of scheduled tasks on Windows systems that include HTTP command arguments, using Windows Security EventCode 4698. It identifies tasks registered via schtasks.exe or TaskService with HTTP in their command arguments. This behavior is significant as it often indicates malware activity or the use of Living off the Land binaries (lolbins) to download additional payloads. If confirmed malicious, this activity could lead to data exfiltration, malware propagation, or unauthorized access to sensitive information, necessitating immediate investigation and mitigation. how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9914,10 +9774,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of suspicious tasks in Windows, specifically tasks using the rundll32 command. It's implemented using Windows Security EventCode 4698 for A scheduled task was created, and looks for tasks executed either via schtasks.exe or TaskService. This behavior is worth identifying as it is commonly used by malware, such as TrickBot, that leverages rundll32 to execute its downloader. \ -If a true positive is found, it suggests an attacker is trying to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. \ -To implement this analytic, ensure you are ingesting logs with task schedule information from your endpoints. Be aware of potential false positives - legitimate uses of Task Scheduler in your environment may cause benign activities to be flagged. \ -Upon triage, review the scheduled task's source and the command to be executed. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. +explanation = The following analytic detects the creation of scheduled tasks in Windows that use the rundll32 command. It leverages Windows Security EventCode 4698, which logs the creation of scheduled tasks, and filters for tasks executed via rundll32. This activity is significant as it is a common technique used by malware, such as TrickBot, to persist in an environment or deliver additional payloads. If confirmed malicious, this could lead to data theft, ransomware deployment, or other damaging outcomes. Immediate investigation and mitigation are crucial to prevent further compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9927,8 +9784,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of suspicious tasks on a remote Windows endpoint using the at.exe command with command-line arguments. This technique is commonly used by red teams and adversaries for lateral movement and remote code execution. The at.exe binary leverages the deprecated AT protocol, which may still work on previous versions of Windows. Attackers can enable this protocol on demand by modifying a system registry key. It is important to consider potential false positives. While administrators may create scheduled tasks on remote systems, this activity is typically limited to a small set of hosts or users. \ -Identifying the creation of scheduled tasks on remote endpoints is crucial for a Security Operations Center (SOC) because it indicates potential unauthorized activity or an attacker attempting to establish persistence or execute malicious code. The impact of a true positive can be significant, leading to unauthorized access, data theft, or other damaging outcomes. During triage, investigate the source and purpose of the scheduled task, inspect relevant on-disk artifacts, and analyze concurrent processes to identify the extent of the attack and take appropriate response actions. +explanation = The following analytic detects the creation of scheduled tasks on remote Windows endpoints using the at.exe command. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process creation events involving at.exe with remote command-line arguments. Identifying this activity is significant for a SOC as it may indicate lateral movement or remote code execution attempts by an attacker. If confirmed malicious, this activity could lead to unauthorized access, persistence, or execution of malicious code, potentially resulting in data theft or further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053", "T1053.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may create scheduled tasks on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9938,7 +9794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic focuses on identifying the creation or deletion of scheduled tasks using the schtasks.exe utility with the corresponding command-line flags (-create or -delete). This technique has been notably associated with threat actors like Dragonfly and the SUNBURST attack against SolarWinds. The purpose of this analytic is to detect suspicious activity related to scheduled tasks that could indicate malicious intent or unauthorized system manipulation. By monitoring for these specific command-line flags, we can enhance our ability to identify potential threats and prevent attacks similar to the use of scheduled tasks in the BadRabbit Ransomware incident. +explanation = The following analytic identifies the creation or deletion of scheduled tasks using the schtasks.exe utility with the -create or -delete flags. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it can indicate unauthorized system manipulation or malicious intent, often associated with threat actors like Dragonfly and incidents such as the SUNBURST attack. If confirmed malicious, this activity could allow attackers to execute code, escalate privileges, or persist within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = While it is possible for legitimate scripts or administrators to trigger this behavior, filtering can be applied based on the parent process and application to reduce false positives. Analysts should reference the provided references to understand the context and threat landscape associated with this activity. @@ -9948,7 +9804,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects instances of 'schtasks.exe' being used to start a Scheduled Task on a remote endpoint. Adversaries often abuse the Task Scheduler for lateral movement and remote code execution. The search parameters include process details such as the process name, parent process, and command-line executions. Although legitimate administrators may start scheduled tasks on remote systems, this activity is usually limited to a small set of hosts or users. The findings from this analytic provide valuable insight into potentially malicious activities on an endpoint. +explanation = The following analytic detects the use of 'schtasks.exe' to start a Scheduled Task on a remote endpoint. This detection leverages Endpoint Detection and Response (EDR) data, focusing on process details such as process name, parent process, and command-line executions. This activity is significant as adversaries often abuse Task Scheduler for lateral movement and remote code execution. If confirmed malicious, this behavior could allow attackers to execute arbitrary code remotely, potentially leading to further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]} known_false_positives = Administrators may start scheduled tasks on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -9958,7 +9814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect when a Windows Scheduled Task is executed on demand via shell or command line. Adversaries often force the execution of their created Scheduled Tasks for persistent access or lateral movement within a compromised machine. This analytic is driven by process-related data, specifically process name, parent process, and command-line executions, sourced from endpoint logs. The search criteria focus on 'schtasks.exe' with an associated 'run' command. +explanation = The following analytic detects the execution of a Windows Scheduled Task on demand via the shell or command line. It leverages process-related data, including process name, parent process, and command-line executions, sourced from endpoint logs. The detection focuses on 'schtasks.exe' with an associated 'run' command. This activity is significant as adversaries often use it to force the execution of their created Scheduled Tasks for persistent access or lateral movement within a compromised machine. If confirmed malicious, this could allow attackers to maintain persistence or move laterally within the network, potentially leading to further compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]} known_false_positives = Bear in mind, administrators debugging Scheduled Task entries may trigger this analytic, necessitating fine-tuning and filtering to distinguish between legitimate and potentially malicious use of 'schtasks.exe'. @@ -9968,7 +9824,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect suspicious command-line arguments executed through 'schtasks.exe' to create a scheduled task on a remote endpoint. The analytic scans process data, checking for instances where 'schtasks.exe' has been used with specific command-line flags that suggest an attempt at lateral movement or remote code execution, common techniques employed by adversaries and red teams. Key data points include the process name, the specific command line used, the parent process name, the target destination, and the user involved. Also, timestamp data gives context to when these activities occurred. +explanation = The following analytic detects the use of 'schtasks.exe' to create a scheduled task on a remote system, indicating potential lateral movement or remote code execution. It leverages process data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line arguments and flags. This activity is significant as it may signify an adversary's attempt to persist or execute code remotely. If confirmed malicious, this could allow attackers to maintain access, execute arbitrary commands, or further infiltrate the network, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = While it is possible to have false positives, due to legitimate administrative tasks, these are usually limited and should still be validated and investigated as appropriate. @@ -9978,7 +9834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes a Splunk query to pinpoint potential threats by monitoring the 'schtasks.exe' command-line usage. This particular command, especially when used in tandem with 'shutdown' and '/create' flags, can suggest an adversarial force intending to schedule unwarranted system reboots. The query focuses on endpoint process data and retrieves details such as the process name, the parent process name, the destination, and the user involved. Essential to the investigation are the earliest and latest timestamps of these events, providing an activity timeline. Data such as the targeted host and initiating user offer valuable context for analyst. +explanation = The following analytic detects the use of 'schtasks.exe' to schedule forced system reboots using the 'shutdown' and '/create' flags. It leverages endpoint process data to identify instances where these specific command-line arguments are used. This activity is significant because it may indicate an adversary attempting to disrupt operations or force a reboot to execute further malicious actions. If confirmed malicious, this could lead to system downtime, potential data loss, and provide an attacker with an opportunity to execute additional payloads or evade detection. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = This analytic may also capture legitimate administrative activities such as system updates or maintenance tasks, which can be classified as false positives. Filter as needed. @@ -9988,7 +9844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect possible event trigger execution through screensaver registry entry modification for persistence or privilege escalation. This technique was seen in several APT and malware where they put the malicious payload path to the SCRNSAVE.EXE registry key to redirect the execution to their malicious payload path. This TTP is a good indicator that some attacker may modify this entry for their persistence and privilege escalation. +explanation = The following analytic detects modifications to the SCRNSAVE.EXE registry entry, indicating potential event trigger execution via screensaver settings for persistence or privilege escalation. It leverages registry activity data from the Endpoint data model to identify changes to the specified registry path. This activity is significant as it is a known technique used by APT groups and malware to maintain persistence or escalate privileges. If confirmed malicious, this could allow an attacker to execute arbitrary code with elevated privileges, leading to further system compromise and persistent access. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546", "T1546.002"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -9998,7 +9854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects any potential misuse of Windows Management Instrumentation (WMI) for malicious purposes since adversaries often use WMI to run scripts which allows them to carry out malicious activities without raising suspicion. The detection is made by monitoring the process 'scrcons.exe', which is essential to run WMI scripts. The detection is important because it proactively identifies and responds to potential threats that leverage WMI for malicious purposes that can lead to system compromise, data exfiltration, or the establishment of persistence within the environment. False positives might occur since administrators might occasionally use WMI to launch scripts for legitimate purposes. Therefore, you must distinguish between malicious and benign activities. +explanation = The following analytic detects the execution of scripts via Windows Management Instrumentation (WMI) by monitoring the process 'scrcons.exe'. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events. WMI-based script execution is significant because adversaries often use it to perform malicious activities stealthily, such as system compromise, data exfiltration, or establishing persistence. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, or maintain long-term access to the environment. Analysts should differentiate between legitimate administrative use and potential threats. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, administrators may use wmi to launch scripts for legitimate purposes. Filter as needed. @@ -10008,7 +9864,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious sdclt.exe registry modification. This technique is commonly seen when attacker try to bypassed UAC by using sdclt.exe application by modifying some registry that sdclt.exe tries to open or query with payload file path on it to be executed. +explanation = The following analytic detects suspicious modifications to the sdclt.exe registry, a technique often used to bypass User Account Control (UAC). It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific registry paths and values associated with sdclt.exe. This activity is significant because UAC bypasses can allow attackers to execute payloads with elevated privileges without user consent. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, and potential persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = Limited to no false positives are expected. @@ -10018,7 +9874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect the execution of sdelete.exe application sysinternal tools. This tool is one of the most use tool of malware and adversaries to remove or clear their tracks and artifact in the targetted host. This tool is designed to delete securely a file in file system that remove the forensic evidence on the machine. A good TTP query to check why user execute this application which is not a common practice. +explanation = The following analytic detects the execution of the sdelete.exe application, a Sysinternals tool often used by adversaries to securely delete files and remove forensic evidence from a targeted host. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. Monitoring this activity is crucial as sdelete.exe is not commonly used in regular operations and its presence may indicate an attempt to cover malicious activities. If confirmed malicious, this could lead to the loss of critical forensic data, hindering incident response and investigation efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]} known_false_positives = user may execute and use this application @@ -10028,7 +9884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies searchprotocolhost.exe with no command line arguments and with a network connection. It is unusual for searchprotocolhost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. searchprotocolhost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects instances of searchprotocolhost.exe running without command line arguments but with an active network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network traffic data. It is significant because searchprotocolhost.exe typically runs with specific command line arguments, and deviations from this norm can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers to establish network connections for command and control, potentially leading to data exfiltration or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process. @@ -10038,7 +9894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a potential usage of secretsdump.py tool for dumping credentials (ntlm hash) from a copy of ntds.dit and SAM.Security,SYSTEM registrry hive. This technique was seen in some attacker that dump ntlm hashes offline after having a copy of ntds.dit and SAM/SYSTEM/SECURITY registry hive. +explanation = The following analytic detects the potential use of the secretsdump.py tool to dump NTLM hashes from a copy of ntds.dit and the SAM, SYSTEM, and SECURITY registry hives. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns and process names associated with secretsdump.py. This activity is significant because it indicates an attempt to extract sensitive credential information offline, which is a common post-exploitation technique. If confirmed malicious, this could allow an attacker to obtain NTLM hashes, facilitating further lateral movement and potential privilege escalation within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10048,11 +9904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `powershell.exe` usage, using Script Block Logging EventCode 4104, related to querying the domain for Service Principle Names. typically, this is a precursor activity related to kerberoasting or the silver ticket attack. \ -What is a ServicePrincipleName? \ -A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name. \ -The following analytic identifies the use of KerberosRequestorSecurityToken class within the script block. Using .NET System.IdentityModel.Tokens.KerberosRequestorSecurityToken class in PowerShell is the equivelant of using setspn.exe. \ -During triage, review parallel processes for further suspicious activity. +explanation = The following analytic detects the use of `powershell.exe` to query the domain for Service Principal Names (SPNs) using Script Block Logging EventCode 4104. It identifies the use of the KerberosRequestorSecurityToken class within the script block, which is equivalent to using setspn.exe. This activity is significant as it often precedes kerberoasting or silver ticket attacks, which can lead to credential theft. If confirmed malicious, attackers could leverage this information to escalate privileges or persist within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558.003"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however filter as needed. @@ -10062,14 +9914,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `setspn.exe` usage related to querying the domain for Service Principle Names. typically, this is a precursor activity related to kerberoasting or the silver ticket attack. \ -What is a ServicePrincipleName? \ -A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name. \ -Example usage includes the following \ -* setspn -T offense -Q */* 1. setspn -T attackrange.local -F -Q MSSQLSvc/* 1. setspn -Q */* > allspns.txt 1. setspn -q \ -Values \ -* -F = perform queries at the forest, rather than domain level 1. -T = perform query on the specified domain or forest (when -F is also used) 1. -Q = query for existence of SPN \ -During triage, review parallel processes for further suspicious activity. +explanation = The following analytic detects the use of `setspn.exe` to query the domain for Service Principal Names (SPNs). This detection leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with `setspn.exe`. Monitoring this activity is crucial as it often precedes Kerberoasting or Silver Ticket attacks, which can lead to credential theft. If confirmed malicious, an attacker could use the gathered SPNs to escalate privileges or persist within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558.003"], "nist": ["DE.CM"]} known_false_positives = False positives may be caused by Administrators resetting SPNs or querying for SPNs. Filter as needed. @@ -10079,7 +9924,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of `svc-exe` with Cobalt Strike. The behavior typically follows after an adversary has already gained initial access and is escalating privileges. Using `svc-exe`, a randomly named binary will be downloaded from the remote Teamserver and placed on disk within `C:\Windows\400619a.exe`. Following, the binary will be added to the registry under key `HKLM\System\CurrentControlSet\Services\400619a\` with multiple keys and values added to look like a legitimate service. Upon loading, `services.exe` will spawn the randomly named binary from `\\127.0.0.1\ADMIN$\400619a.exe`. The process lineage is completed with `400619a.exe` spawning rundll32.exe, which is the default `spawnto_` value for Cobalt Strike. The `spawnto_` value is arbitrary and may be any process on disk (typically system32/syswow64 binary). The `spawnto_` process will also contain a network connection. During triage, review parallel procesess and identify any additional file modifications. +explanation = The following analytic identifies the execution of a randomly named binary via `services.exe`, indicative of privilege escalation using Cobalt Strike's `svc-exe`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process lineage and command-line executions. This activity is significant as it often follows initial access, allowing adversaries to escalate privileges and establish persistence. If confirmed malicious, this behavior could enable attackers to execute arbitrary code, maintain long-term access, and potentially move laterally within the network, posing a severe threat to the organization's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as `services.exe` should never spawn a process from `ADMIN$`. Filter as needed. @@ -10089,7 +9934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `services.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the Service Control Manager and creating a remote malicious service, the executed command is spawned as a child process of `services.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of services.exe that are part of the LOLBAS project can help defenders identify lateral movement activity. +explanation = The following analytic identifies `services.exe` spawning a LOLBAS (Living Off the Land Binaries and Scripts) execution process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where `services.exe` is the parent process. This activity is significant because adversaries often abuse the Service Control Manager to execute malicious code via native Windows binaries, facilitating lateral movement. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may trigger this behavior, filter as needed. @@ -10109,7 +9954,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for shim database files being written to default directories. The sdbinst.exe application is used to install shim database files (.sdb). According to Microsoft, a shim is a small library that transparently intercepts an API, changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. +explanation = The following analytic detects the creation of shim database files (.sdb) in default directories using the sdbinst.exe application. It leverages filesystem activity data from the Endpoint.Filesystem data model to identify file writes to the Windows\AppPatch\Custom directory. This activity is significant because shims can intercept and alter API calls, potentially allowing attackers to bypass security controls or execute malicious code. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, or persistent access within the environment. how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.011", "T1546"], "nist": ["DE.CM"]} known_false_positives = Because legitimate shim files are created and used all the time, this event, in itself, is not suspicious. However, if there are other correlating events, it may warrant further investigation. @@ -10119,7 +9964,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search detects the process execution and arguments required to silently create a shim database. The sdbinst.exe application is used to install shim database files (.sdb). A shim is a small library which transparently intercepts an API, changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. +explanation = The following analytic detects the execution of sdbinst.exe with parameters indicative of silently creating a shim database. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line arguments. This activity is significant because shim databases can be used to intercept and manipulate API calls, potentially allowing attackers to bypass security controls or achieve persistence. If confirmed malicious, this could enable unauthorized code execution, privilege escalation, or persistent access to the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.011", "T1546"], "nist": ["DE.CM"]} known_false_positives = None identified @@ -10129,10 +9974,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes Windows Security EventCode 4698, "A scheduled task was created," and EventCode 4699, "A scheduled task was deleted," to identify scheduled tasks that are created and deleted within a short time frame of less than 30 seconds. This behavior is indicative of a potential lateral movement attack where the Task Scheduler is abused to achieve code execution. Both red teams and adversaries may exploit the Task Scheduler for lateral movement and remote code execution. \ -To implement this analytic, ensure that you are ingesting Windows Security Event Logs with EventCode 4698 enabled. Additionally, the Windows TA (Technology Add-on) is required to parse and extract the necessary information from the logs. \ -It's important to note that while uncommon, legitimate applications may create and delete scheduled tasks within a short duration. Analysts should filter the results based on the specific context and environment to reduce false positives. \ -Identifying short-lived scheduled tasks is valuable for a SOC as it can indicate malicious activities attempting to move laterally or execute unauthorized code on Windows systems. By detecting and investigating these events, security analysts can respond promptly to prevent further compromise and mitigate potential risks. The impact of a true positive could range from unauthorized access to data exfiltration or the execution of malicious payloads. +explanation = The following analytic detects the creation and deletion of scheduled tasks within a short time frame (less than 30 seconds) using Windows Security EventCodes 4698 and 4699. This behavior is identified by analyzing Windows Security Event Logs and leveraging the Windows TA for parsing. Such activity is significant as it may indicate lateral movement or remote code execution attempts by adversaries. If confirmed malicious, this could lead to unauthorized access, data exfiltration, or execution of malicious payloads, necessitating prompt investigation and response by security analysts. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005"], "nist": ["DE.CM"]} known_false_positives = Although uncommon, legitimate applications may create and delete a Scheduled Task within 30 seconds. Filter as needed. @@ -10142,7 +9984,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects the creation and deletion of accounts in a short time period to identify potential threats earlier and take appropriate actions to mitigate the risks. Helps prevent or minimize the potential damage caused by unauthorized access or malicious activities within the environment. This detection is made by a Splunk query that searches for events with the result IDs 4720 and 4726 in the "Change" data model. The query then groups the results by time, user, and destination. The result is filtered to only include events with the specified result IDs. The "transaction" command is used to group events that occur within a specified time span and have the same user but are not connected. Finally, the relevant information such as the first and last time of the event, the count, user, destination, and result ID are displayed in a table. This detection is important because it suggests that an attacker is attempting to create and delete accounts rapidly, potentially to cover their tracks or gain unauthorized access. The impact of such an attack can include unauthorized access to sensitive data, privilege escalation, or the ability to carry out further malicious activities within the environment. Next steps include investigating the events flagged by the analytic, review the account creation and deletion activities, and analyze any associated logs or artifacts to determine the intent and impact of the attack. +explanation = The following analytic detects the rapid creation and deletion of Windows accounts within a short time frame. It leverages the "Change" data model in Splunk, specifically monitoring events with result IDs 4720 (account creation) and 4726 (account deletion). This behavior is significant as it may indicate an attacker attempting to create and remove accounts quickly to evade detection or gain unauthorized access. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, or further malicious actions within the environment. Immediate investigation of flagged events is crucial to mitigate potential damage. how_to_implement = This search requires you to have enabled your Group Management Audit Logs in your Local Windows Security Policy and be ingesting those logs. More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/ annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]} known_false_positives = It is possible that an administrator created and deleted an account in a short time period. Verifying activity with an administrator is advised. @@ -10152,7 +9994,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious modification of registry that may related to UAC bypassed. This registry will be trigger once the attacker abuse the silentcleanup task schedule to gain high privilege execution that will bypass User control account. +explanation = The following analytic detects suspicious modifications to the registry that may indicate a UAC (User Account Control) bypass attempt via the SilentCleanup task. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry changes in the path "*\\Environment\\windir" with executable values. This activity is significant as it can allow an attacker to gain high-privilege execution without user consent, bypassing UAC protections. If confirmed malicious, this could lead to unauthorized administrative access, enabling further system compromise and persistence. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10162,7 +10004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a behavior where a process name consists only of a single letter that helps to detect potential threats earlier and mitigate the risks. This detection is important because it indicates the presence of malware or an attacker attempting to evade detection by using a process name that is difficult to identify or track so that he can carry out malicious activities such as data theft or ransomware attacks. False positives might occur since there might be legitimate uses of single-letter process names in your environment. Next steps include reviewing the process details and investigating any suspicious activity upon triage. +explanation = The following analytic detects processes with names consisting of a single letter, which is often indicative of malware or an attacker attempting to evade detection. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because attackers use such techniques to obscure their presence and carry out malicious activities like data theft or ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized access, data exfiltration, or system compromise. Immediate investigation is required to determine the legitimacy of the process. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.CM"]} known_false_positives = Single-letter executables are not always malicious. Investigate this activity with your normal incident-response process. @@ -10172,7 +10014,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Microsoft Software Licensing User Interface Tool, `slui.exe`, elevating access using the `-verb runas` function. This particular bypass utilizes a registry key/value. Identified by two sources, the registry keys are `HKCU\Software\Classes\exefile\shell` and `HKCU\Software\Classes\launcher.Systemsettings\Shell\open\command`. To simulate this behavior, multiple POC are available. The analytic identifies the use of `runas` by `slui.exe`. +explanation = The following analytic detects the execution of the Microsoft Software Licensing User Interface Tool (`slui.exe`) with elevated privileges using the `-verb runas` function. This activity is identified through logs from Endpoint Detection and Response (EDR) agents, focusing on specific registry keys and command-line parameters. This behavior is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to gain elevated access and execute malicious actions with higher privileges. If confirmed malicious, this could lead to unauthorized system changes, data exfiltration, or further compromise of the affected endpoint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present as this is not commonly used by legitimate applications. @@ -10182,7 +10024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Microsoft Software Licensing User Interface Tool, `slui.exe`, spawning a child process. This behavior is associated with publicly known UAC bypass. `slui.exe` is commonly associated with software updates and is most often spawned by `svchost.exe`. The `slui.exe` process should not have child processes, and any processes spawning from it will be running with elevated privileges. During triage, review the child process and additional parallel processes. Identify any file modifications that may have lead to the bypass. +explanation = The following analytic detects the Microsoft Software Licensing User Interface Tool (`slui.exe`) spawning a child process. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where `slui.exe` is the parent process. This activity is significant because `slui.exe` should not typically spawn child processes, and doing so may indicate a UAC bypass attempt, leading to elevated privileges. If confirmed malicious, an attacker could leverage this to execute code with elevated privileges, potentially compromising the system's security and gaining unauthorized access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = Certain applications may spawn from `slui.exe` that are legitimate. Filtering will be needed to ensure proper monitoring. @@ -10202,7 +10044,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious child process, `rundll32.exe`, with no command-line arguments being spawned from `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to spawn a process. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events. +explanation = The following analytic detects the spawning of `rundll32.exe` without command-line arguments by `spoolsv.exe`, which is unusual and potentially indicative of exploitation attempts like CVE-2021-34527 (PrintNightmare). This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where `spoolsv.exe` is the parent process. This activity is significant as `spoolsv.exe` typically does not spawn other processes, and such behavior could indicate an active exploitation attempt. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence on the compromised endpoint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = Limited false positives have been identified. There are limited instances where `rundll32.exe` may be spawned by a legitimate print driver. @@ -10222,7 +10064,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious behavior related to PrintNightmare, or CVE-2021-34527 previously (CVE-2021-1675), to gain privilege escalation on the vulnerable machine. This exploit attacks a critical Windows Print Spooler Vulnerability to elevate privilege. This detection is to look for suspicious process access made by the spoolsv.exe that may related to the attack. +explanation = The following analytic detects suspicious process access by spoolsv.exe, potentially indicating exploitation of the PrintNightmare vulnerability (CVE-2021-34527). It leverages Sysmon EventCode 10 to identify when spoolsv.exe accesses critical system files or processes like rundll32.exe with elevated privileges. This activity is significant as it may signal an attempt to gain unauthorized privilege escalation on a vulnerable machine. If confirmed malicious, an attacker could achieve elevated privileges, leading to further system compromise, persistent access, or unauthorized control over the affected environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with process access event where SourceImage, TargetImage, GrantedAccess and CallTrace executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of spoolsv.exe. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = Unknown. Filter as needed. @@ -10232,7 +10074,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a `.dll` being written by `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write a `.dll`. Current POC code used will write the suspicious DLL to disk within a path of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events. +explanation = The following analytic detects `spoolsv.exe` writing a `.dll` file, which is unusual behavior and may indicate exploitation of vulnerabilities like CVE-2021-34527 (PrintNightmare). This detection leverages the Endpoint datamodel, specifically monitoring process and filesystem events to identify `.dll` file creation within the `\spool\drivers\x64\` path. This activity is significant as it may signify an attacker attempting to execute malicious code via the Print Spooler service. If confirmed malicious, this could lead to unauthorized code execution and potential system compromise. Immediate endpoint isolation and further investigation are recommended. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = Unknown. @@ -10242,7 +10084,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a `.dll` being written by `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously(CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write a `.dll`. Current POC code used will write the suspicious DLL to disk within a path of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events. +explanation = The following analytic detects `spoolsv.exe` writing a `.dll` file, which is unusual behavior and may indicate exploitation of vulnerabilities like CVE-2021-34527 (PrintNightmare). This detection leverages Sysmon Event ID 11 to monitor file creation events in the `\spool\drivers\x64\` directory. This activity is significant because `spoolsv.exe` typically does not write DLL files, and such behavior could signify an ongoing attack. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence on the compromised system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]} known_false_positives = Limited false positives. Filter as needed. @@ -10252,7 +10094,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious file creation of sqlite3.dll in %temp% folder. This behavior was seen in IcedID malware where it download sqlite module to parse browser database like for chrome or firefox to stole browser information related to bank, credit card or credentials. +explanation = The following analytic detects the creation of sqlite3.dll files in the %temp% folder. It leverages Sysmon EventCode 11 to identify when these files are written to the temporary directory. This activity is significant because it is associated with IcedID malware, which uses the sqlite3 module to parse browser databases and steal sensitive information such as banking details, credit card information, and credentials. If confirmed malicious, this behavior could lead to significant data theft and compromise of user accounts. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1005"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10262,7 +10104,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This correlation rule focuses on detecting potential threats associated with MITRE ATT&CK T1649 (Steal or Forge Authentication Certificates). The rule is designed to identify instances where 5 or more analytics related to Windows Certificate Services analytic story that are triggered within a specified time frame, which may indicate a potential attack in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. +explanation = The following analytic identifies potential threats related to the theft or forgery of authentication certificates. It detects when five or more analytics from the Windows Certificate Services story trigger within a specified timeframe. This detection leverages aggregated risk scores and event counts from the Risk data model. This activity is significant as it may indicate an ongoing attack aimed at compromising authentication mechanisms. If confirmed malicious, attackers could gain unauthorized access to sensitive systems and data, potentially leading to severe security breaches. how_to_implement = The Windows Certificate Services analytic story must have 5 or more analytics enabled. In addition, ensure data is being logged that is required. Modify the correlation as needed based on volume of noise related to the other analytics. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on automated tooling or system administrators. Filter as needed. @@ -10282,7 +10124,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries need to create a new computer account name and rename it to match the name of a domain controller account without the ending '$'. In Windows Active Directory environments, computer account names always end with `$`. This analytic leverages Event Id 4781, `The name of an account was changed`, to identify a computer account rename event with a suspicious name that does not terminate with `$`. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation. +explanation = The following analytic detects a suspicious computer account name change in Active Directory. It leverages Event ID 4781, which logs account name changes, to identify instances where a computer account name is changed to one that does not end with a `$`. This behavior is significant as it may indicate an attempt to exploit CVE-2021-42278 and CVE-2021-42287, which can lead to domain controller impersonation and privilege escalation. If confirmed malicious, this activity could allow an attacker to gain elevated privileges and potentially control the domain. 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.CM"]} known_false_positives = Renaming a computer account name to a name that not end with '$' is highly unsual and may not have any legitimate scenarios. @@ -10292,7 +10134,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious copy of file from systemroot folder of the windows OS. This technique is commonly used by APT or other malware as part of execution (LOLBIN) to run its malicious code using the available legitimate tool in OS. this type of event may seen or may execute of normal user in some instance but this is really a anomaly that needs to be check within the network. +explanation = The following analytic detects suspicious file copy operations from the System32 or SysWow64 directories, often indicative of malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes initiated by command-line tools like cmd.exe or PowerShell. This behavior is significant as it may indicate an attempt to execute malicious code using legitimate system tools (LOLBIN). If confirmed malicious, this activity could allow an attacker to execute arbitrary code, potentially leading to system compromise or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.003", "T1036"], "nist": ["DE.CM"]} known_false_positives = every user may do this event but very un-ussual. @@ -10302,7 +10144,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of a curl contacting suspicious remote domains to checkin to Command And Control servers or download further implants. In the context of Silver Sparrow, curl is identified contacting s3.amazonaws.com. This particular behavior is common with MacOS adware-malicious software. +explanation = The following analytic detects the use of the curl command contacting suspicious remote domains, such as s3.amazonaws.com, which is indicative of Command and Control (C2) activity or downloading further implants. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant as it may indicate the presence of MacOS adware or other malicious software attempting to establish persistence or exfiltrate data. If confirmed malicious, this could allow attackers to maintain control over the compromised system and deploy additional payloads. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = Unknown. Filter as needed. @@ -10312,7 +10154,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies DLLHost.exe with no command line arguments. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects instances of DLLHost.exe executing without command line arguments. This behavior is unusual and often associated with malicious activities, such as those performed by Cobalt Strike. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because DLLHost.exe typically requires arguments to function correctly, and its absence may indicate an attempt to evade detection. If confirmed malicious, this could lead to unauthorized actions like credential dumping or file manipulation, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process. @@ -10322,7 +10164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect suspicious driver loaded paths. This technique is commonly used by malicious software like coin miners (xmrig) to register its malicious driver from notable directories where executable or drivers do not commonly exist. During triage, validate this driver is for legitimate business use. Review the metadata and certificate information. Unsigned drivers from non-standard paths is not normal, but occurs. In addition, review driver loads into `ntoskrnl.exe` for possible other drivers of interest. Long tail analyze drivers by path (outside of default, and in default) for further review. +explanation = The following analytic detects the loading of drivers from suspicious paths, which is a technique often used by malicious software such as coin miners (e.g., xmrig). It leverages Sysmon EventCode 6 to identify drivers loaded from non-standard directories. This activity is significant because legitimate drivers typically reside in specific system directories, and deviations may indicate malicious activity. If confirmed malicious, this could allow an attacker to execute code at the kernel level, potentially leading to privilege escalation, persistence, or further system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the driver loaded and Signature from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543.003", "T1543"], "nist": ["DE.CM"]} known_false_positives = Limited false positives will be present. Some applications do load drivers @@ -10332,7 +10174,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = 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. +explanation = The following analytic detects the shutdown of the Windows Event Log service using Windows Event ID 1100. This event is logged every time the service stops, including during normal system shutdowns. Monitoring this activity is crucial as it can indicate attempts to cover tracks or disable logging. If confirmed malicious, an attacker could hide their activities, making it difficult to trace their actions and investigate further incidents. Analysts should verify if the shutdown was planned and review other alerts and data sources for additional suspicious behavior. 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.001"], "nist": ["DE.AE"]} known_false_positives = It is possible the Event Logging service gets shut down due to system errors or legitimately administration tasks. Filter as needed. @@ -10342,7 +10184,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies gpupdate.exe with no command line arguments. It is unusual for gpupdate.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. gpupdate.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of gpupdate.exe without any command line arguments. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. It is significant because gpupdate.exe typically runs with specific arguments, and its execution without them is often associated with malicious activities, such as those performed by Cobalt Strike. If confirmed malicious, this activity could indicate an attempt to execute unauthorized commands or scripts, potentially leading to further system compromise or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process. @@ -10352,7 +10194,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious rundll32.exe commandline to execute dll file. This technique was seen in IcedID malware to load its payload dll with the following parameter to load encrypted dll payload which is the license.dat. +explanation = The following analytic detects a suspicious `rundll32.exe` command line used to execute a DLL file, a technique associated with IcedID malware. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing the pattern `*/i:*`. This activity is significant as it indicates potential malware attempting to load an encrypted DLL payload, often named `license.dat`. If confirmed malicious, this could allow attackers to execute arbitrary code, leading to further system compromise and potential data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = limitted. this parameter is not commonly used by windows application but can be used by the network operator. @@ -10362,7 +10204,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious creation of image in appdata folder made by process that also has a file reference in appdata folder. This technique was seen in remcos rat that capture screenshot of the compromised machine and place it in the appdata and will be send to its C2 server. This TTP is really a good indicator to check that process because it is in suspicious folder path and image files are not commonly created by user in this folder path. +explanation = The following analytic detects the creation of image files in the AppData folder by processes that also have a file reference in the same folder. It leverages data from the Endpoint.Processes and Endpoint.Filesystem datamodels to identify this behavior. This activity is significant because it is commonly associated with malware, such as the Remcos RAT, which captures screenshots and stores them in the AppData folder before exfiltrating them to a command-and-control server. If confirmed malicious, this activity could indicate unauthorized data capture and exfiltration, compromising sensitive information and user privacy. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10372,7 +10214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries will request and obtain a Kerberos Service Ticket (TGS) with a domain controller computer account as the Service Name. This Service Ticket can be then used to take control of the domain controller on the final part of the attack. This analytic leverages Event Id 4769, `A Kerberos service ticket was requested`, to identify an unusual TGS request where the Account_Name requesting the ticket matches the Service_Name field. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation. +explanation = The following analytic detects suspicious Kerberos Service Ticket (TGS) requests where the requesting account name matches the service name, potentially indicating an exploitation attempt of CVE-2021-42278 and CVE-2021-42287. This detection leverages Event ID 4769 from Domain Controller and Kerberos events. Such activity is significant as it may represent an adversary attempting to escalate privileges by impersonating a domain controller. If confirmed malicious, this could allow an attacker to take control of the domain controller, leading to complete domain compromise and unauthorized access to sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.CM"]} known_false_positives = We have tested this detection logic with ~2 million 4769 events and did not identify false positives. However, they may be possible in certain environments. Filter as needed. @@ -10382,8 +10224,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search, detects execution of suspicious bash commands from various commonly leveraged bash scripts like (AutoSUID, LinEnum, LinPeas) to perform discovery of possible paths of privilege execution, password files, vulnerable directories, executables and file permissions on a Linux host. \ -The search logic specifically looks for high number of distinct commands run in a short period of time. +explanation = The following analytic detects the execution of suspicious bash commands commonly used in scripts like AutoSUID, LinEnum, and LinPeas for system discovery on a Linux host. It leverages Endpoint Detection and Response (EDR) data, specifically looking for a high number of distinct commands executed within a short time frame. This activity is significant as it often precedes privilege escalation or other malicious actions. If confirmed malicious, an attacker could gain detailed system information, identify vulnerabilities, and potentially escalate privileges, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.004"], "nist": ["DE.CM"]} known_false_positives = Unless an administrator is using these commands to troubleshoot or audit a system, the execution of these commands should be monitored. @@ -10393,7 +10234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a renamed instance of microsoft.workflow.compiler.exe. Microsoft.workflow.compiler.exe is natively found in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 and is rarely utilized. When investigating, identify the executed code on disk and review. A spawned child process from microsoft.workflow.compiler.exe is uncommon. In any instance, microsoft.workflow.compiler.exe spawning from an Office product or any living off the land binary is highly suspect. +explanation = The following analytic detects the renaming of microsoft.workflow.compiler.exe, a rarely used executable typically located in C:\Windows\Microsoft.NET\Framework64\v4.0.30319. This detection leverages Endpoint Detection and Response (EDR) data, focusing on process names and original file names. This activity is significant because renaming this executable can indicate an attempt to evade security controls. If confirmed malicious, an attacker could use this renamed executable to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1127", "T1036.003"], "nist": ["DE.AE"]} known_false_positives = Although unlikely, some legitimate applications may use a moved copy of microsoft.workflow.compiler.exe, triggering a false positive. @@ -10413,7 +10254,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies msbuild.exe executing from a non-standard path. Msbuild.exe is natively found in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Instances of Visual Studio will run a copy of msbuild.exe. A moved instance of MSBuild is suspicious, however there are instances of build applications that will move or use a copy of MSBuild. +explanation = The following analytic detects the execution of msbuild.exe from a non-standard path. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that deviate from typical msbuild.exe locations. This activity is significant because msbuild.exe is commonly abused by attackers to execute malicious code, and running it from an unusual path can indicate an attempt to evade detection. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to system compromise and further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1127", "T1036.003", "T1127.001"], "nist": ["DE.CM"]} known_false_positives = Some legitimate applications may use a moved copy of msbuild.exe, triggering a false positive. Baselining of MSBuild.exe usage is recommended to better understand it's path usage. Visual Studio runs an instance out of a path that will need to be filtered on. @@ -10433,7 +10274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies wmiprvse.exe spawning msbuild.exe. This behavior is indicative of a COM object being utilized to spawn msbuild from wmiprvse.exe. It is common for MSBuild.exe to be spawned from devenv.exe while using Visual Studio. In this instance, there will be command line arguments and file paths. In a malicious instance, MSBuild.exe will spawn from non-standard processes and have no command line arguments. For example, MSBuild.exe spawning from explorer.exe, powershell.exe is far less common and should be investigated. +explanation = The following analytic identifies instances where wmiprvse.exe spawns msbuild.exe, which is unusual and indicative of potential misuse of a COM object. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process relationships and command-line executions. This activity is significant because msbuild.exe is typically spawned by devenv.exe during legitimate Visual Studio use, not by wmiprvse.exe. If confirmed malicious, this behavior could indicate an attacker executing arbitrary code or scripts, potentially leading to system compromise or further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1127", "T1127.001"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. @@ -10443,7 +10284,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies child processes spawning from "mshta.exe". The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, parent process "mshta.exe" and its child process. +explanation = The following analytic identifies child processes spawned from "mshta.exe". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific child processes like "powershell.exe" and "cmd.exe". This activity is significant because "mshta.exe" is often exploited by attackers to execute malicious scripts or commands. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment. Monitoring this activity helps in early detection of potential threats leveraging "mshta.exe" for malicious purposes. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. @@ -10463,14 +10304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of a native MacOS utility, PlistBuddy, creating or modifying a properly list (.plist) file. In the instance of Silver Sparrow, the following commands were executed: \ -* PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist \ -Upon triage, capture the property list file being written to disk and review for further indicators. Contain the endpoint and triage further. +explanation = The following analytic identifies the use of the native macOS utility, PlistBuddy, to create or modify property list (.plist) files. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions involving PlistBuddy. This activity is significant because PlistBuddy can be used to establish persistence by modifying LaunchAgents, as seen in the Silver Sparrow malware. If confirmed malicious, this could allow an attacker to maintain persistence, execute arbitrary commands, and potentially escalate privileges on the compromised macOS system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543.001", "T1543"], "nist": ["DE.CM"]} known_false_positives = Some legitimate applications may use PlistBuddy to create or modify property lists and possibly generate false positives. Review the property list being modified or created to confirm. @@ -10480,14 +10314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of a native MacOS utility, PlistBuddy, creating or modifying a properly list (.plist) file. In the instance of Silver Sparrow, the following commands were executed: \ -* PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist \ -* PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist \ -Upon triage, capture the property list file being written to disk and review for further indicators. Contain the endpoint and triage further. +explanation = The following analytic detects the use of the PlistBuddy utility on macOS to create or modify property list (.plist) files. It leverages OSQuery to monitor process events, specifically looking for commands that interact with LaunchAgents and set properties like RunAtLoad. This activity is significant because PlistBuddy can be used to establish persistence mechanisms, as seen in malware like Silver Sparrow. If confirmed malicious, this could allow an attacker to maintain persistence, execute arbitrary commands, and potentially escalate privileges on the compromised system. how_to_implement = OSQuery must be installed and configured to pick up process events (info at https://osquery.io) as well as using the Splunk OSQuery Add-on https://splunkbase.splunk.com/app/4402. Modify the macro and validate fields are correct. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543.001", "T1543"], "nist": ["DE.CM"]} known_false_positives = Some legitimate applications may use PlistBuddy to create or modify property lists and possibly generate false positives. Review the property list being modified or created to confirm. @@ -10497,7 +10324,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a suspicious process making a DNS query via known, abused text-paste web services, VoIP, instant messaging, and digital distribution platforms used to download external files. This technique is abused by adversaries, malware actors, and red teams to download a malicious file on the target host. This is a good TTP indicator for possible initial access techniques. A user will experience false positives if the following instant messaging is allowed or common applications like telegram or discord are allowed in the corporate network. +explanation = The following analytic detects a suspicious process making DNS queries to known, abused text-paste web services, VoIP, instant messaging, and digital distribution platforms. It leverages Sysmon Event ID 22 logs to identify queries from processes like cmd.exe, powershell.exe, and others. This activity is significant as it may indicate an attempt to download malicious files, a common initial access technique. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the target host. how_to_implement = This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.CM"]} known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed. @@ -10507,7 +10334,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious process spawned by another process from within common container/archive file types. This technique was a common technique used by adversaries and malware to execute scripts or evade defenses. This TTP may detect some normal software installation or user behaviors where opening archive files is common. +explanation = The following analytic identifies a suspicious process executed from within common container/archive file types such as ZIP, ISO, IMG, and others. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it is a common technique used by adversaries to execute scripts or evade defenses. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or persist within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1204.002", "T1036.008"], "nist": ["DE.CM"]} known_false_positives = Various business process or userland applications and behavior. @@ -10517,7 +10344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious processes running in file paths that are not typically associated with legitimate software. Adversaries often employ this technique to drop and execute malicious executables in accessible locations that do not require administrative privileges. By monitoring for processes running in such unconventional file paths, we can identify potential indicators of compromise and proactively respond to malicious activity. This analytic plays a crucial role in enhancing system security by pinpointing suspicious behaviors commonly associated with malware and unauthorized software execution. +explanation = The following analytic identifies processes running from file paths not typically associated with legitimate software. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific process paths within the Endpoint data model. This activity is significant because adversaries often use unconventional file paths to execute malicious code without requiring administrative privileges. If confirmed malicious, this behavior could indicate an attempt to bypass security controls, leading to unauthorized software execution, potential system compromise, and further malicious activities within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"]} known_false_positives = Administrators may allow execution of specific binaries in non-standard paths. Filter as needed. @@ -10527,7 +10354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a process making a DNS query to Discord, a well known instant messaging and digital distribution platform. Discord can be abused by adversaries, as seen in the WhisperGate campaign, to host and download malicious. external files. A process resolving a Discord DNS name could be an indicator of malware trying to download files from Discord for further execution. +explanation = The following analytic identifies a process making a DNS query to Discord, excluding legitimate Discord application paths. It leverages Sysmon logs with Event ID 22 to detect DNS queries containing "discord" in the QueryName field. This activity is significant because Discord can be abused by adversaries to host and download malicious files, as seen in the WhisperGate campaign. If confirmed malicious, this could indicate malware attempting to download additional payloads from Discord, potentially leading to further code execution and compromise of the affected system. how_to_implement = his detection relies on sysmon logs with the Event ID 22, DNS Query. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.AE"]} known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed. @@ -10547,7 +10374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code by using non-standard file extensions to load DLLs. Upon investigating, look for network connections to remote destinations (internal or external). Review additional parrallel processes and child processes for additional activity. +explanation = The following analytic detects the use of Regsvr32.exe to register DLLs from suspicious paths such as AppData, ProgramData, or Windows Temp directories. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because Regsvr32.exe can be abused to proxy execution of malicious code, bypassing traditional security controls. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"]} known_false_positives = Limited false positives with the query restricted to specified paths. Add more world writeable paths as tuning continues. @@ -10557,7 +10384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe using dllregisterserver on the command line to load a DLL. When a DLL is registered, the DllRegisterServer method entry point in the DLL is invoked. This is typically seen when a DLL is being registered on the system. Not every instance is considered malicious, but it will capture malicious use of it. During investigation, review the parent process and parrellel processes executing. Capture the DLL being loaded and inspect further. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of rundll32.exe with the DllRegisterServer command to load a DLL. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it may indicate an attempt to register a malicious DLL, which can be a method for code execution or persistence. If confirmed malicious, an attacker could gain unauthorized code execution, escalate privileges, or maintain persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = This is likely to produce false positives and will require some filtering. Tune the query by adding command line paths to known good DLLs, or filtering based on parent process names. @@ -10567,7 +10394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe with no command line arguments. It is unusual for rundll32.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects the execution of rundll32.exe without any command line arguments. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution logs. It is significant because rundll32.exe typically requires command line arguments to function properly, and its absence is often associated with malicious activities, such as those performed by Cobalt Strike. If confirmed malicious, this activity could indicate an attempt to execute arbitrary code, potentially leading to credential dumping, unauthorized file writes, or other malicious actions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use a moved copy of rundll32, triggering a false positive. @@ -10587,7 +10414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe executing a DLL function name, Start and StartW, on the command line that is commonly observed with Cobalt Strike x86 and x64 DLL payloads. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. Typically, the DLL will be written and loaded from a world writeable path or user location. In most instances it will not have a valid certificate (Unsigned). During investigation, review the parent process and other parallel application execution. Capture and triage the DLL in question. In the instance of Cobalt Strike, rundll32.exe is the default process it opens and injects shellcode into. This default process can be changed, but typically is not. +explanation = The following analytic identifies the execution of rundll32.exe with the DLL function names "Start" and "StartW," commonly associated with Cobalt Strike payloads. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. This activity is significant as it often indicates the presence of malicious payloads, such as Cobalt Strike, which can lead to unauthorized code execution. If confirmed malicious, this activity could allow attackers to inject shellcode, escalate privileges, and maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, some legitimate applications may use Start as a function and call it via the command line. Filter as needed. @@ -10597,8 +10424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic, "Suspicious Scheduled Task from Public Directory", detects the registration of scheduled tasks aimed to execute a binary or script from public directories, a behavior often associated with malware deployment. It utilizes the Sysmon EventID 1 data source, searching for instances where schtasks.exe is connected with the directories users\public, \programdata\, or \windows\temp and involves the /create command. \ -The registration of such scheduled tasks in public directories could suggest that an attacker is trying to maintain persistence or execute malicious scripts. If confirmed as a true positive, this could lead to data compromise, unauthorized access, and potential lateral movement within the network. +explanation = The following analytic identifies the creation of scheduled tasks that execute binaries or scripts from public directories, such as users\public, \programdata\, or \windows\temp, using schtasks.exe with the /create command. It leverages Sysmon Event ID 1 data to detect this behavior. This activity is significant because it often indicates an attempt to maintain persistence or execute malicious scripts, which are common tactics in malware deployment. If confirmed as malicious, this could lead to data compromise, unauthorized access, and potential lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.AE"]} known_false_positives = The main source of false positives could be the legitimate use of scheduled tasks from these directories. Careful tuning of this search may be necessary to suit the specifics of your environment, reducing the rate of false positives. @@ -10608,7 +10434,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies searchprotocolhost.exe with no command line arguments. It is unusual for searchprotocolhost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. searchprotocolhost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +explanation = The following analytic detects instances of searchprotocolhost.exe running without command line arguments. This behavior is unusual and often associated with malicious activities, such as those performed by Cobalt Strike. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution data. This activity is significant because searchprotocolhost.exe typically runs with specific arguments, and its absence may indicate an attempt to evade detection. If confirmed malicious, this could lead to unauthorized code execution, potential credential dumping, or other malicious actions within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process. @@ -10618,7 +10444,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of a SQLite3 querying the MacOS preferences to identify the original URL the pkg was downloaded from. This particular behavior is common with MacOS adware-malicious software. Upon triage, review other processes in parallel for suspicious activity. Identify any recent package installations. +explanation = The following analytic identifies the use of SQLite3 querying the MacOS preferences to determine the original URL from which a package was downloaded. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions involving LSQuarantine. This activity is significant as it is commonly associated with MacOS adware and other malicious software. If confirmed malicious, this behavior could indicate an attempt to track or manipulate downloaded packages, potentially leading to further system compromise or persistent adware infections. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1074"], "nist": ["DE.CM"]} known_false_positives = Unknown. @@ -10628,7 +10454,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries will need to request a Kerberos Ticket Granting Ticket (TGT) on behalf of the newly created and renamed computer account. The TGT request will be preceded by a computer account name event. This analytic leverages Event Id 4781, `The name of an account was changed` and event Id 4768 `A Kerberos authentication ticket (TGT) was requested` to correlate a sequence of events where the new computer account on event id 4781 matches the request account on event id 4768. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation. +explanation = The following analytic detects suspicious Kerberos Ticket Granting Ticket (TGT) requests that may indicate exploitation of CVE-2021-42278 and CVE-2021-42287. It leverages Event ID 4781 (account name change) and Event ID 4768 (TGT request) to identify sequences where a newly renamed computer account requests a TGT. This behavior is significant as it could represent an attempt to escalate privileges by impersonating a Domain Controller. If confirmed malicious, this activity could allow attackers to gain elevated access and potentially control over the domain environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.AE"]} known_false_positives = A computer account name change event inmediately followed by a kerberos TGT request with matching fields is unsual. However, legitimate behavior may trigger it. Filter as needed. @@ -10638,7 +10464,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious creation of .wav file in appdata folder. This behavior was seen in Remcos RAT malware where it put the audio recording in the appdata\audio folde as part of data collection. this recording can be send to its C2 server as part of its exfiltration to the compromised machine. creation of wav files in this folder path is not a ussual disk place used by user to save audio format file. +explanation = The following analytic detects the creation of .wav files in the AppData folder, a behavior associated with Remcos RAT malware, which stores audio recordings in this location for data exfiltration. The detection leverages endpoint process and filesystem data to identify .wav file creation within the AppData\Roaming directory. This activity is significant as it indicates potential unauthorized data collection and exfiltration by malware. If confirmed malicious, this could lead to sensitive information being sent to an attacker's command and control server, compromising the affected system's confidentiality. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, file_name, file_path and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10658,7 +10484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Windows confidence = medium -explanation = The following analytic detects when a process other than explorer.exe writes to the Windows Recycle Bin to detect potential threats earlier and mitigate the risks. This detection is made by a Splunk query that utilizes the Endpoint.Filesystem data model and the Endpoint.Processes data model. The query looks for any process writing to the "*$Recycle.Bin*" file path, excluding explorer.exe. This detection is important because it suggests that an attacker is attempting to hide their activities by using the Recycle Bin, which can lead to data theft, ransomware, or other damaging outcomes. Detecting writes to the Recycle Bin by a process other than explorer.exe can help to investigate and determine if the activity is malicious or benign. False positives might occur since there might be legitimate uses of the Recycle Bin by processes other than explorer.exe. Next steps include reviewing the process writing to the Recycle Bin and any relevant on-disk artifacts upon triage. +explanation = The following analytic detects when a process other than explorer.exe writes to the Windows Recycle Bin. It leverages the Endpoint.Filesystem and Endpoint.Processes data models in Splunk to identify any process writing to the "*$Recycle.Bin*" file path, excluding explorer.exe. This activity is significant because it may indicate an attacker attempting to hide their actions, potentially leading to data theft, ransomware, or other malicious outcomes. If confirmed malicious, this behavior could allow an attacker to persist in the environment and evade detection by security tools. how_to_implement = To successfully implement this search you need to be ingesting information on filesystem and process logs responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` nodes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.CM"]} known_false_positives = Because the Recycle Bin is a hidden folder in modern versions of Windows, it would be unusual for a process other than explorer.exe to write to it. Incidents should be investigated as appropriate. @@ -10668,7 +10494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to spot instances of 'svchost.exe' initiating a Living Off The Land Binaries and Scripts (LOLBAS) execution process. Often, adversaries manipulate Task Scheduler to execute code on remote endpoints, resulting in the spawning of a malicious command as a child process of 'svchost.exe'. By tracking child processes of 'svchost.exe' that align with the LOLBAS project, potential lateral movement activity can be detected. The analytic examines process details, including the process name, parent process, and command-line executions. A comprehensive list of LOLBAS processes is included in the search parameters. Although the analytic might catch legitimate applications exhibiting this behavior, these instances should be filtered accordingly. The findings from this analytic offer valuable insight into potentially malicious activities on an endpoint. +explanation = The following analytic detects instances of 'svchost.exe' spawning Living Off The Land Binaries and Scripts (LOLBAS) processes. It leverages Endpoint Detection and Response (EDR) data to monitor child processes of 'svchost.exe' that match known LOLBAS executables. This activity is significant as adversaries often use LOLBAS techniques to execute malicious code stealthily, potentially indicating lateral movement or code execution attempts. If confirmed malicious, this behavior could allow attackers to execute arbitrary commands, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may trigger this behavior, filter as needed. @@ -10678,7 +10504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious dxdiag.exe process command-line execution. Dxdiag is used to collect the system info of the target host. This technique has been used by Remcos RATS, various actors, and other malware to collect information as part of the recon or collection phase of an attack. This behavior should rarely be seen in a corporate network, but this command line can be used by a network administrator to audit host machine specifications. Thus in some rare cases, this detection will contain false positives in its results. To triage further, analyze what commands were passed after it pipes out the result to a file for further processing. +explanation = The following analytic identifies the execution of the dxdiag.exe process with specific command-line arguments, which is used to gather system information. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line details. This activity is significant because dxdiag.exe is rarely used in corporate environments and its execution may indicate reconnaissance efforts by malicious actors. If confirmed malicious, this activity could allow attackers to collect detailed system information, aiding in further exploitation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.AE"]} known_false_positives = This commandline can be used by a network administrator to audit host machine specifications. Thus, a filter is needed. @@ -10698,9 +10524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for system processes that typically execute from `C:\Windows\System32\` or `C:\Windows\SysWOW64`. This may indicate a malicious process that is trying to hide as a legitimate process. \ -This detection utilizes a lookup that is deduped `system32` and `syswow64` directories from Server 2016 and Windows 10. \ -During triage, review the parallel processes - what process moved the native Windows binary? identify any artifacts on disk and review. If a remote destination is contacted, what is the reputation? +explanation = The following analytic identifies system processes running from unexpected locations outside `C:\Windows\System32\` or `C:\Windows\SysWOW64`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process paths, names, and hashes. This activity is significant as it may indicate a malicious process attempting to masquerade as a legitimate system process. If confirmed malicious, this behavior could allow an attacker to execute code, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.AE"]} known_false_positives = This detection may require tuning based on third party applications utilizing native Windows binaries in non-standard paths. @@ -10710,7 +10534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `query.exe` with command-line arguments utilized to discover the logged user. Red Teams and adversaries alike may leverage `query.exe` to identify system users on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `query.exe` with command-line arguments aimed at discovering logged-in users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as adversaries may use `query.exe` to gain situational awareness and perform Active Directory discovery on compromised endpoints. If confirmed malicious, this behavior could allow attackers to identify active users, aiding in further lateral movement and privilege escalation within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -10720,7 +10544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `whoami.exe` without any arguments. This windows native binary prints out the current logged user. Red Teams and adversaries alike may leverage `whoami.exe` to identify system users on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `whoami.exe` without any arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because both Red Teams and adversaries use `whoami.exe` to identify the current logged-in user, aiding in situational awareness and Active Directory discovery. If confirmed malicious, this behavior could indicate an attacker is gathering information to further compromise the system, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -10730,7 +10554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious modification of time provider registry for persistence and autostart. This technique can allow the attacker to persist on the compromised host and autostart as soon as the machine boot up. This TTP can be a good indicator of suspicious behavior since this registry is not commonly modified by normal user or even an admin. +explanation = The following analytic detects suspicious modifications to the time provider registry for persistence and autostart. It leverages data from the Endpoint.Registry data model, focusing on changes to the "CurrentControlSet\\Services\\W32Time\\TimeProviders" registry path. This activity is significant because such modifications are uncommon and can indicate an attempt to establish persistence on a compromised host. If confirmed malicious, this technique allows an attacker to maintain access and execute code automatically upon system boot, potentially leading to further exploitation and control over the affected system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.003", "T1547"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10750,7 +10574,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious loaded unsigned dll by MMC.exe application. This technique is commonly seen in attacker that tries to bypassed UAC feature or gain privilege escalation. This is done by modifying some CLSID registry that will trigger the mmc.exe to load the dll path +explanation = The following analytic detects the loading of an unsigned DLL by the MMC.exe application, which is indicative of a potential UAC bypass or privilege escalation attempt. It leverages Sysmon EventCode 7 to identify instances where MMC.exe loads a non-Microsoft, unsigned DLL. This activity is significant because attackers often use this technique to modify CLSID registry entries, causing MMC.exe to load malicious DLLs, thereby bypassing User Account Control (UAC) and gaining elevated privileges. If confirmed malicious, this could allow an attacker to execute arbitrary code with higher privileges, leading to further system compromise and persistence. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548", "T1218.014"], "nist": ["DE.CM"]} known_false_positives = unknown. all of the dll loaded by mmc.exe is microsoft signed dll. @@ -10760,7 +10584,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a possible uac bypass using the colorui.dll COM Object. this technique was seen in so many malware and ransomware like lockbit where it make use of the colorui.dll COM CLSID to bypass UAC. +explanation = The following analytic detects a potential UAC bypass using the colorui.dll COM Object. It leverages Sysmon EventCode 7 to identify instances where colorui.dll is loaded by a process other than colorcpl.exe, excluding common system directories. This activity is significant because UAC bypass techniques are often used by malware, such as LockBit ransomware, to gain elevated privileges without user consent. If confirmed malicious, this could allow an attacker to execute code with higher privileges, leading to further system compromise and persistence within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.003"], "nist": ["DE.CM"]} known_false_positives = not so common. but 3rd part app may load this dll. @@ -10770,7 +10594,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious un-installation of application using msiexec. This technique was seen in conti leak tool and script where it tries to uninstall AV product using this commandline. This commandline to uninstall product is not a common practice in enterprise network. +explanation = The following analytic detects the uninstallation of applications using msiexec with specific command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it is an uncommon practice in enterprise environments and has been associated with malicious behavior, such as disabling antivirus software. If confirmed malicious, this could allow an attacker to remove security software, potentially leading to further compromise and persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007", "T1218"], "nist": ["DE.CM"]} known_false_positives = unknown. @@ -10780,7 +10604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process performing an outbound connection on port 88 used by default by the network authentication protocol Kerberos. Typically, on a regular Windows endpoint, only the lsass.exe process is the one tasked with connecting to the Kerberos Distribution Center to obtain Kerberos tickets. Identifying an unknown process using this protocol may be evidence of an adversary abusing the Kerberos protocol. +explanation = The following analytic identifies a non-lsass.exe process making an outbound connection on port 88, which is typically used by the Kerberos authentication protocol. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and network traffic logs. This activity is significant because, under normal circumstances, only the lsass.exe process should interact with the Kerberos Distribution Center. If confirmed malicious, this behavior could indicate an adversary attempting to abuse the Kerberos protocol, potentially leading to unauthorized access or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550"], "nist": ["DE.CM"]} known_false_positives = Custom applications may leverage the Kerberos protocol. Filter as needed. @@ -10800,10 +10624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the behavior of AMSI being tampered with. Implemented natively in many frameworks, the command will look similar to `SEtValuE($Null,(New-OBJEct COLlECtionS.GenerIC.HAshSEt{[StrINg]))}$ReF=[ReF].AsSeMbLY.GeTTyPe("System.Management.Automation.Amsi"+"Utils")` taken from Powershell-Empire. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +explanation = The following analytic detects the tampering of AMSI (Antimalware Scan Interface) via PowerShell reflection. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze suspicious PowerShell commands, specifically those involving `system.management.automation.amsi`. This activity is significant as it indicates an attempt to bypass AMSI, a critical security feature that helps detect and block malicious scripts. If confirmed malicious, this could allow an attacker to execute harmful code undetected, leading to potential system compromise and data exfiltration. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1562", "T1059.001", "T1059"], "nist": ["DE.CM"]} known_false_positives = Potential for some third party applications to disable AMSI upon invocation. Filter as needed. @@ -10813,7 +10634,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic leverages Event ID 4769, `A Kerberos service ticket was requested`, to identify an unusual number of computer service ticket requests from one source. When a domain joined endpoint connects to a remote endpoint, it first will request a Kerberos Ticket with the computer name as the Service Name. An endpoint requesting a large number of computer service tickets for different endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of service requests. To customize this analytic, users can try different combinations of the `bucket` span time, the calculation of the `upperBound` field as well as the Outlier calculation. This logic can be used for real time security monitoring as well as threat hunting exercises. +explanation = The following analytic identifies an unusual number of computer service ticket requests from a single source, leveraging Event ID 4769, "A Kerberos service ticket was requested." It uses statistical analysis, including standard deviation and the 3-sigma rule, to detect anomalies in service ticket requests. This activity is significant as it may indicate malicious behavior such as lateral movement, malware staging, or reconnaissance. If confirmed malicious, an attacker could gain unauthorized access to multiple endpoints, facilitating further compromise and potential data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = An single endpoint requesting a large number of computer service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systeams and missconfigured systems. @@ -10823,8 +10644,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential kerberoasting attack against Active Directory networks. Kerberoasting allows an adversary to request kerberos tickets for domain accounts typically used as service accounts and attempt to crack them offline allowing them to obtain privileged access to the domain. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number service ticket requests. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. +explanation = The following analytic identifies an unusual number of Kerberos service ticket requests, potentially indicating a kerberoasting attack. It leverages Kerberos Event 4769 and calculates the standard deviation for each host, using the 3-sigma rule to detect anomalies. This activity is significant as kerberoasting allows adversaries to request service tickets and crack them offline, potentially gaining privileged access to the domain. If confirmed malicious, this could lead to unauthorized access to sensitive accounts and escalation of privileges within the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.AE"]} known_false_positives = An single endpoint requesting a large number of kerberos service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems. @@ -10834,7 +10654,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic leverages Event ID 4624, `An account was successfully logged on`, to identify an unusual number of remote authentication attempts coming from one source. An endpoint authenticating to a large number of remote endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual high number of authentication events.To customize this analytic, users can try different combinations of the `bucket` span time, the calculation of the `upperBound` field as well as the Outlier calculation.This logic can be used for real time security monitoring as well as threat hunting exercises. +explanation = The following analytic identifies an unusual number of remote authentication attempts from a single source by leveraging Windows Event ID 4624, which logs successful account logons. It uses statistical analysis, specifically the 3-sigma rule, to detect deviations from normal behavior. This activity is significant for a SOC as it may indicate lateral movement, malware staging, or reconnaissance. If confirmed malicious, this behavior could allow an attacker to move laterally within the network, escalate privileges, or gather information for further attacks. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} known_false_positives = An single endpoint authenticating to a large number of hosts is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, jump servers and missconfigured systems. @@ -10844,7 +10664,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects command lines that are extremely long, which might be indicative of malicious activity on your hosts because attackers often use obfuscated or complex command lines to hide their actions and evade detection. This helps to mitigate the risks associated with long command lines to enhance your overall security posture and reduce the impact of attacks. This detection is important because it suggests that an attacker might be attempting to execute a malicious command or payload on the host, which can lead to various damaging outcomes such as data theft, ransomware, or further compromise of the system. False positives might occur since legitimate processes or commands can sometimes result in long command lines. Next steps include conducting extensive triage and investigation to differentiate between legitimate and malicious activities. Review the source of the command line and the command itself during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. +explanation = The following analytic detects unusually long command lines, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on the length of command lines executed on hosts. This behavior is significant because attackers often use obfuscated or complex command lines to evade detection and execute malicious payloads. If confirmed malicious, this activity could lead to data theft, ransomware deployment, or further system compromise. Analysts should investigate the source and content of the command line, inspect relevant artifacts, and review concurrent processes to identify potential threats. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = Some legitimate applications start with long command lines. @@ -10854,7 +10674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Command lines that are extremely long may be indicative of malicious activity on your hosts. This search leverages the Machine Learning Toolkit (MLTK) to help identify command lines with lengths that are unusual for a given user. +explanation = The following analytic identifies unusually long command lines executed on hosts, which may indicate malicious activity. It leverages the Machine Learning Toolkit (MLTK) to detect command lines with lengths that deviate from the norm for a given user. This is significant for a SOC as unusually long command lines can be a sign of obfuscation or complex malicious scripts. If confirmed malicious, this activity could allow attackers to execute sophisticated commands, potentially leading to unauthorized access, data exfiltration, or further compromise of the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} known_false_positives = Some legitimate applications use long command lines for installs or updates. You should review identified command lines for legitimacy. You may modify the first part of the search to omit legitimate command lines from consideration. If you are seeing more results than desired, you may consider changing the value of threshold in the search to a smaller value. You should also periodically re-run the support search to re-build the ML model on the latest data. You may get unexpected results if the user identified in the results is not present in the data used to build the associated model. @@ -10864,7 +10684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments that leverage PowerShell environment variables to identify the current logged user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the execution of `powershell.exe` with command-line arguments that use PowerShell environment variables to identify the current logged user. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as adversaries may use it for situational awareness and Active Directory discovery on compromised endpoints. If confirmed malicious, this behavior could allow attackers to gather critical user information, aiding in further exploitation and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -10874,7 +10694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the use of PowerShell environment variables to identify the current logged user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of PowerShell environment variables to identify the current logged user by leveraging PowerShell Script Block Logging (EventCode=4104). This method monitors script blocks containing `$env:UserName` or `[System.Environment]::UserName`. Identifying this activity is significant as adversaries and Red Teams may use it for situational awareness and Active Directory discovery on compromised endpoints. If confirmed malicious, this activity could allow attackers to gain insights into user context, aiding in further exploitation and lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. @@ -10884,7 +10704,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The fsutil.exe application is a legitimate Windows utility used to perform tasks related to the file allocation table (FAT) and NTFS file systems. The update sequence number (USN) change journal provides a log of all changes made to the files on the disk. This search looks for fsutil.exe deleting the USN journal. +explanation = The following analytic detects the deletion of the USN Journal using the fsutil.exe utility. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because the USN Journal maintains a log of all changes made to files on the disk, and its deletion can be an indicator of an attempt to cover tracks or hinder forensic investigations. If confirmed malicious, this action could allow an attacker to obscure their activities, making it difficult to trace file modifications and potentially compromising incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]} known_false_positives = None identified @@ -10894,7 +10714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious wscript commandline to execute vbscript. This technique was seen in several malware to execute malicious vbs file using wscript application. commonly vbs script is associated to cscript process and this can be a technique to evade process parent child detections or even some av script emulation system. +explanation = The following analytic detects the execution of VBScript using the wscript.exe application. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because wscript.exe is typically not used to execute VBScript, which is usually associated with cscript.exe. This deviation can indicate an attempt to evade traditional process monitoring and antivirus defenses. If confirmed malicious, this technique could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10904,7 +10724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a possible abuse of verclsid to execute malicious file through generate CLSID. This process is a normal application of windows to verify the CLSID COM object before it is instantiated by Windows Explorer. This hunting query can be a good pivot point to analyze what is he CLSID or COM object pointing too to check if it is a valid application or not. +explanation = The following analytic detects the potential abuse of the verclsid.exe utility to execute malicious files via generated CLSIDs. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns associated with verclsid.exe. This activity is significant because verclsid.exe is a legitimate Windows application used to verify CLSID COM objects, and its misuse can indicate an attempt to bypass security controls. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise or further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.012", "T1218"], "nist": ["DE.AE"]} known_false_positives = windows can used this application for its normal COM object validation. @@ -10914,7 +10734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This query identifies a shell, PowerShell.exe or Cmd.exe, spawning from W3WP.exe, or IIS. In addition to IIS logs, this behavior with an EDR product will capture potential webshell activity, similar to the HAFNIUM Group abusing CVEs, on publicly available Exchange mail servers. During triage, review the parent process and child process of the shell being spawned. Review the command-line arguments and any file modifications that may occur. Identify additional parallel process, child processes, that may highlight further commands executed. After triaging, work to contain the threat and patch the system that is vulnerable. +explanation = The following analytic identifies instances where a shell (PowerShell.exe or Cmd.exe) is spawned from W3WP.exe, the IIS worker process. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is W3WP.exe. This activity is significant as it may indicate webshell activity, often associated with exploitation attempts like those by the HAFNIUM Group on Exchange servers. If confirmed malicious, this behavior could allow attackers to execute arbitrary commands, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"]} known_false_positives = Baseline your environment before production. It is possible build systems using IIS will spawn cmd.exe to perform a software build. Filter as needed. @@ -10934,7 +10754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a potential suspicious process loading a COM object from wbemprox.dll or faskprox.dll. The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. This feature is being abused by several threat actors, adversaries or even red teamers to gain privilege escalation or even to evade detections. This TTP is a good indicator that a process is loading possible known .dll modules that were known for its COM object. +explanation = The following analytic detects a suspicious process loading a COM object from wbemprox.dll, fastprox.dll, or wbemcomn.dll. It leverages Sysmon EventCode 7 to identify instances where these DLLs are loaded by processes not typically associated with them, excluding known legitimate processes and directories. This activity is significant as it may indicate an attempt by threat actors to abuse COM objects for privilege escalation or evasion of detection mechanisms. If confirmed malicious, this could allow attackers to gain elevated privileges or maintain persistence within the environment, posing a significant security risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.003"], "nist": ["DE.CM"]} known_false_positives = legitimate process that are not in the exception list may trigger this event. @@ -10944,7 +10764,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is designed to detect suspicious wermgr.exe process that tries to connect to known IP web services. This technique is know for trickbot and other trojan spy malware to recon the infected machine and look for its ip address without so much finger print on the commandline process. Since wermgr.exe is designed for error handling process of windows it is really suspicious that this process is trying to connect to this IP web services cause that maybe cause of some malicious code injection. +explanation = The following analytic detects the wermgr.exe process attempting to connect to known IP check web services. It leverages Sysmon EventCode 22 to identify DNS queries made by wermgr.exe to specific IP check services. This activity is significant because wermgr.exe is typically used for Windows error reporting, and its connection to these services may indicate malicious code injection, often associated with malware like Trickbot. If confirmed malicious, this behavior could allow attackers to recon the infected machine's IP address, aiding in further exploitation and evasion tactics. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from your endpoints like EventCode 22. If you are using Sysmon, you must have at least version 12 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590", "T1590.005"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10954,7 +10774,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = this search is designed to detect potential malicious wermgr.exe process that drops or create executable file. Since wermgr.exe is an application trigger when error encountered in a process, it is really un ussual to this process to drop executable file. This technique is commonly seen in trickbot malware where it injects it code to this process to execute it malicious behavior like downloading other payload +explanation = The following analytic detects the wermgr.exe process creating an executable file. It leverages Sysmon EventCode 11 to identify instances where wermgr.exe generates a .exe file. This behavior is unusual because wermgr.exe is typically associated with error reporting, not file creation. Such activity is significant as it may indicate TrickBot malware, which injects code into wermgr.exe to execute malicious actions like downloading additional payloads. If confirmed malicious, this could lead to further malware infections, data exfiltration, or system compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of wermgr.exe may be used. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10964,7 +10784,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is designed to detect suspicious cmd and powershell process spawned by wermgr.exe process. This suspicious behavior are commonly seen in code injection technique technique like trickbot to execute a shellcode, dll modules to run malicious behavior. +explanation = The following analytic detects the spawning of cmd or PowerShell processes by the wermgr.exe process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process telemetry, including parent-child process relationships and command-line executions. This behavior is significant as it is commonly associated with code injection techniques used by malware like TrickBot to execute shellcode or malicious DLL modules. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -10974,7 +10794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of wget on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +explanation = The following analytic detects the use of wget on Linux or MacOS to download a file from a remote source and pipe it to bash. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it is commonly associated with malicious actions like coinminers and exploits such as CVE-2021-44228 in Log4j. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise and unauthorized access to sensitive data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however filtering may be required. @@ -10984,7 +10804,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a suspicious process making a DNS query via known, abused text-paste web services, VoIP, internet via secure tunneling,instant messaging, and digital distribution platforms used to download external files. This technique is abused by adversaries, malware actors, and red teams to download a malicious file on the target host. This is a good TTP indicator for possible initial access techniques. A user will experience false positives if the following instant messaging is allowed or common applications like telegram or discord are allowed in the corporate network. +explanation = The following analytic detects a suspicious process making DNS queries to known, abused web services such as text-paste sites, VoIP, secure tunneling, instant messaging, and digital distribution platforms. This detection leverages Sysmon logs with Event ID 22, focusing on specific query names. This activity is significant as it may indicate an adversary attempting to download malicious files, a common initial access technique. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the target host. how_to_implement = This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1102"], "nist": ["DE.CM"]} known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed. @@ -10994,7 +10814,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious process enabling the "SeDebugPrivilege" privilege token. SeDebugPrivilege allows a process to inspect and adjust the memory of other processes, and has long been a security concern. SeDebugPrivilege allows the token bearer to access any process or thread, regardless of security descriptors, per Palantir. This technique is abused by adversaries to gain debug privileges with their malicious software to be able to access or debug a process to dump credentials or to inject malicious code. +explanation = The following analytic detects a process enabling the "SeDebugPrivilege" privilege token. It leverages Windows Security Event Logs with EventCode 4703, filtering out common legitimate processes. This activity is significant because SeDebugPrivilege allows a process to inspect and modify the memory of other processes, potentially leading to credential dumping or code injection. If confirmed malicious, an attacker could gain extensive control over system processes, enabling them to escalate privileges, persist in the environment, or access sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4703 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.002", "T1134"], "nist": ["DE.AE"]} known_false_positives = Some native binaries and browser applications may request SeDebugPrivilege. Filter as needed. @@ -11004,7 +10824,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process requesting access to winlogon.exe attempting to duplicate its handle. This technique was seen in several adversaries to gain privileges for their process. Winlogon.exe is the common targeted process of this technique because it contains high privileges and security tokens. +explanation = The following analytic detects a process attempting to access winlogon.exe to duplicate its handle. This is identified using Sysmon EventCode 10, focusing on processes targeting winlogon.exe with specific access rights. This activity is significant because it is a common technique used by adversaries to escalate privileges by leveraging the high privileges and security tokens associated with winlogon.exe. If confirmed malicious, this could allow an attacker to gain elevated privileges, potentially leading to full system compromise and unauthorized access to sensitive information. how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.001", "T1134"], "nist": ["DE.AE"]} known_false_positives = It is possible legitimate applications will request access to winlogon, filter as needed. @@ -11014,7 +10834,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process requesting access in winlogon.exe to duplicate its handle with a non-common or public process source path. This technique was seen where adversaries attempt to gain privileges to their process. This duplicate handle access technique, may refer to a malicious process duplicating the process token of winlogon.exe and using it to a new process instance. Winlogon.exe is the common targeted process of this technique because it contains high privileges and security tokens. +explanation = The following analytic detects a process attempting to duplicate the handle of winlogon.exe from an uncommon or public source path. This is identified using Sysmon EventCode 10, focusing on processes targeting winlogon.exe with specific access rights and excluding common system paths. This activity is significant because it may indicate an adversary trying to escalate privileges by leveraging the high-privilege tokens associated with winlogon.exe. If confirmed malicious, this could allow the attacker to gain elevated access, potentially leading to full system compromise and persistent control over the affected host. how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.001", "T1134"], "nist": ["DE.AE"]} known_false_positives = It is possible legitimate applications will request access to winlogon, filter as needed. @@ -11024,7 +10844,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging to identify the execution of the PowerView PowerShell commandlet Get-NetUser. In the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user accounts that are not disabled. The full script block text based on the CISA-23-347A advisory is "Get-NetUser -UACFilter NOT_ACCOUNTDISABLE". Utilize this query to identify potential suspicious activity of user account enumeration. +explanation = The following analytic detects the execution of the PowerView PowerShell cmdlet Get-NetUser with the UACFilter parameter set to NOT_ACCOUNTDISABLE, indicating an attempt to enumerate Active Directory user accounts that are not disabled. This detection leverages PowerShell Script Block Logging (EventCode 4104) to identify the specific script block text. Monitoring this activity is significant as it may indicate reconnaissance efforts by an attacker to identify active user accounts for further exploitation. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]} known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed. @@ -11034,7 +10854,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. In the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user account's "samccountname". This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system. +explanation = The following analytic detects the execution of the PowerView PowerShell cmdlet Get-NetUser, specifically querying for "samaccountname" and "pwdlastset" attributes. It leverages Event ID 4104 from PowerShell Script Block Logging to identify this activity. This behavior is significant as it may indicate an attempt to gather user account information from Active Directory, which is a common reconnaissance step in lateral movement or privilege escalation attacks. If confirmed malicious, this activity could allow an attacker to map out user accounts, potentially leading to further exploitation and unauthorized access within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed. @@ -11044,7 +10864,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. This technique was observed in the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user accounts that do not require preauthentication for Kerberos. This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system. +explanation = The following analytic detects the execution of the PowerView PowerShell cmdlet Get-NetUser with the -PreauthNotRequire parameter, leveraging Event ID 4104. This method identifies attempts to query Active Directory user accounts that do not require Kerberos preauthentication. Monitoring this activity is crucial as it can indicate reconnaissance efforts by an attacker to identify potentially vulnerable accounts. If confirmed malicious, this behavior could lead to further exploitation, such as unauthorized access or privilege escalation within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed. @@ -11064,7 +10884,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the modification of the Access Control List for the AdminSDHolder object within a Windows domain. Specifically, the detection triggers on the addition of a new rule to the existing ACL. AdminSDHolder is an object located in the System Partition in Active Directory and is used as a security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that dont match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with the security permissions set on the AdminSDHolder. An adversary who has obtained privileged access to a Windows Domain may modify the AdminSDHolder ACL to establish persistence and allow an unprivileged user to take control of a domain. +explanation = The following analytic detects modifications to the Access Control List (ACL) of the AdminSDHolder object in a Windows domain, specifically the addition of new rules. It leverages EventCode 5136 from the Security Event Log, focusing on changes to the nTSecurityDescriptor attribute. This activity is significant because the AdminSDHolder object secures privileged group members, and unauthorized changes can allow attackers to establish persistence and escalate privileges. If confirmed malicious, this could enable an attacker to control domain-level permissions, compromising the entire Active Directory environment. how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for the AdminSDHolder object in order to log modifications. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546"], "nist": ["DE.CM"]} known_false_positives = Adding new users or groups to the AdminSDHolder ACL is not usual. Filter as needed @@ -11074,7 +10894,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects within different domains. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries for inter-domain privilege escalation and persistence. +explanation = The following analytic detects changes to the sIDHistory attribute of user or computer objects across different domains. It leverages Windows Security Event Codes 4738 and 4742 to identify when the sIDHistory attribute is modified. This activity is significant because the sIDHistory attribute allows users to inherit permissions from other AD accounts, which can be exploited by adversaries for inter-domain privilege escalation and persistence. If confirmed malicious, this could enable attackers to gain unauthorized access to resources, maintain persistence, and escalate privileges across domain boundaries. how_to_implement = To successfully implement this search, you need to be ingesting eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit User Account Management` and `Audit Computer Account Management` within `Account Management` all need to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]} known_false_positives = Domain mergers and migrations may generate large volumes of false positives for this analytic. @@ -11084,7 +10904,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the disabling of audit policies on a domain controller. The detection is made by identifying changes made to audit policies and checks for the removal of success or failure auditing, which are common indicators of policy tampering. The detection is important because it indicates that an attacker has gained access to the domain controller and is attempting to evade detection and cover up malicious activity. The impact of such an attack can be severe, including data theft, privilege escalation, and compromise of the entire network. False positives might occur since legitimate changes to audit policies might also trigger the analytic. Upon triage, review the audit policy change event and investigate the source of the change. Additionally, you must capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the attack source." +explanation = The following analytic detects the disabling of audit policies on a domain controller. It leverages EventCode 4719 from Windows Security Event Logs to identify changes where success or failure auditing is removed. This activity is significant as it suggests an attacker may have gained access to the domain controller and is attempting to evade detection by tampering with audit policies. If confirmed malicious, this could lead to severe consequences, including data theft, privilege escalation, and full network compromise. Immediate investigation is required to determine the source and intent of the change. how_to_implement = Ensure you are ingesting EventCode `4719` from your domain controllers, the category domain_controller exists in assets and identities, and that assets and identities is enabled. If A&I is not configured, you will need to manually filter the results within the base search. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -11094,7 +10914,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a genuine DC promotion event. Identifying when a computer assigns itself the necessary SPNs to function as a domain controller. Note these events are triggered on the existing domain controllers, not the newly joined domain controller. This detection will serve to identify rogue DCs added to the network. There are 2x detections within this analytic story which identify DCShadow attacks, if you do not currently possess the logging for these detections, remove the where clause within this detection to identify DCShadow activity. +explanation = The following analytic identifies a genuine Domain Controller (DC) promotion event by detecting when a computer assigns itself the necessary Service Principal Names (SPNs) to function as a domain controller. It leverages Windows Security Event Code 4742 to monitor existing domain controllers for these changes. This activity is significant as it can help identify rogue DCs added to the network, which could indicate a DCShadow attack. If confirmed malicious, this could allow an attacker to manipulate Active Directory, leading to potential privilege escalation and persistent access within the environment. how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4742`. The Advanced Security Audit policy setting `Audit Computer Account Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]} known_false_positives = None. @@ -11104,7 +10924,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the addition of the permissions necessary to perform a DCSync attack. In order to replicate AD objects, the initiating user or computer must have the following permissions on the domain. - DS-Replication-Get-Changes - DS-Replication-Get-Changes-All Certain Sync operations may require the additional permission of DS-Replication-Get-Changes-In-Filtered-Set. By default, adding DCSync permissions via the Powerview Add-ObjectACL operation adds all 3. This alert identifies where this trifecta has been met, and also where just the base level requirements have been met. +explanation = The following analytic detects the addition of permissions required for a DCSync attack, specifically DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, and DS-Replication-Get-Changes-In-Filtered-Set. It leverages EventCode 5136 from the Windows Security Event Log to identify when these permissions are granted. This activity is significant because it indicates potential preparation for a DCSync attack, which can be used to replicate AD objects and exfiltrate sensitive data. If confirmed malicious, an attacker could gain extensive access to Active Directory, leading to severe data breaches and privilege escalation. how_to_implement = To successfully implement this search, you need to be ingesting the eventcode 5136. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` to `Write All Properties` applied to the domain root and all descendant objects. Once the necessary logging has been enabled, enumerate the domain policy to verify if existing accounts with access need to be whitelisted, or revoked. Assets and Identities is also leveraged to automatically translate the objectSid into username. Ensure your identities lookup is configured with the sAMAccountName and objectSid of all AD user and computer objects. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.CM"]} known_false_positives = When there is a change to nTSecurityDescriptor, Windows logs the entire ACL with the newly added components. If existing accounts are present with this permission, they will raise an alert each time the nTSecurityDescriptor is updated unless whitelisted. @@ -11114,7 +10934,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = Aside from being used to promote genuine domain controllers, the DSRM (Directory Services Restore Mode) account can be used to persist within a Domain. A DC can be configured to allow the DSRM account to logon & be used in the same way as a local administrator account. This detection is looking for alterations to the behaviour of the account via registry. +explanation = The following analytic identifies changes to the Directory Services Restore Mode (DSRM) account behavior via registry modifications. It detects alterations in the registry path "*\\System\\CurrentControlSet\\Control\\Lsa\\DSRMAdminLogonBehavior" with specific values indicating potential misuse. This activity is significant because the DSRM account, if misconfigured, can be exploited to persist within a domain, similar to a local administrator account. If confirmed malicious, an attacker could gain persistent administrative access to a Domain Controller, leading to potential domain-wide compromise and unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = Disaster recovery events. @@ -11124,7 +10944,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Aside from being used to promote genuine domain controllers, the DSRM (Directory Services Restore Mode) account can be used to persist within a Domain. A DC can be configured to allow the DSRM account to logon & be used in the same way as a local administrator account. This detection is looking for any password reset attempts against that account. +explanation = The following analytic detects attempts to reset the Directory Services Restore Mode (DSRM) administrator password on a Domain Controller. It leverages event code 4794 from the Windows Security Event Log, specifically looking for events where the DSRM password reset is attempted. This activity is significant because the DSRM account can be used similarly to a local administrator account, providing potential persistence for an attacker. If confirmed malicious, this could allow an attacker to maintain administrative access to the Domain Controller, posing a severe risk to the domain's security. how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4794` and have the Advanced Security Audit policy `Audit User Account Management` within `Account Management` enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = Resetting the DSRM password for legitamate reasons, i.e. forgot the password. Disaster recovery. Deploying AD backdoor deliberately. @@ -11134,7 +10954,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This detection identifies when the SID of a privileged user is added to the SID History attribute of another user. Useful for tracking SID history abuse across multiple domains. This detection leverages the Asset and Identities framework. See the implementation section for further details on configuration. +explanation = The following analytic identifies when the SID of a privileged user is added to the SID History attribute of another user. It leverages Windows Security Event Codes 4742 and 4738, combined with identity lookups, to detect this activity. This behavior is significant as it may indicate an attempt to abuse SID history for unauthorized access across multiple domains. If confirmed malicious, this activity could allow an attacker to escalate privileges or maintain persistent access within the environment, posing a significant security risk. how_to_implement = Ensure you have objectSid and the Down Level Logon Name `DOMAIN\sAMACountName` added to the identity field of your Asset and Identities lookup, along with the category of privileged for the applicable users. Ensure you are ingesting eventcodes 4742 and 4738. Two advanced audit policies `Audit User Account Management` and `Audit Computer Account Management` under `Account Management` are required to generate these event codes. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]} known_false_positives = Migration of privileged accounts. @@ -11144,7 +10964,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = Windows Active Directory contains numerous objects that grant elevated access to the domain they reside in. These objects should be rarely accessed by normal users or processes. Access attempts to one or more of these objects may be evidence of attacker enumeration of Active Directory. +explanation = The following analytic detects access attempts to privileged Active Directory objects, such as Domain Admins or Enterprise Admins. It leverages Windows Security Event Code 4662 to identify when these sensitive objects are accessed. This activity is significant because such objects should rarely be accessed by normal users or processes, and unauthorized access attempts may indicate attacker enumeration or lateral movement within the domain. If confirmed malicious, this activity could allow attackers to escalate privileges, persist in the environment, or gain control over critical domain resources. how_to_implement = Enable Audit Directory Service Access via GPO and collect event code 4662. The required SACLs need to be created for the relevant objects. Be aware Splunk filters this event by default on the Windows TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]} known_false_positives = Service accounts or applications that routinely query Active Directory for information. @@ -11154,7 +10974,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This alert was written to detect activity associated with the DCSync attack. When a domain controller receives a replication request, the user account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. This alert detects when a user account creates a handle to domainDNS with the necessary replication permissions. +explanation = The following analytic detects a user account initiating an Active Directory replication request, indicative of a DCSync attack. It leverages EventCode 4662 from the Windows Security Event Log, focusing on specific object types and replication permissions. This activity is significant because it can allow an attacker with sufficient privileges to request password hashes for any or all users within the domain. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of the entire domain. how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services Access` within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root and all descendant objects. The principals `everybody`, `Domain Computers`, and `Domain Controllers` auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes In Filtered Set` annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.006", "T1003"], "nist": ["DE.CM"]} known_false_positives = Azure AD Connect syncing operations. @@ -11164,7 +10984,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This alert was written to detect activity associated with the DCSync attack performed by computer accounts. When a domain controller receives a replication request, the account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. This alert detects when a computer account account creates a handle to domainDNS with the necessary replication permissions. These requests are then filtered to exclude where the events originate from a known domain controller IP address. +explanation = The following analytic identifies unauthorized Active Directory replication requests initiated from non-domain controller locations. It leverages EventCode 4662 to detect when a computer account with replication permissions creates a handle to domainDNS, filtering out known domain controller IP addresses. This activity is significant as it may indicate a DCSync attack, where an attacker with privileged access can request password hashes for any or all users within the domain. If confirmed malicious, this could lead to unauthorized access to sensitive information and potential full domain compromise. how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services Access` within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root and all descendant objects. The principals `everybody`, `Domain Computers`, and `Domain Controllers` auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes In Filtered Set` Assets and Identities will also need to be configured, with the category of domain_controller added for domain controllers. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.006", "T1003"], "nist": ["DE.CM"]} known_false_positives = Genuine DC promotion may trigger this alert. @@ -11174,7 +10994,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects which exist within the same domain. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain. This analytic was written to pick up on activity via Mimikatz sid::patch. Please note there are additional avenues to abuse SID history such as DCShadow & Golden / Diamond tickets which won't be detected using these event codes. +explanation = The following analytic detects changes to the sIDHistory attribute of user or computer objects within the same domain. It leverages Windows Security Event Codes 4738 and 4742 to identify when the sIDHistory attribute is modified. This activity is significant because the sIDHistory attribute can be abused by adversaries to grant unauthorized access by inheriting permissions from another account. If confirmed malicious, this could allow attackers to maintain persistent access or escalate privileges within the domain, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit User Account Management` and `Audit Computer Account Management` within `Account Management` all need to be enabled. SID resolution is not required.. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -11184,7 +11004,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the addition of a Service Principal Name to a domain account. While this event may be part of a legitimate action part of certain administrative operations, it may also be evidence of a persistence attack. Domain accounts with Servce Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt to obtain its clertext password. +explanation = The following analytic detects the addition of a Service Principal Name (SPN) to a domain account. It leverages Windows Event Code 5136 and monitors changes to the servicePrincipalName attribute. This activity is significant because it may indicate an attempt to perform Kerberoasting, a technique where attackers extract and crack service account passwords offline. If confirmed malicious, this could allow an attacker to obtain cleartext passwords, leading to unauthorized access and potential lateral movement within the domain environment. how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed. @@ -11194,7 +11014,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the addition of a Service Principal Name to a domain account that is quickly deleted within 5 minutes or less. While this event may be part of a legitimate action part of certain administrative operations, it may also be evidence of a persistence attack. Domain accounts with Service Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt to obtain its clertext password. To clean things up, the adversary may delete the SPN which will trigger this detection. +explanation = The following analytic identifies the addition and quick deletion of a Service Principal Name (SPN) to a domain account within 5 minutes. This detection leverages EventCode 5136 from the Windows Security Event Log, focusing on changes to the servicePrincipalName attribute. This activity is significant as it may indicate an attempt to perform Kerberoasting, a technique used to crack the cleartext password of a domain account offline. If confirmed malicious, this could allow an attacker to gain unauthorized access to sensitive information or escalate privileges within the domain environment. how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = A Service Principal Name should only be added to an account when an application requires it. Adding an SPN and quickly deleting it is less common but may be part of legitimate action. Filter as needed. @@ -11204,7 +11024,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when either a global catalog SPN or a DRS RPC SPN are temporarily added to an Active Directory computer object, both of which can be evidence of a DCShadow attack. DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject and replicate changes into the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security researchers Benjamin Delpy and Vincent Le Toux. No event logs are written for changes to AD attributes, allowing for stealthy backdoors to be implanted in the domain, or metadata such as timestamps overwritten to cover tracks. +explanation = The following analytic detects the temporary addition of a global catalog SPN or a DRS RPC SPN to an Active Directory computer object, indicative of a potential DCShadow attack. This detection leverages EventCode 5136 from the `wineventlog_security` data source, focusing on specific SPN attribute changes. This activity is significant as DCShadow attacks allow attackers with privileged access to register rogue Domain Controllers, enabling unauthorized changes to the AD infrastructure. If confirmed malicious, this could lead to unauthorized replication of changes, including credentials and keys, compromising the entire domain's security. how_to_implement = To successfully implement this search, you need to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` to `Write All Properties` applied to the domain root and all descendant objects. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]} known_false_positives = None. @@ -11214,7 +11034,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a change in an Active Directory environment that could represent evidence of the DCShadow attack. DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject and replicate changes in the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security researchers Benjamin Delpy and Vincent Le Toux. Specifically, the detection will trigger when a possible rogue Domain Controller computer object is created and quickly deleted within 30 seconds or less in an Active Directory domain. This behavior was identfied by simulating the DCShadow attack with Mimikatz. +explanation = The following analytic identifies the creation and quick deletion of a Domain Controller (DC) object within 30 seconds in an Active Directory environment, indicative of a potential DCShadow attack. This detection leverages Windows Security Event Codes 5137 and 5141, analyzing the duration between these events. This activity is significant as DCShadow allows attackers with privileged access to register a rogue DC, enabling unauthorized changes to AD objects, including credentials. If confirmed malicious, this could lead to unauthorized AD modifications, compromising the integrity and security of the entire domain. how_to_implement = To successfully implement this search, you ned to be ingesting Event codes `5137` and `5141`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. For these event codes to be generated, specific SACLs are required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]} known_false_positives = Creating and deleting a server object within 30 seconds or less is unusual but not impossible in a production environment. Filter as needed. @@ -11224,7 +11044,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages event code `5136` to identify a modification of the SID History AD attribute. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain. +explanation = The following analytic detects modifications to the SID History attribute in Active Directory by leveraging event code 5136. This detection uses logs from the `wineventlog_security` data source to identify changes to the sIDHistory attribute. Monitoring this activity is crucial as the SID History attribute can be exploited by adversaries to inherit permissions from other accounts, potentially granting unauthorized access. If confirmed malicious, this activity could allow attackers to maintain persistent access and escalate privileges within the domain, posing a significant security risk. how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134", "T1134.005"], "nist": ["DE.CM"]} known_false_positives = Domain mergers and migrations may generate large volumes of false positives for this analytic. @@ -11234,7 +11054,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for the execution of `adfind.exe` with command-line arguments that it uses by default specifically the filter or search functions. It also considers the arguments necessary like objectcategory, see readme for more details: https://www.joeware.net/freetools/tools/adfind/usage.htm. AdFind.exe is a powerful tool that is commonly used for querying and retrieving information from Active Directory (AD). While it is primarily designed for AD administration and management, it has been seen used before by Wizard Spider, FIN6 and actors whom also launched SUNBURST. +explanation = The following analytic identifies the execution of `adfind.exe` with specific command-line arguments related to Active Directory queries. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and parent processes. This activity is significant because `adfind.exe` is a powerful tool often used by threat actors like Wizard Spider and FIN6 to gather sensitive AD information. If confirmed malicious, this activity could allow attackers to map the AD environment, facilitating further attacks such as privilege escalation or lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = ADfind is a command-line tool for AD administration and management that is seen to be leveraged by various adversaries. Filter out legitimate administrator usage using the filter macro. @@ -11244,7 +11064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to identify suspicious file creation in the root drive (C:\). This tactic was observed in NjRAT as a means to ascertain whether its malware instance running on the compromised host possesses administrative privileges. The methodology involves an attempt to create a 'win.dat' file in the C:\ directory. If this file is successfully created, it serves as an indicator that the process indeed holds administrative privileges. This anomaly detection mechanism serves as a valuable pivot point for detecting NjRAT and other malware strains employing similar techniques to assess the privileges of their running malware instances, without using token privilege API calls or PowerShell commandlets. +explanation = The following analytic identifies the creation of a suspicious file named 'win.dat' in the root directory (C:\). It leverages data from the Endpoint.Filesystem datamodel to detect this activity. This behavior is significant as it is commonly used by malware like NjRAT to check for administrative privileges on a compromised host. If confirmed malicious, this activity could indicate that the malware has administrative access, allowing it to perform high-privilege actions, potentially leading to further system compromise and persistence. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069.001"], "nist": ["DE.AE"]} known_false_positives = False positives may occur if there are legitimate accounts with the privilege to drop files in the root of the C drive. It's recommended to verify the legitimacy of such actions and the accounts involved. @@ -11254,7 +11074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event IDs 5140 or 5145 to identify a source computer accessing windows administrative shares (C$, Admin$ and IPC$ ) across a large number remote endpoints. Specifically, the logic will trigger when a source endpoint accesses administrative shares across 30 or more target computers within a 5 minute timespan. This behavior could represent an adversary who is enumerating network shares across an Active Directory environment in the search for sensitive files, a common technique leveraged by red teamers and threat actors. As environments differ across organizations, security teams should customize the thresholds of this detection as needed. +explanation = The following analytic detects a source computer accessing Windows administrative shares (C$, Admin$, IPC$) on 30 or more remote endpoints within a 5-minute window. It leverages Event IDs 5140 and 5145 from file share events. This behavior is significant as it may indicate an adversary enumerating network shares to locate sensitive files, a common tactic used by threat actors. If confirmed malicious, this activity could lead to unauthorized access to critical data, lateral movement, and potential compromise of multiple systems within the network. how_to_implement = To successfully implement this search, you need to be ingesting file share events. The Advanced Security Audit policy setting `Audit Detailed File Share` or `Audit File Share` within `Object Access` need to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.CM"]} known_false_positives = An single endpoint accessing windows administrative shares across a large number of endpoints is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems. @@ -11264,7 +11084,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Splunks Admon to identify the modification of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the modification of the default GPOs. +explanation = The following analytic detects modifications to the default Group Policy Objects (GPOs) in an Active Directory environment. It leverages Splunk's Admon to monitor updates to the "Default Domain Policy" and "Default Domain Controllers Policy." This activity is significant because changes to these default GPOs can indicate an adversary with privileged access attempting to gain further control, establish persistence, or deploy malware across multiple hosts. If confirmed malicious, such modifications could lead to widespread policy enforcement changes, unauthorized access, and potential compromise of the entire domain environment. how_to_implement = To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]} known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed. @@ -11274,7 +11094,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Splunks Admon to identify the creation of a new Group Policy Object. With GPOs, system administrators can manage and configure applications, software operations, and user settings throughout an entire organization. GPOs can be abused and leveraged by adversaries to escalate privileges or deploy malware across an Active Directory network. As an example, the Lockbit ransomware malware will create new group policies on the domain controller that are then pushed out to every device on the network. Security teams should monitor the creation of new Group Policy Objects. +explanation = The following analytic detects the creation of a new Group Policy Object (GPO) using Splunk's Admon data. It identifies events where a new GPO is created, excluding default "New Group Policy Object" entries. Monitoring GPO creation is crucial as adversaries can exploit GPOs to escalate privileges or deploy malware across an Active Directory network. If confirmed malicious, this activity could allow attackers to control system configurations, deploy ransomware, or propagate malware, significantly compromising the network's security. how_to_implement = To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]} known_false_positives = Group Policy Objects are created as part of regular administrative operations, filter as needed. @@ -11284,7 +11104,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic leverages Sysmon EventID 15, a critical file creation event, to detect the creation of Alternate Data Streams (ADS) on Windows systems. ADS is a feature of the NTFS file system that allows the storage of data in hidden streams attached to files. These streams are not visible in standard file listings, making them a popular technique for concealing malicious activity. Event ID 15 captures both the hash of the primary file content (unnamed stream) and the content of any additional named streams, which can include executables, scripts, or configuration data. Malware often exploits ADS to hide payloads, leveraging browser downloads to attach a Zone.Identifier stream, marking the file as originating from the Internet (Mark Of The Web, MOTW). This analytic is designed to identify such misuse by analyzing the content and creation patterns of named streams, including those under 1KB which may contain MOTW information. It is essential for detecting sophisticated threats that utilize non-executable file types or conceal malicious scripts within ADS, beyond the traditional focus on PE executables. The detection process involves monitoring for the creation of named streams, which are part of the NTFS structure and can be examined using tools like PowerShell for the presence of additional data streams or MOTW information. This approach helps in uncovering hidden payloads and tracking the origin of suspicious files downloaded via browsers or email clients, providing a comprehensive defense against ADS abuse. +explanation = The following analytic detects the creation of Alternate Data Streams (ADS) with Base64 content on Windows systems. It leverages Sysmon Event ID 15, which captures file creation events, including the content of named streams. ADS can conceal malicious payloads, making them significant for SOC monitoring. This detection identifies hidden streams that may contain executables, scripts, or configuration data, often used by malware to evade detection. If confirmed malicious, this activity could allow attackers to hide and execute payloads, persist in the environment, or access sensitive information without being easily detected. how_to_implement = Target environment must ingest sysmon data, specifically Event ID 15. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -11294,7 +11114,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect when data, possessing an IMPHASH value, is written to an Alternate Data Stream (ADS) in the NTFS file system. The presence of an IMPHASH value suggests that the written data has a Portable Executable (PE) structure, indicating its potential to be executed. Such behavior could be a sign of a threat actor staging malicious code within hard-to-detect areas of the file system for future use or persistence. It's important to note that for this analytic to function correctly, import hashing/imphash must be enabled within Sysmon. This allows the capture of the IMPHASH value, a unique identifier for the imported functions of a PE, providing a robust mechanism for detecting hidden malicious activity leveraging ADS. +explanation = The following analytic detects the writing of data with an IMPHASH value to an Alternate Data Stream (ADS) in the NTFS file system. It leverages Sysmon Event ID 15 and regex to identify files with a Portable Executable (PE) structure. This activity is significant as it may indicate a threat actor staging malicious code in hidden areas for persistence or future execution. If confirmed malicious, this could allow attackers to execute hidden code, maintain persistence, or escalate privileges within the environment. how_to_implement = Target environment must ingest Sysmon data, specifically Event ID 15, and import hashing/imphash must be enabled within Sysmon. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -11304,7 +11124,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This following analytic detects when a process attempts to execute a file from within an NTFS file system alternate data stream. This behavior could indicate that a threat actor staged malicious code within a difficult to detect area of the file system and is now attempting to execute it. +explanation = The following analytic detects when a process attempts to execute a file from within an NTFS file system alternate data stream. This detection leverages process execution data from sources like Windows process monitoring or Sysmon Event ID 1, focusing on specific processes known for such behavior. This activity is significant because alternate data streams can be used by threat actors to hide malicious code, making it difficult to detect. If confirmed malicious, this could allow an attacker to execute hidden code, potentially leading to unauthorized actions and further compromise of the system. how_to_implement = Target environment must ingest process execution data sources such as Windows process monitoring and/or Sysmon EventID 1. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated by process executions within the commandline, regex has been provided to minimize the possibilty. @@ -11314,7 +11134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a default behavior of a MetaSploit payload. MetaSploit uses Apache Benchmark to generate payloads. The payloads contain standard artifacts including "Apache Benchmark" and the original file name is always ab.exe. During triage, review the process and it's path. It is possible network connections spawned from it. Review parallel processes for further behaviors. +explanation = The following analytic detects the execution of the Apache Benchmark binary (ab.exe), commonly used by MetaSploit payloads. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the original file name is ab.exe. This activity is significant as it may indicate the presence of a MetaSploit attack, which uses Apache Benchmark to generate malicious payloads. If confirmed malicious, this could lead to unauthorized network connections, further system compromise, and potential data exfiltration. Immediate investigation is required to determine the intent and scope of the activity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited as there is a small subset of binaries that contain the original file name of ab.exe. Filter as needed. @@ -11324,7 +11144,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious process creating or connecting to a possible Qakbot named pipe . This technique was seen in Qakbot malware that creates named pipe after injecting its code in legitimate process to communicate on other process that also has an injected code to steal information on the compromised host. This Anomaly detection can be a good pivot for possible Qakbot infection. This detection looks for possible random generated named pipe (in GUID form) created by known process being abused by Qakbot. +explanation = The following analytic detects a suspicious process creating or connecting to a potential Qakbot named pipe. It leverages Sysmon EventCodes 17 and 18, focusing on specific processes known to be abused by Qakbot and identifying randomly generated named pipes in GUID form. This activity is significant as Qakbot malware uses named pipes for inter-process communication after code injection, facilitating data theft. If confirmed malicious, this behavior could indicate a Qakbot infection, leading to unauthorized data access and potential exfiltration from the compromised host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, pipename, processguid and named pipe event type from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -11334,7 +11154,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious wermgr.exe process creating or connecting to a named pipe. Wermgr.exe is part of Windows OS Problem reporting application responsible for reporting problems, fault or error happen on the Windows OS. This file is being abused by several Threat actors and malware such as Trickbot and Qakbot to execute their malicious code. This anomaly detection can be a good pivot on possible wermgr.exe processes having injected malicious code that might be related to qakbot infection that communicates via named pipe. +explanation = The following analytic detects the wermgr.exe process creating or connecting to a named pipe. It leverages Sysmon EventCodes 17 and 18 to identify these actions. This activity is significant because wermgr.exe, a legitimate Windows OS Problem Reporting application, is often abused by malware such as Trickbot and Qakbot to execute malicious code. If confirmed malicious, this behavior could indicate that an attacker has injected code into wermgr.exe, potentially allowing them to communicate covertly, escalate privileges, or persist within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, pipename, processguid and named pipe event type from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -11344,7 +11164,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of default or publicly known named pipes used by RMX remote admin tool. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. RMX Tool uses named pipes in many way as part of its communication for its server and client component. This tool was abuse by several adversaries and malware like Azorult to collect data to the targeted host. This TTP is a good indicator that this tool was install in production premise and need to check if the user has a valid reason why it need to install this legitimate application. +explanation = The following analytic detects the use of default or publicly known named pipes associated with the RMX remote admin tool. It leverages Sysmon EventCodes 17 and 18 to identify named pipe creation and connection events. This activity is significant as the RMX tool has been abused by adversaries and malware like Azorult to collect data from targeted hosts. If confirmed malicious, this could indicate unauthorized remote administration capabilities, leading to data exfiltration or further compromise of the affected system. Immediate investigation is required to determine the legitimacy of this tool's presence. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.CM"]} known_false_positives = False positives may be present. Filter based on pipe name or process. @@ -11364,7 +11184,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify executions of applications or scripts from uncommon or suspicious file paths, which could be indicative of malware or unauthorized activity. By leveraging a simple statistical model, the query analyzes the frequency of application executions across different file paths. It calculates the average (avg) number of executions per file path and uses the standard deviation (stdev) to measure the variation or dispersion of the execution counts from the average. A file path is considered uncommon or suspicious if the number of executions from it is significantly higher than what is expected based on the calculated average and standard deviation. Specifically, the analytic flags any file path from which the number of executions exceeds the upper bound, defined as the average plus two times the standard deviation (avg+stdev*2). This approach helps in pinpointing anomalies in application execution patterns, potentially uncovering malicious activities or policy violations. +explanation = The following analytic identifies the execution of applications or scripts from uncommon or suspicious file paths, potentially indicating malware or unauthorized activity. It leverages Windows AppLocker event logs and uses statistical analysis to detect anomalies. By calculating the average and standard deviation of execution counts per file path, it flags paths with execution counts significantly higher than expected. This behavior is significant as it can uncover malicious activities or policy violations. If confirmed malicious, this activity could allow attackers to execute unauthorized code, leading to potential system compromise or data breaches. how_to_implement = The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there. Upon tuning, modify to Anomaly or TTP. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.AE"]} known_false_positives = False positives are possible if legitimate users are executing applications from file paths that are not permitted by AppLocker. It is recommended to investigate the context of the application execution to determine if it is malicious or not. Modify the threshold as needed to reduce false positives. @@ -11384,7 +11204,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect the launch of applications that occur rarely within the environment, which could indicate the use of potentially malicious software or tools by attackers. It works by aggregating the count of application launches over time, then calculating the average and standard deviation of these counts. Applications whose launch counts significantly deviate from the norm, either by exceeding or falling below three standard deviations from the average, are flagged for further investigation. This approach helps in identifying unusual application activity that could be indicative of a security threat. +explanation = The following analytic detects the launch of rarely used applications within the environment, which may indicate the use of potentially malicious software or tools by attackers. It leverages Windows AppLocker event logs, aggregating application launch counts over time and flagging those that significantly deviate from the norm. This behavior is significant as it helps identify unusual application activity that could signal a security threat. If confirmed malicious, this activity could allow attackers to execute unauthorized code, potentially leading to further compromise of the system. how_to_implement = The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.AE"]} known_false_positives = False positives are possible if legitimate users are launching applications that are not permitted by AppLocker. It is recommended to investigate the context of the application launch to determine if it is malicious or not. Modify the threshold as needed to reduce false positives. @@ -11394,7 +11214,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script that archive files to a temp folder. This anomaly detection serves as a valuable indicator to uncover threats from adversaries utilizing PowerShell scripts for data archiving purposes. Identifying this method becomes pivotal in flagging and investigating potential threats, enabling proactive measures threat actors leveraging similar PowerShell-based data collection and archiving techniques. +explanation = The following analytic detects the use of PowerShell scripts to archive files into a temporary folder. It leverages PowerShell Script Block Logging, specifically monitoring for the `Compress-Archive` command targeting the `Temp` directory. This activity is significant as it may indicate an adversary's attempt to collect and compress data for exfiltration. If confirmed malicious, this behavior could lead to unauthorized data access and exfiltration, posing a severe risk to sensitive information and overall network security. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560"], "nist": ["DE.AE"]} known_false_positives = powershell may used this function to archive data. @@ -11404,7 +11224,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execute a rar utilities to archive files. This method has been exploited by various threat actors, including red-teamers and malware like DarkGate, to gather and compress collected data on compromised hosts. Subsequently, these archives are transmitted to command and control servers as part of their data exfiltration techniques. These adversaries leverage RAR archiving to consolidate and compress collected data on compromised hosts. Once the data is compiled into these archives, it serves as a means for these entities to effectively exfiltrate sensitive information. This process involves transferring the archived data to command and control servers, facilitating the extraction and retrieval of critical information from compromised systems. +explanation = The following analytic identifies the execution of RAR utilities to archive files on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, GUIDs, and command-line arguments. This activity is significant as threat actors, including red-teamers and malware like DarkGate, use RAR archiving to compress and exfiltrate collected data from compromised hosts. If confirmed malicious, this behavior could lead to the unauthorized transfer of sensitive information to command and control servers, posing a severe risk to data confidentiality and integrity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} known_false_positives = user and network administrator can execute this command. @@ -11414,7 +11234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect any execution of AutoIt3, a scripting language designed for automating the Windows GUI and general scripting. This includes instances where AutoIt3 has been renamed or otherwise altered in an attempt to evade detection. The analytic works by searching for process names or original file names that match 'autoit3.exe', which is the default executable for AutoIt scripts. This detection is important as AutoIt3 is often used by attackers to automate malicious activities, such as the execution of malware or other unwanted software. False positives may occur with legitimate uses of AutoIt3. +explanation = The following analytic detects the execution of AutoIt3, a scripting language often used for automating Windows GUI tasks and general scripting. It identifies instances where AutoIt3 or its variants are executed by searching for process names or original file names matching 'autoit3.exe'. This activity is significant because attackers frequently use AutoIt3 to automate malicious actions, such as executing malware. If confirmed malicious, this activity could lead to unauthorized code execution, system compromise, or further propagation of malware within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if the application is legitimately used, filter by user or endpoint as needed. @@ -11424,7 +11244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the abuse of two undocumented registry keys that allow for a DLL to load into lsass.exe to potentially capture credentials. Upon successful modification of \CurrentControlSet\Services\NTDS\DirectoryServiceExtPt or \CurrentControlSet\Services\NTDS\LsaDbExtPt, a DLL either remote or local will be set as the value and load up into lsass.exe. Based on POC code a text file may be written to disk with credentials. +explanation = The following analytic detects modifications to undocumented registry keys that allow a DLL to load into lsass.exe, potentially capturing credentials. It leverages the Endpoint.Registry data model to identify changes to \CurrentControlSet\Services\NTDS\DirectoryServiceExtPt or \CurrentControlSet\Services\NTDS\LsaDbExtPt. This activity is significant as it indicates a possible attempt to inject malicious code into the Local Security Authority Subsystem Service (LSASS), which can lead to credential theft. If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information and escalate privileges within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.008"], "nist": ["DE.CM"]} known_false_positives = False positives may be present on recent Windows Operating Systems. Filtering may be required based on process_name. In addition, look for non-standard, unsigned, module loads into LSASS. If query is too noisy, modify by adding Endpoint.processes process_name to query to identify the process making the modification. @@ -11434,7 +11254,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = Adversaries may abuse mavinject.exe to inject malicious DLLs into running processes (i.e. Dynamic-link Library Injection), allowing for arbitrary code execution (ex. C:\Windows\system32\mavinject.exe PID /INJECTRUNNING PATH_DLL). In addition to Dynamic-link Library Injection, Mavinject.exe can also be abused to perform import descriptor injection via its /HMODULE command-line parameter (ex. mavinject.exe PID /HMODULE=BASE_ADDRESS PATH_DLL ORDINAL_NUMBER). This command would inject an import table entry consisting of the specified DLL into the module at the given base address. During triage, review file modifcations and parallel processes. +explanation = The following analytic detects the use of mavinject.exe for DLL injection into running processes, identified by specific command-line parameters such as /INJECTRUNNING and /HMODULE. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because it indicates potential arbitrary code execution, a common tactic for malware deployment and persistence. If confirmed malicious, this could allow attackers to execute unauthorized code, escalate privileges, and maintain persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.013", "T1218"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter on DLL name or parent process. @@ -11444,7 +11264,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious files dropped or created in the Windows %startup% folder. This technique is a common way to gain persistence on a targeted host. Threat actor, adversaries and red teamer abuse this folder path to automatically execute their malicious sample upon boot or restart of the infected host. This TTP detection is a good indicator that a suspicious process wants to gain persistence on the targeted host. We suggest to verify the process name by using the process guid field, the file created and also the user and the computer name for further investigation. +explanation = The following analytic detects the creation of files in the Windows %startup% folder, a common persistence technique. It leverages the Endpoint.Filesystem data model to identify file creation events in this specific directory. This activity is significant because adversaries often use the startup folder to ensure their malicious code executes automatically upon system boot or user logon. If confirmed malicious, this could allow attackers to maintain persistence on the host, potentially leading to further system compromise and unauthorized access to sensitive information. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.AE"]} known_false_positives = Administrators may allow creation of script or exe in this path. @@ -11454,7 +11274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting query utilizes a PowerShell Scripted input that captures the bootloader paths for each Windows endpoint it is deployed to. The template inputs.conf is located in the references link. By default, it only captures the path, but may be modified to capture everything that BCDedit provides. It can be verbose, but may be worth it. +explanation = The following analytic identifies the bootloader paths on Windows endpoints. It leverages a PowerShell Scripted input to capture this data, which is then processed and aggregated using Splunk. Monitoring bootloader paths is significant for a SOC as it helps detect unauthorized modifications that could indicate bootkits or other persistent threats. If confirmed malicious, such activity could allow attackers to maintain persistence, bypass security controls, and potentially control the boot process, leading to full system compromise. how_to_implement = To implement this analytic, a new stanza will need to be added to a inputs.conf and deployed to all or some Windows endpoints. https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 provides the stanza. If modifying the sourcetype, be sure to update the Macro for this analytic. Recommend running it daily, or weekly, depending on threat model. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.001", "T1542"], "nist": ["DE.AE"]} known_false_positives = No false positives here, only bootloaders. Filter as needed or create a lookup as a baseline. @@ -11464,7 +11284,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a potentially suspicious execution of the 'pkgmgr' process involving the use of an XML input file for package management. The 'pkgmgr' process, though deprecated in modern Windows systems, was historically used for managing packages. The presence of an XML input file raises concerns about the nature of the executed command and its potential impact on the system. Due to the deprecated status of 'pkgmgr' and the involvement of an XML file, this activity warrants careful investigation. XML files are commonly used for configuration and data exchange, making it crucial to ascertain the intentions and legitimacy of the command. To ensure system security, it is recommended to use up-to-date package management utilities, such as DISM or PowerShell's PackageManagement module, and exercise caution when executing commands involving potentially sensitive operations or files. +explanation = The following analytic detects the execution of the deprecated 'pkgmgr.exe' process with an XML input file, which is unusual and potentially suspicious. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution details and command-line arguments. The significance lies in the deprecated status of 'pkgmgr.exe' and the use of XML files, which could indicate an attempt to bypass User Account Control (UAC). If confirmed malicious, this activity could allow an attacker to execute commands with elevated privileges, leading to potential system compromise and unauthorized changes. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002"], "nist": ["DE.AE"]} known_false_positives = False positives may be present on recent Windows Operating Systems. Filtering may be required based on process_name. In addition, look for non-standard, unsigned, module loads into LSASS. If query is too noisy, modify by adding Endpoint.processes process_name to query to identify the process making the modification. @@ -11474,7 +11294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies .cab files being written to disk. Utilize this analytic as a way to hunt for suspect .cab files being written to non-standard paths and tune as needed. Cab files were recently being utilized to deliver .url files embedded. The .url files were then used to deliver malicious payloads. The search specifically looks for instances where the file name is '*.cab' and the action is 'write'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. +explanation = The following analytic detects .cab files being written to disk. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on events where the file name is '*.cab' and the action is 'write'. This activity is significant as .cab files can be used to deliver malicious payloads, including embedded .url files that execute harmful code. If confirmed malicious, this behavior could lead to unauthorized code execution and potential system compromise. Analysts should review the file path and associated artifacts for further investigation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001"], "nist": ["DE.AE"]} known_false_positives = False positives will only be present if a process legitimately writes a .cab file to disk. Modify the analytic as needed by file path. Filter as needed. @@ -11484,7 +11304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line related to the discovery of cache domain credential logon count in the registry. This Technique was being abused by several post exploitation tool like Winpeas where it query CachedLogonsCount registry value in Winlogon registry. This value can be good information about the login caching setting on the Windows OS target host. A value of 0 means login caching is disable and values > 50 caches only 50 login attempts. By default all versions of Windows 10 save cached logins except Windows Server 2008. +explanation = The following analytic identifies a process command line querying the CachedLogonsCount registry value in the Winlogon registry. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and registry queries. Monitoring this activity is significant as it can indicate the use of post-exploitation tools like Winpeas, which gather information about login caching settings. If confirmed malicious, this activity could help attackers understand login caching configurations, potentially aiding in credential theft or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.005", "T1003"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -11494,7 +11314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious process commandline to change or set the default file association of a file without file extension with notepad.exe. This technique was seen in some APT and ransomware Prestige where it set/modify the default process to run file association, like .txt to notepad.exe. +explanation = The following analytic detects attempts to change the default file association for files without an extension to open with Notepad.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns and registry modifications. This activity is significant as it can indicate an attempt to manipulate file handling behavior, a technique observed in APT and ransomware attacks like Prestige. If confirmed malicious, this could allow attackers to execute arbitrary code by tricking users into opening files, potentially leading to system compromise or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -11504,7 +11324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a powershell script command to retrieve clipboard data. This technique was seen in several post exploitation tools like WINPEAS to steal sensitive information that was saved in clipboard. Using the Get-Clipboard powershell commandlet, adversaries can be able collect data stored in clipboard that might be a copied user name, password or other sensitive information. +explanation = The following analytic detects the execution of the PowerShell command 'Get-Clipboard' to retrieve clipboard data. It leverages PowerShell Script Block Logging (EventCode 4104) to identify instances where this command is used. This activity is significant because it can indicate an attempt to steal sensitive information such as usernames, passwords, or other confidential data copied to the clipboard. If confirmed malicious, this behavior could lead to unauthorized access to sensitive information, potentially compromising user accounts and other critical assets. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1115"], "nist": ["DE.AE"]} known_false_positives = It is possible there will be false positives, filter as needed. @@ -11514,7 +11334,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of reg.exe performing an add to the InProcServer32, which may be related to COM hijacking. Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence. Hijacking a COM object requires a change in the Registry to replace a reference to a legitimate system component which may cause that component to not work when executed. When that system component is executed through normal system operation the adversary's code will be executed instead. +explanation = The following analytic detects the modification of the InProcServer32 registry key by reg.exe, indicative of potential COM hijacking. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. COM hijacking is significant as it allows adversaries to insert malicious code that executes in place of legitimate software, providing a means for persistence. If confirmed malicious, this activity could enable attackers to execute arbitrary code, disrupt legitimate system components, and maintain long-term access to the compromised environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.015", "T1546"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and some filtering may be required. @@ -11524,7 +11344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies path traversal command-line execution and should be used to tune and driver other more higher fidelity analytics. This technique was seen in malicious document that execute malicious code using msdt.exe and path traversal technique that serve as defense evasion. This Hunting query is a good pivot to look for possible suspicious process and command-line that runs execute path traversal technique to run malicious code. This may help you to find possible downloaded malware or other lolbin execution. +explanation = The following analytic identifies path traversal command-line executions, leveraging data from Endpoint Detection and Response (EDR) agents. It detects patterns in command-line arguments indicative of path traversal techniques, such as multiple instances of "/..", "\..", or "\\..". This activity is significant as it often indicates attempts to evade defenses by executing malicious code, such as through msdt.exe. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = false positive may vary depends on the score you want to check. The bigger number of path traversal string count the better. @@ -11534,7 +11354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies path traversal command-line execution. This technique was seen in malicious document that execute malicious code using msdt.exe and path traversal technique that serve as defense evasion. This TTP is a good pivot to look for more suspicious process and command-line that runs before and after this execution. This may help you to find possible downloaded malware or other lolbin execution. +explanation = The following analytic detects path traversal command-line execution, often used in malicious documents to execute code via msdt.exe for defense evasion. It leverages Endpoint Detection and Response (EDR) data, focusing on specific patterns in process paths. This activity is significant as it can indicate an attempt to bypass security controls and execute unauthorized code. If confirmed malicious, this behavior could lead to code execution, privilege escalation, or persistence within the environment, potentially allowing attackers to deploy malware or leverage other living-off-the-land binaries (LOLBins). how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} known_false_positives = Not known at this moment. @@ -11544,7 +11364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies DCRat "forkbomb" payload feature. This technique was seen in dark crystal RAT backdoor capabilities where it will execute several cmd child process executing "notepad.exe & pause". The following analytic detects the multiple cmd.exe and child process notepad.exe execution using batch script in the targeted host within 30s timeframe. this TTP can be a good pivot to check DCRat infection. +explanation = The following analytic detects the execution of a DCRat "forkbomb" payload, which spawns multiple cmd.exe processes that launch notepad.exe instances in quick succession. This detection leverages Endpoint Detection and Response (EDR) data, focusing on the rapid creation of cmd.exe and notepad.exe processes within a 30-second window. This activity is significant as it indicates a potential DCRat infection, a known Remote Access Trojan (RAT) with destructive capabilities. If confirmed malicious, this behavior could lead to system instability, resource exhaustion, and potential disruption of services. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -11554,7 +11374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious process command line fetching the environment variables with a non-shell parent process. This technique was seen in qakbot malware where it fetches the environment variable in the target or compromised host. This TTP detection is a good pivot of possible malicious behavior since the command line is executed by a common non-shell process like cmd.exe , powershell.exe and many more. This can also be a good sign that the parent process has a malicious code injected to it to execute this command. +explanation = The following analytic identifies a suspicious process command line fetching environment variables with a non-shell parent process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and parent process names. This activity is significant as it is commonly associated with malware like Qakbot, which uses this technique to gather system information. If confirmed malicious, this behavior could indicate that the parent process has been compromised, potentially allowing attackers to execute arbitrary commands, escalate privileges, or persist within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = shell process that are not included in this search may cause False positive. Filter is needed. @@ -11564,7 +11384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following correlation identifies instances where four or more distinct detection analytics are associated with malicious command line behavior that is known to be exploited by multiple threat actors, adversaries, or red teamers on a specific host. By leveraging the Command Line Interface (CLI), attackers can execute malicious commands, gain access to sensitive data, install backdoors, and engage in various nefarious activities. The impact of such compromise can be severe, as attackers may gain unauthorized control over the compromised system, enabling them to exfiltrate valuable information, escalate privileges, or launch further attacks within the network. If this detection is triggered, there is a high level of confidence in the occurrence of suspicious command line activities on the host. +explanation = The following analytic identifies instances where four or more distinct detection analytics are associated with malicious command line behavior on a specific host. This detection leverages the Command Line Interface (CLI) data from various sources to identify suspicious activities. This behavior is significant as it often indicates attempts to execute malicious commands, access sensitive data, install backdoors, or perform other nefarious actions. If confirmed malicious, attackers could gain unauthorized control, exfiltrate information, escalate privileges, or launch further attacks within the network, leading to severe compromise. how_to_implement = 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation", "Installation"], "mitre_attack": ["T1222", "T1049", "T1033", "T1529", "T1016", "T1059"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers. @@ -11574,7 +11394,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifes a Computer Account creating a new Computer Account with specific a Service Principle Name - "RestrictedKrbHost". The RestrictedKrbHost service class allows client applications to use Kerberos authentication when they do not have the identity of the service but have the server name. +explanation = The following analytic identifies a computer account creating a new computer account with a specific Service Principal Name (SPN) "RestrictedKrbHost". This detection leverages Windows Security Event Logs, specifically EventCode 4741, to identify such activities. This behavior is significant as it may indicate an attempt to establish unauthorized Kerberos authentication channels, potentially leading to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to impersonate services, access sensitive information, or maintain persistence within the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4741 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]} known_false_positives = It is possible third party applications may have a computer account that adds computer accounts, filtering may be required. @@ -11604,7 +11424,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the unusual use of the Windows Console Host process (conhost.exe) with the undocumented --headless parameter to spawn a new process. This behavior is highly unusual and indicative of suspicious activity, as the --headless parameter is not commonly used in legitimate operations. The analytic identifies this behavior by looking for instances where conhost.exe is invoked with the --headless argument. This behavior is worth identifying for a Security Operations Center (SOC) as it could indicate an attacker's attempt to execute commands or scripts in a stealthy manner, potentially to establish persistence, perform lateral movement, or carry out other malicious activities. If a true positive is identified, it suggests that an attacker has gained a foothold in the environment and is attempting to further their attack, which could lead to serious consequences such as data exfiltration, system compromise, or deployment of ransomware. Potential false positives could arise from legitimate administrative activity, hence it is important to validate the context of the detected behavior during triage. +explanation = The following analytic detects the unusual invocation of the Windows Console Host process (conhost.exe) with the undocumented --headless parameter. This detection leverages Endpoint Detection and Response (EDR) telemetry, specifically monitoring for command-line executions where conhost.exe is executed with the --headless argument. This activity is significant for a SOC as it is not commonly used in legitimate operations and may indicate an attacker's attempt to execute commands stealthily. If confirmed malicious, this behavior could lead to persistence, lateral movement, or other malicious activities, potentially resulting in data exfiltration or system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003", "T1564.006"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if the application is legitimately used, filter by user or endpoint as needed. @@ -11634,7 +11454,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of CreateDump.exe being used to perform a process dump. This particular binary is not native to Windows, but is found to be brought in my many different third party applications including PowerShell 7. +explanation = The following analytic detects the use of CreateDump.exe to perform a process dump. This binary is not native to Windows and is often introduced by third-party applications, including PowerShell 7. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, GUIDs, and complete command-line executions. This activity is significant as it may indicate an attempt to dump LSASS memory, which can be used to extract credentials. If confirmed malicious, this could lead to unauthorized access and lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if an application is dumping processes, filter as needed. Recommend reviewing createdump.exe usage across the fleet to better understand all usage and by what. @@ -11644,7 +11464,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic focuses on identifying non-chrome processes that attempt to access the Chrome extensions file. This file contains crucial settings and information related to the browser's extensions installed on the computer. Adversaries and malware authors have been known to exploit this file to extract sensitive information from the Chrome browser on targeted hosts. Detecting such anomalous behavior provides valuable insights for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for access to the Chrome extensions file by non-chrome processes, we can enhance our ability to detect potential threats and protect sensitive information stored within the browser. +explanation = The following analytic detects non-Chrome processes attempting to access the Chrome extensions file. It leverages Windows Security Event logs, specifically event code 4663, to identify this behavior. This activity is significant because adversaries may exploit this file to extract sensitive information from the Chrome browser, posing a security risk. If confirmed malicious, this could lead to unauthorized access to stored credentials and other sensitive data, potentially compromising the security of the affected system and broader network. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = Uninstall chrome browser extension application may access this file and folder path to removed chrome installation in the target host. Filter is needed. @@ -11654,7 +11474,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect non-chrome processes accessing the Chrome user data file called "local state." This file contains important settings and information related to the browser's operations on the computer. Threat actors, adversaries, and malware authors have been known to exploit this file in attempts to extract the encrypted master key used for decrypting passwords saved in the Chrome browser. Detecting access to the "local state" file by non-chrome processes serves as a valuable pivot for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for this anomaly, we can improve our ability to identify potential threats and safeguard sensitive information stored within the browser. +explanation = The following analytic detects non-Chrome processes accessing the Chrome "Local State" file, which contains critical settings and information. It leverages Windows Security Event logs, specifically event code 4663, to identify this behavior. This activity is significant because threat actors can exploit this file to extract the encrypted master key used for decrypting saved passwords in Chrome. If confirmed malicious, this could lead to unauthorized access to sensitive information, posing a severe security risk. Monitoring this anomaly helps identify potential threats and safeguard browser-stored data. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = Uninstall chrome application may access this file and folder path to removed chrome installation in target host. Filter is needed. @@ -11664,7 +11484,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify non-chrome processes accessing the Chrome user data file called "login data." This SQLite database file contains important information related to the browser's operations on the computer. Threat actors, adversaries, and malware authors have been known to exploit this file in attempts to extract and decrypt passwords saved in the Chrome browser. Detecting access to the "login data" file by non-chrome processes serves as a valuable pivot for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for this anomaly, we can enhance our ability to detect potential threats and protect sensitive information stored within the browser. +explanation = The following analytic identifies non-Chrome processes accessing the Chrome user data file "login data." This file is an SQLite database containing sensitive information, including saved passwords. The detection leverages Windows Security Event logs, specifically event code 4663, to monitor access attempts. This activity is significant as it may indicate attempts by threat actors to extract and decrypt stored passwords, posing a risk to user credentials. If confirmed malicious, attackers could gain unauthorized access to sensitive accounts and escalate their privileges within the environment. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = Uninstall application may access this registry to remove the entry of the target application. filter is needed. @@ -11674,7 +11494,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool and malware such as Darkgate malware to create stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks. +explanation = The following analytic detects the execution of the Windows OS tool cmdkey.exe, which is used to create stored usernames, passwords, or credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because cmdkey.exe is often abused by post-exploitation tools and malware, such as Darkgate, to gain unauthorized access. If confirmed malicious, this behavior could allow attackers to escalate privileges and maintain persistence on the targeted host, facilitating further attacks and potential data breaches. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.CM"]} known_false_positives = network administrator can use this tool for auditing process. @@ -11684,7 +11504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool and malware such as Darkgate malware to delete stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks. +explanation = The following analytic detects the execution of the Windows OS tool cmdkey.exe with the /delete parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. The activity is significant because cmdkey.exe can be used by attackers to delete stored credentials, potentially leading to privilege escalation and persistence. If confirmed malicious, this behavior could allow attackers to remove stored user credentials, hindering incident response efforts and enabling further unauthorized access to the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.CM"]} known_false_positives = network administrator can use this tool for auditing process. @@ -11694,7 +11514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to list stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks. +explanation = The following analytic detects the execution of the Windows OS tool cmdkey.exe, which is often abused by post-exploitation tools like winpeas, commonly used in ransomware attacks to list stored usernames, passwords, or credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant as it indicates potential credential harvesting, which can lead to privilege escalation and persistence. If confirmed malicious, attackers could gain unauthorized access to sensitive information and maintain control over compromised systems for further exploitation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.AE"]} known_false_positives = network administrator can use this tool for auditing process. @@ -11704,7 +11524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line related to the discovery of possible password or credentials in the registry. This technique is being abused by adversaries or post exploitation tools like winpeas to steal credentials in the registry in the targeted host. Registry can contain several sensitive information like username and credentials that can be used for privilege escalation, persistence or even in lateral movement. This Anomaly detection can be a good pivot to detect a suspicious process querying a registry related to password or private keys. +explanation = The following analytic identifies processes querying the registry for potential passwords or credentials. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that access specific registry paths known to store sensitive information. This activity is significant as it may indicate credential theft attempts, often used by adversaries or post-exploitation tools like winPEAS. If confirmed malicious, this behavior could lead to privilege escalation, persistence, or lateral movement within the network, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -11714,9 +11534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Windows Curl.exe downloading a file to a suspicious location. \ --O or --output is used when a file is to be downloaded and placed in a specified location. \ -During triage, review parallel processes for further behavior. In addition, identify if the download was successful. If a file was downloaded, capture and analyze. +explanation = The following analytic detects the use of Windows Curl.exe to download a file to a suspicious location, such as AppData, ProgramData, or Public directories. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include the -O or --output options. This activity is significant because downloading files to these locations can indicate an attempt to bypass security controls or establish persistence. If confirmed malicious, this behavior could lead to unauthorized code execution, data exfiltration, or further compromise of the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = It is possible Administrators or super users will use Curl for legitimate purposes. Filter as needed. @@ -11726,14 +11544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Windows Curl.exe uploading a file to a remote destination. \ -`-T` or `--upload-file` is used when a file is to be uploaded to a remotge destination. \ - \ -`-d` or `--data` POST is the HTTP method that was invented to send data to a receiving web application, and it is, for example, how most common HTML forms on the web work. \ - \ -HTTP multipart formposts are done with `-F`, but this appears to not be compatible with the Windows version of Curl. Will update if identified adversary tradecraft. \ - \ -Adversaries may use one of the three methods based on the remote destination and what they are attempting to upload (zip vs txt). During triage, review parallel processes for further behavior. In addition, identify if the upload was successful in network logs. If a file was uploaded, isolate the endpoint and review. +explanation = The following analytic detects the use of Windows Curl.exe to upload a file to a remote destination. It identifies command-line arguments such as `-T`, `--upload-file`, `-d`, `--data`, and `-F` in process execution logs. This activity is significant because adversaries may use Curl to exfiltrate data or upload malicious payloads. If confirmed malicious, this could lead to data breaches or further compromise of the system. Analysts should review parallel processes and network logs to determine if the upload was successful and isolate the endpoint if necessary. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = False positives may be limited to source control applications and may be required to be filtered out. @@ -11743,17 +11554,27 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious process that is recursively deleting files on a compromised host. This behavior has been observed in several types of destructive malware, such as CaddyWiper, DoubleZero, and SwiftSlicer, which delete or overwrite files with randomly generated strings to make recovery impossible. Additionally, this analytic can detect potential recursive file writes across multiple files using Sysmon Event 23 or 26. Sysmon considers a file as deleted as soon as it is overwritten. This analytic serves as a strong indicator of potential destructive malware activity on a host machine or the uninstallation of a large software application. +explanation = The following analytic identifies a suspicious process that is recursively deleting executable files on a compromised host. It leverages Sysmon Event Codes 23 and 26 to detect this activity by monitoring for a high volume of deletions or overwrites of files with extensions like .exe, .sys, and .dll. This behavior is significant as it is commonly associated with destructive malware such as CaddyWiper, DoubleZero, and SwiftSlicer, which aim to make file recovery impossible. If confirmed malicious, this activity could lead to significant data loss and system instability, severely impacting business operations. how_to_implement = To successfully implement this search, you need to ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = The uninstallation of a large software application or the use of cleanmgr.exe may trigger this detection. A filter is necessary to reduce false positives. providing_technologies = ["Microsoft Sysmon"] +[savedsearch://ESCU - Windows Debugger Tool Execution - Rule] +type = detection +asset_type = Endpoint +confidence = medium +explanation = This analysis detects the use of debugger tools within a production environment. While these tools are legitimate for file analysis and debugging, they are abused by malware like PlugX and DarkGate for malicious DLL side-loading. The hunting query aids Security Operations Centers (SOCs) in identifying potentially suspicious tool executions, particularly for non-technical users in the production network. +how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. +annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"]} +known_false_positives = administrator or IT professional may execute this application for verifying files or debugging application. +providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Microsoft Sysmon", "Microsoft Windows", "Symantec Endpoint Protection"] + [savedsearch://ESCU - Windows Defacement Modify Transcodedwallpaper File - Rule] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification to the Transcodedwallpaper file in the wallpaper theme directory to change the wallpaper of the host machine. This technique was seen in adversaries attempting to deface or change the desktop wallpaper of the targeted host. During our testing, the common process that affects or changes the wallpaper if a user changes it via desktop personalized setting is explorer.exe. +explanation = The following analytic identifies modifications to the TranscodedWallpaper file in the wallpaper theme directory, excluding changes made by explorer.exe. This detection leverages the Endpoint.Processes and Endpoint.Filesystem data models to correlate process activity with file modifications. This activity is significant as it may indicate an adversary attempting to deface or change the desktop wallpaper of a targeted host, a tactic often used to signal compromise or deliver a message. If confirmed malicious, this could be a sign of unauthorized access and tampering, potentially leading to further system compromise or data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1491"], "nist": ["DE.AE"]} known_false_positives = 3rd part software application can change the wallpaper. Filter is needed. @@ -11763,7 +11584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 5136 to identify the modification of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the modification of the default GPOs. +explanation = The following analytic detects modifications to default Group Policy Objects (GPOs) using Event ID 5136. It monitors changes to the `Default Domain Controllers Policy` and `Default Domain Policy`, which are critical for enforcing security settings across domain controllers and all users/computers, respectively. This activity is significant because unauthorized changes to these GPOs can indicate an adversary with privileged access attempting to deploy persistence mechanisms or execute malware across the network. If confirmed malicious, such modifications could lead to widespread compromise, allowing attackers to maintain control and execute arbitrary code on numerous hosts. how_to_implement = To successfully implement this search, the Advanced Security Audit policy setting `Audit Directory Service Changes` within `DS Access` needs to be enabled. Furthermore, the appropriate system access control lists (SACL) need to be created as the used events are not logged by default. A good guide to accomplish this can be found here https://jgspiers.com/audit-group-policy-changes/. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]} known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed. @@ -11773,7 +11594,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages the Endpoint datamodel to identify the potential edition of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the edition of the default GPOs. +explanation = The following analytic detects modifications to default Group Policy Objects (GPOs) using the Group Policy Management Editor (GPME). It leverages the Endpoint data model to identify processes where `mmc.exe` executes `gpme.msc` with specific GUIDs related to default GPOs. This activity is significant because default GPOs, such as the `Default Domain Controllers Policy` and `Default Domain Policy`, are critical for enforcing security policies across the domain. If malicious, such modifications could allow an attacker to gain further access, establish persistence, or deploy malware across numerous hosts, severely compromising the network's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]} known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed. @@ -11803,7 +11624,7 @@ providing_technologies = ["Microsoft Defender"] type = detection asset_type = Endpoint confidence = medium -explanation = This detection searches for Windows Defender ASR registry modification events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR registry modification events that are generated when a process or application attempts to modify a registry key that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned. +explanation = The following analytic detects modifications to Windows Defender Attack Surface Reduction (ASR) registry settings. It leverages Windows Defender Operational logs, specifically EventCode 5007, to identify changes in ASR rules. This activity is significant because ASR rules are designed to block actions commonly used by malware to exploit systems. Unauthorized modifications to these settings could indicate an attempt to weaken system defenses. If confirmed malicious, this could allow an attacker to bypass security measures, leading to potential system compromise and data breaches. how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = False positives are expected from legitimate applications generating events that are similar to those generated by malicious activity. For example, Event ID 5007 is generated when a process attempts to modify a registry key that is related to ASR rules. This can be triggered by legitimate applications that attempt to modify registry keys that are not blocked by ASR rules. @@ -11823,8 +11644,7 @@ providing_technologies = ["Microsoft Defender"] type = detection asset_type = Endpoint confidence = medium -explanation = This hunting analytic targets a range of security events from Microsoft Defender, focusing on the Exploit Guard and Attack Surface Reduction (ASR) features. It monitors specific Event IDs - Event IDs 1121 and 1126 indicate active blocking of unauthorized operations or dangerous network connections, whereas Event IDs 1122 and 1125 represent audit logs for similar activities. Event ID 1129 shows user overrides on blocked operations. For ASR-related activities, Event IDs 1131 and 1133 signal blocked operations, while 1132 and 1134 are audit logs. Event ID 5007 alerts on configuration changes, possibly indicating security breaches. \ -Additionally, the analytic utilizes a lookup to correlate ASR rule GUIDs with their descriptive names, enhancing understanding of the context behind these security alerts. This includes rules for blocking vulnerable drivers, restricting actions of Adobe Reader and Office applications, and protecting against various malware and unauthorized system changes. This comprehensive approach aids in assessing policy enforcement and potential security risks. +explanation = The following analytic identifies security events from Microsoft Defender, focusing on Exploit Guard and Attack Surface Reduction (ASR) features. It detects Event IDs 1121, 1126, 1131, and 1133 for blocked operations, and Event IDs 1122, 1125, 1132, and 1134 for audit logs. Event ID 1129 indicates user overrides, while Event ID 5007 signals configuration changes. This detection uses a lookup to correlate ASR rule GUIDs with descriptive names. Monitoring these events is crucial for identifying unauthorized operations, potential security breaches, and policy enforcement issues. If confirmed malicious, attackers could bypass security measures, execute unauthorized actions, or alter system configurations. how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore the analytic will need to be modified for each type of event. The analytic can be modified to look for specific ASR rules, or to look for specific Event IDs. EventID 5007 is a change in the registry, and may be a false positive. This can be removed from the search if desired. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1566.001", "T1566.002", "T1059"], "nist": ["DE.AE"]} known_false_positives = False positives are not expected with this analytic, since it is a hunting analytic. It is meant to show the use of ASR rules and how they can be used to detect malicious activity. @@ -11834,7 +11654,7 @@ providing_technologies = ["Microsoft Defender"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will detect a suspicious process that modify a registry related to windows defender exclusion feature. This registry is abused by adversaries, malware author and red teams to bypassed Windows Defender Anti-Virus product by excluding folder path, file path, process, extensions and etc. from its real time or schedule scan to execute their malicious code. This is a good indicator for a defense evasion and to look further for events after this behavior. +explanation = The following analytic detects modifications to the Windows Defender exclusion registry entries. It leverages endpoint registry data to identify changes in the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Exclusions\\*". This activity is significant because adversaries often modify these entries to bypass Windows Defender, allowing malicious code to execute without detection. If confirmed malicious, this behavior could enable attackers to evade antivirus defenses, maintain persistence, and execute further malicious activities undetected. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = admin or user may choose to use this windows features. @@ -11844,7 +11664,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies potentially malicious 'netsh' processes that manipulate firewall configurations. This behavior has been observed in the NJRAT malware, which deletes its added firewall rules as part of its cleanup process. Leveraging this anomaly detection can be a valuable approach for detecting malware, such as NJRAT, that makes alterations to firewall configurations as a component of its malicious activities. +explanation = The following analytic identifies 'netsh' processes that delete or modify firewall configurations. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing specific keywords. This activity is significant because it can indicate malware, such as NJRAT, attempting to alter firewall settings to evade detection or remove traces. If confirmed malicious, this behavior could allow an attacker to disable security measures, facilitating further compromise and persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.004"], "nist": ["DE.AE"]} known_false_positives = Administrator may modify or delete firewall configuration. @@ -11854,7 +11674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect deletion of registry with suspicious process file path. This technique was seen in Double Zero wiper malware where it will delete all the subkey in HKLM, HKCU and HKU registry hive as part of its destructive payload to the targeted hosts. This anomaly detections can catch possible malware or advesaries deleting registry as part of defense evasion or even payload impact but can also catch for third party application updates or installation. In this scenario false positive filter is needed. +explanation = The following analytic detects the deletion of registry keys by non-critical processes. It leverages Endpoint Detection and Response (EDR) data, focusing on registry deletion events and correlating them with processes not typically associated with system or program files. This activity is significant as it may indicate malware, such as the Double Zero wiper, attempting to evade defenses or cause destructive payload impacts. If confirmed malicious, this behavior could lead to significant system damage, loss of critical configurations, and potential disruption of services. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = This detection can catch for third party application updates or installation. In this scenario false positive filter is needed. @@ -11864,7 +11684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable change password feature of the windows host. This registry modification may disables the Change Password button on the Windows Security dialog box (which appears when you press Ctrl+Alt+Del). As a result, users cannot change their Windows password on demand. This technique was seen in some malware family like ransomware to prevent the user to change the password after ownning the network or a system during attack. This windows feature may implemented by administrator to prevent normal user to change the password of a critical host or server, In this type of scenario filter is needed to minimized false positive. +explanation = The following analytic detects a suspicious registry modification that disables the Change Password feature on a Windows host. It identifies changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableChangePassword" with a value of "0x00000001". This activity is significant as it can prevent users from changing their passwords, a tactic often used by ransomware to maintain control over compromised systems. If confirmed malicious, this could hinder user response to an attack, allowing the attacker to persist and potentially escalate their access within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = This windows feature may implemented by administrator to prevent normal user to change the password of a critical host or server, In this type of scenario filter is needed to minimized false positive. @@ -11874,7 +11694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable Lock Computer windows features. This registry modification prevent the user from locking its screen or computer that are being abused by several malware for example ransomware. This technique was used by threat actor to make its payload more impactful to the compromised host. +explanation = The following analytic detects a suspicious registry modification that disables the Lock Computer feature in Windows. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableLockWorkstation" with a value of "0x00000001". This activity is significant because it prevents users from locking their screens, a tactic often used by malware, including ransomware, to maintain control over compromised systems. If confirmed malicious, this could allow attackers to sustain their presence and execute further malicious actions without user interruption. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -11884,7 +11704,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable logoff feature in windows host. This registry when enable will prevent users to log off of the system by using any method, including programs run from the command line, such as scripts. It also disables or removes all menu items and buttons that log the user off of the system. This technique was seen abused by ransomware malware to make the compromised host un-useful and hard to remove other registry modification made on the machine that needs restart to take effect. This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed. +explanation = The following analytic detects a suspicious registry modification that disables the logoff feature on a Windows host. It leverages data from the Endpoint.Registry data model to identify changes to specific registry values associated with logoff functionality. This activity is significant because it can indicate ransomware attempting to make the compromised host unusable and hinder remediation efforts. If confirmed malicious, this action could prevent users from logging off, complicate incident response, and allow attackers to maintain persistence and control over the affected system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed. @@ -11894,7 +11714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process that is attempting to disable the ability on Windows to generate a memory crash dump. This was recently identified being utilized by HermeticWiper. To disable crash dumps, the value must be set to 0. This feature is typically modified to perform a memory crash dump when a computer stops unexpectedly because of a Stop error (also known as a blue screen, system crash, or bug check). +explanation = The following analytic detects attempts to disable the memory crash dump feature on Windows systems by setting the registry value to 0. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the CrashDumpEnabled registry key. This activity is significant because disabling crash dumps can hinder forensic analysis and incident response efforts. If confirmed malicious, this action could be part of a broader attack strategy, such as data destruction or system destabilization, as seen with HermeticWiper, potentially leading to significant operational disruptions and data loss. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` and `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -11904,7 +11724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following search identifies a modification of registry to disable the windows notification center feature in a windows host machine. This registry modification removes notification and action center from the notification area on the task bar. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload. +explanation = The following analytic detects the modification of the Windows registry to disable the Notification Center on a host machine. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableNotificationCenter" registry value set to "0x00000001." This activity is significant because disabling the Notification Center can be a tactic used by RAT malware to hide its presence and subsequent actions. If confirmed malicious, this could allow an attacker to operate stealthily, potentially leading to further system compromise and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = admin or user may choose to disable this windows features. @@ -11914,7 +11734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify potentially malicious processes that terminate other processes using taskkill.exe. This technique has been observed in various malware instances, employed by adversaries and red teamers alike, to forcibly terminate other processes whether they be security products or other legitimate applications as part of their malicious activities. Detecting this anomaly serves as a valuable alert mechanism to identify suspicious processes or malware attempting to evade detection and disrupt system stability. +explanation = The following analytic identifies the use of taskkill.exe to forcibly terminate processes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that include specific taskkill parameters. This activity is significant because it can indicate attempts to disable security tools or disrupt legitimate applications, a common tactic in malware operations. If confirmed malicious, this behavior could allow attackers to evade detection, disrupt system stability, and potentially gain further control over the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.001"], "nist": ["DE.AE"]} known_false_positives = Network administrator can use this application to kill process during audit or investigation. @@ -11924,7 +11744,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable shutdown button on the logon user. This technique was seen in several malware especially in ransomware family like killdisk malware variant to make the compromised host un-useful and hard to remove other registry modification made on the machine that needs restart to take effect. This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed. +explanation = The following analytic detects suspicious registry modifications that disable the shutdown button on a user's logon screen. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with shutdown policies. This activity is significant because it is a tactic used by malware, particularly ransomware like KillDisk, to hinder system usability and prevent the removal of malicious changes. If confirmed malicious, this could impede system recovery efforts, making it difficult to restart the machine and remove other harmful modifications. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed. @@ -11944,7 +11764,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to disable windows features. These techniques are seen in several ransomware malware to impair the compromised host to make it hard for analyst to mitigate or response from the attack. Disabling these known features make the analysis and forensic response more hard. Disabling these feature is not so common but can still be implemented by the administrator for security purposes. In this scenario filters for users that are allowed doing this is needed. +explanation = The following analytic detects suspicious registry modifications aimed at disabling Windows Group Policy features. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values associated with disabling key Windows functionalities. This activity is significant because it is commonly used by ransomware to hinder mitigation and forensic response efforts. If confirmed malicious, this behavior could severely impair the ability of security teams to analyze and respond to the attack, allowing the attacker to maintain control and persist within the compromised environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Disabling these features for legitimate purposes is not a common use case but can still be implemented by the administrators. Filter as needed. @@ -11954,7 +11774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The search looks for the Registry Key DisableAntiSpyware set to disable. This is consistent with Ryuk infections across a fleet of endpoints. This particular behavior is typically executed when an ransomware actor gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +explanation = The following analytic detects the modification of the Windows Registry key "DisableAntiSpyware" being set to disable. This detection leverages data from the Endpoint.Registry datamodel, specifically looking for the registry value name "DisableAntiSpyware" with a value of "0x00000001". This activity is significant as it is commonly associated with Ryuk ransomware infections, indicating potential malicious intent to disable Windows Defender. If confirmed malicious, this action could allow attackers to disable critical security defenses, facilitating further malicious activities such as data encryption, exfiltration, or additional system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -11964,7 +11784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies DiskCryptor process name of dcrypt.exe or internal name dcinst.exe. This utility has been utilized by adversaries to encrypt disks manually during an operation. In addition, during install, a dcrypt.sys driver is installed and requires a reboot in order to take effect. There are no command-line arguments used. +explanation = The following analytic detects the execution of DiskCryptor, identified by the process names "dcrypt.exe" or "dcinst.exe". This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. DiskCryptor is significant because adversaries use it to manually encrypt disks during an operation, potentially leading to data inaccessibility. If confirmed malicious, this activity could result in complete disk encryption, causing data loss and operational disruption. Immediate investigation is required to mitigate potential ransomware attacks. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]} known_false_positives = It is possible false positives may be present based on the internal name dcinst.exe, filter as needed. It may be worthy to alert on the service name. @@ -11974,7 +11794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = DiskShadow.exe is a Microsoft Signed binary present on Windows Server. It has a scripting mode intended for complex scripted backup operations. This feature also allows for execution of arbitrary unsigned code. This analytic looks for the usage of the scripting mode flags in executions of DiskShadow. During triage, compare to known backup behavior in your environment and then review the scripts called by diskshadow. +explanation = The following analytic detects the use of DiskShadow.exe in scripting mode, which can execute arbitrary unsigned code. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions with scripting mode flags. This activity is significant because DiskShadow.exe is typically used for legitimate backup operations, but its misuse can indicate an attempt to execute unauthorized code. If confirmed malicious, this could lead to unauthorized code execution, potentially compromising the system and allowing further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.CM"]} known_false_positives = Administrators using the DiskShadow tool in their infrastructure as a main backup tool with scripts will cause false positives that can be filtered with `windows_diskshadow_proxy_execution_filter` @@ -11994,7 +11814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This hunting analytic identifies known Windows libraries potentially used in DLL search order hijacking or DLL Sideloading scenarios. Such cases may necessitate recompiling the DLL, relocating the DLL, or moving the vulnerable process. The query searches for any processes running outside of system32 or syswow64 directories. Certain libraries inherently operate from different application paths and must be added to the exclusion list as required. The lookup includes Microsoft native libraries cataloged in the Hijacklibs.net project. +explanation = The following analytic identifies potential DLL search order hijacking or DLL sideloading by detecting known Windows libraries loaded from non-standard directories. It leverages Sysmon EventCode 7 to monitor DLL loads and cross-references them with a lookup of known hijackable libraries. This activity is significant as it may indicate an attempt to execute malicious code by exploiting DLL search order vulnerabilities. If confirmed malicious, this could allow attackers to gain code execution, escalate privileges, or maintain persistence within the environment. how_to_implement = The search is written against the latest Sysmon TA 4.0 https://splunkbase.splunk.com/app/5709. For this specific event ID 7, the sysmon TA will extract the ImageLoaded name to the loaded_file field which is used in the search to compare against the hijacklibs lookup. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on paths. Filter or add other paths to the exclusion as needed. Some applications may legitimately load libraries from non-standard paths. @@ -12004,7 +11824,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a recently disclosed search ordler DLL hijack in iscsicpl.exe. The malicious DLL must be in a new path and iscsicpl.exe, upon load, will execute the payload. The analytic is restricted to Windows shells. Two proof of concepts were identified and utilized to determine the behavior. The command-line is an option to go after, but most likely identifying a child process off iscsicpl.exe will be more effective. Monitoring for suspicious DLL loads is also an option. +explanation = The following analytic detects DLL search order hijacking involving iscsicpl.exe. It identifies when iscsicpl.exe loads a malicious DLL from a new path, triggering the payload execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on child processes spawned by iscsicpl.exe. This activity is significant as it indicates a potential attempt to execute unauthorized code via DLL hijacking. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filtering may be required. Remove the Windows Shells macro to determine if other utilities are using iscsicpl.exe. @@ -12014,7 +11834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious DLL modules loaded by calc.exe that are not in windows %systemroot%\system32 or %systemroot%\sysWoW64 folder. This technique is well used by Qakbot malware to execute its malicious DLL file via dll side loading technique in calc process execution. This TTP detection is a good indicator that a suspicious dll was loaded in a public or non-common installation folder of Windows Operating System that needs further investigation. +explanation = The following analytic detects suspicious DLL modules loaded by calc.exe that are not located in the %systemroot%\system32 or %systemroot%\sysWoW64 directories. This detection leverages Sysmon EventCode 7 to identify DLL side-loading, a technique often used by Qakbot malware to execute malicious DLLs. This activity is significant as it indicates potential malware execution through a trusted process, which can bypass security controls. If confirmed malicious, this could allow attackers to execute arbitrary code, maintain persistence, and escalate privileges within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on processes that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -12024,7 +11844,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the suspicious child process of calc.exe due to dll side loading technique to execute another executable. This technique was seen in qakbot malware that uses dll side loading technique to calc applications to load its malicious dll code. The malicious dll that abuses dll side loading technique will load the actual qakbot loader dll using regsvr32.exe application. This TTP is a good indicator of qakbot since the calc.exe will not load other child processes aside from win32calc.exe. +explanation = The following analytic identifies suspicious child processes spawned by calc.exe, indicative of DLL side-loading techniques. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process GUIDs, names, and parent processes. This activity is significant as it is commonly associated with Qakbot malware, which uses calc.exe to load malicious DLLs via regsvr32.exe. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, maintain persistence, and escalate privileges, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12034,7 +11854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line used to enumerate DNS records. Adversaries, threat actors, or red teamers may employ this technique to gather information about a victim's DNS, which can be utilized during targeting. This method was also observed as part of a tool used by the Sandworm APT group in a geopolitical cyber warfare attack. By using the dnscmd.exe Windows application, an attacker can enumerate DNS records for specific domains within the targeted network, potentially aiding in further attacks. This anomaly detection can serve as a valuable starting point for identifying users and hostnames that may be compromised or targeted by adversaries seeking to collect data information. +explanation = The following analytic detects the use of the dnscmd.exe command to enumerate DNS records. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line executions. This activity is significant as it may indicate an adversary gathering network information, a common precursor to more targeted attacks. If confirmed malicious, this behavior could enable attackers to map the network, identify critical assets, and plan subsequent actions, potentially leading to data exfiltration or further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590.002"], "nist": ["DE.AE"]} known_false_positives = network administrator can execute this command to enumerate DNS record. Filter or add other paths to the exclusion as needed. @@ -12044,7 +11864,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4732 to identify the addition of a new member to the DnsAdmins group within Active Directory. . Members of the DnsAdmin group can manage the DNS service which most of the times runs on the Domain Controller. By abusing legitimate DNS management functionality, a member of the DnsAdmins group can escalate privileges by executing malicious code on a Domain Controller as SYSTEM. Security teams should monitor the modification of the DnsAdmins group and validate the changes are legitimate. +explanation = The following analytic detects the addition of a new member to the DnsAdmins group in Active Directory by leveraging Event ID 4732. This detection uses security event logs to identify changes to this high-privilege group. Monitoring this activity is crucial because members of the DnsAdmins group can manage the DNS service, often running on Domain Controllers, and potentially execute malicious code with SYSTEM privileges. If confirmed malicious, this activity could allow an attacker to escalate privileges and gain control over critical domain services, posing a significant security risk. how_to_implement = To successfully implement this search, Domain Controller events need to be ingested. The Advanced Security Audit policy setting `Audit Security Group Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} known_false_positives = New members can be added to the DnsAdmins group as part of legitimate administrative tasks. Filter as needed. @@ -12054,7 +11874,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetComputer. This technique was seen used in the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user account's "samccountname", "accountexpires", "lastlogon" and so on. This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system. +explanation = The following analytic detects the execution of the PowerView PowerShell cmdlet Get-NetComputer, which is used to query Active Directory for user account details such as "samaccountname," "accountexpires," "lastlogon," and more. It leverages Event ID 4104 from PowerShell Script Block Logging to identify this activity. This behavior is significant as it may indicate an attempt to gather user account information, which is often a precursor to further malicious actions. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.AE"]} known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed. @@ -12074,7 +11894,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies native .net binaries within the Windows operating system that may be abused by adversaries by moving it to a new directory. The analytic identifies the .net binary by using a lookup and compares the process name and original file name (internal name). The analytic utilizes a lookup with the is_net_windows_file_macro macro to identify the binary process name and original file name. if one or the other matches an alert will be generated. Adversaries abuse these binaries as they are native to windows and native DotNet. Note that not all SDK (post install of Windows) are captured in the lookup. +explanation = The following analytic detects the execution of native .NET binaries from non-standard directories within the Windows operating system. It leverages Endpoint Detection and Response (EDR) telemetry, comparing process names and original file names against a predefined lookup using the `is_net_windows_file_macro` macro. This activity is significant because adversaries may move .NET binaries to unconventional paths to evade detection and execute malicious code. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003", "T1218", "T1218.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering may be required. Certain utilities will run from non-standard paths based on the third-party application in use. @@ -12084,7 +11904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting / inventory query assists defenders in identifying Drivers being loaded across the fleet. This query relies upon a PowerShell script input to be deployed to critical systems and beyond. If capturing all via the input, this will provide retrospection into drivers persisting. Note, that this is not perfect across a large fleet. Modify the query as you need to view the data differently. +explanation = The following analytic identifies drivers being loaded across the fleet. It leverages a PowerShell script input deployed to critical systems to capture driver data. This detection is significant as it helps monitor for unauthorized or malicious drivers that could compromise system integrity. If confirmed malicious, such drivers could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment. how_to_implement = To capture the drivers by host, utilize the referenced Gist to create the inputs, props and transforms. Otherwise, this hunt query will not work. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.AE"]} known_false_positives = Filter and modify the analytic as you'd like. Filter based on path. Remove the system32\drivers and look for non-standard paths. @@ -12094,7 +11914,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses Windows EventCode 7045 to identify new Kernel Mode Drivers being loaded in Windows from a non-standard path. Note that, adversaries may move malicious or vulnerable drivers into these paths and load up. The idea is that this analytic provides visibility into drivers loading in non-standard file paths. +explanation = The following analytic detects the loading of new Kernel Mode Drivers from non-standard paths using Windows EventCode 7045. It identifies drivers not located in typical directories like Windows, Program Files, or SystemRoot. This activity is significant because adversaries may use these non-standard paths to load malicious or vulnerable drivers, potentially bypassing security controls. If confirmed malicious, this could allow attackers to execute code at the kernel level, escalate privileges, or maintain persistence within the environment, posing a severe threat to system integrity and security. how_to_implement = To implement this analytic, the Windows EventCode 7045 will need to be logged. The Windows TA for Splunk is also recommended. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1014", "T1068"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on legitimate third party applications needing to install drivers. Filter, or allow list known good drivers consistently being installed in these paths. @@ -12104,7 +11924,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic assists with viewing all drivers being loaded by using Sysmon EventCode 6 (Driver Load). Sysmon provides some simple fields to assist with identifying suspicious drivers. Use this analytic to look at prevalence of driver (count), path of driver, signature status and hash. Review these fields with scrutiny until the ability to prove the driver is legitimate and has a purpose in the environment. +explanation = The following analytic identifies all drivers being loaded on Windows systems using Sysmon EventCode 6 (Driver Load). It leverages fields such as driver path, signature status, and hash to detect potentially suspicious drivers. This activity is significant for a SOC as malicious drivers can be used to gain kernel-level access, bypass security controls, or persist in the environment. If confirmed malicious, this activity could allow an attacker to execute arbitrary code with high privileges, leading to severe system compromise and potential data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have the latest version of the Sysmon TA. Most EDR products provide the ability to review driver loads, or module loads, and using a query as such help with hunting for malicious drivers. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1014", "T1068"], "nist": ["DE.AE"]} known_false_positives = This analytic is meant to assist with identifying drivers loaded in the environment and not to be setup for notables off the bat. @@ -12114,7 +11934,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic searches for a registry modification that enables the use of the at.exe or wmi Win32_ScheduledJob command to add scheduled tasks on a Windows endpoint. Specifically, it looks for the creation of a new DWORD value named "EnableAt" in the following registry path: "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration". If this value is set to 1, it enables the at.exe and wmi Win32_ScheduledJob commands to schedule tasks on the system. Detecting this registry modification is important because it may indicate that an attacker has enabled the ability to add scheduled tasks to the system, which can be used to execute malicious code at specific times or intervals. +explanation = The following analytic detects the creation of a new DWORD value named "EnableAt" in the registry path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration". This modification enables the use of the at.exe or wmi Win32_ScheduledJob commands to add scheduled tasks on a Windows endpoint. The detection leverages registry event data from the Endpoint datamodel. This activity is significant because it may indicate that an attacker is enabling the ability to schedule tasks, potentially to execute malicious code at specific times or intervals. If confirmed malicious, this could allow persistent code execution on the system. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005"], "nist": ["DE.AE"]} known_false_positives = In some cases, an automated script or system may enable this setting continuously, leading to false positives. To avoid such situations, it is recommended to monitor the frequency and context of the registry modification and modify or filter the detection rules as needed. This can help to reduce the number of false positives and ensure that only genuine threats are identified. Additionally, it is important to investigate any detected instances of this modification and analyze them in the broader context of the system and network to determine if further action is necessary. @@ -12124,7 +11944,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious system event of services that was modified from start to disabled. This technique is seen where the adversary attempts to disable security app services, other malware services to evade the defense systems on the compromised host +explanation = The following analytic detects when a Windows service is modified from a start type to disabled. It leverages system event logs, specifically EventCode 7040, to identify this change. This activity is significant because adversaries often disable security or other critical services to evade detection and maintain control over a compromised host. If confirmed malicious, this action could allow attackers to bypass security defenses, leading to further exploitation and persistence within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = Windows service update may cause this event. In that scenario, filtering is needed. @@ -12134,7 +11954,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = 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. +explanation = The following analytic detects the clearing of Windows event logs by identifying Windows Security Event ID 1102 or System log event 104. This detection leverages Windows event logs to monitor for log clearing activities. Such behavior is significant as it may indicate an attempt to cover tracks after malicious activities. If confirmed malicious, this action could hinder forensic investigations and allow attackers to persist undetected, making it crucial to investigate further and correlate with other alerts and data sources. 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.001"], "nist": ["DE.CM"]} known_false_positives = It is possible that these logs may be legitimately cleared by Administrators. Filter as needed. @@ -12144,7 +11964,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies EventCode 3000 in Application channel indicating a process exit. This behavior is based on process names being added to the Image File Execution Options under HKLM \SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ and \SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit. Once these are set for a process, an eventcode 3000 will generate. The example used is from Thinkst Canary where a CanaryToken is setup to monitor for a commonly abused living off the land binary (ex. Klist.exe) and generate an event when it occurs. This can be seen as settings traps to monitor for suspicious behavior. Monitor and tune this hunting analytic and setup traps across your organization and begin monitoring. +explanation = The following analytic identifies the creation or modification of Image File Execution Options (IFEO) registry keys, detected via EventCode 3000 in the Application channel. This detection leverages Windows Event Logs to monitor for process names added to IFEO under specific registry paths. This activity is significant as it can indicate attempts to set traps for process monitoring or debugging, often used by attackers for persistence or evasion. If confirmed malicious, this could allow an attacker to execute arbitrary code or manipulate process behavior, leading to potential system compromise. how_to_implement = This analytic requires capturing the Windows Event Log Application channel in XML. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.012"], "nist": ["DE.AE"]} known_false_positives = False positives may be present and tuning will be required before turning into a TTP or notable. @@ -12154,7 +11974,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious excessive number of system events of services that was modified from start to disabled. This technique is seen where the adversary attempts to disable security app services, other malware services oer serve as an destructive impact to complete the objective on the compromised system. One good example for this scenario is Olympic destroyer where it disable all active services in the compromised host as part of its destructive impact and defense evasion. +explanation = The following analytic identifies an excessive number of system events where services are modified from start to disabled. It leverages Windows Event Logs (EventCode 7040) to detect multiple service state changes on a single host. This activity is significant as it may indicate an adversary attempting to disable security applications or other critical services, potentially leading to defense evasion or destructive actions. If confirmed malicious, this behavior could allow attackers to disable security defenses, disrupt system operations, and achieve their objectives on the compromised system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -12164,7 +11984,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies potentially malicious 'ImageLoaded' events, particularly when they involve executable files. This behavior was observed in NjRAT instances, where, during each instance of loading a module from its C2 server onto the compromised host, Sysmon recorded the path of the actual Image or Process as an 'ImageLoaded' event, rather than the typical tracking of dynamically loaded DLL modules in memory. This event holds significance because it tracks processes that load modules and libraries, which are typically in the .dll format rather than .exe. Leveraging this 'Time-To-Perform' (TTP) detection method can prove invaluable for the identification of NjRAT malware or other malicious software instances that introduce executable files as modules within a targeted host. +explanation = The following analytic identifies instances where executable files (.exe) are loaded as modules, detected through 'ImageLoaded' events in Sysmon logs. This method leverages Sysmon EventCode 7 to track unusual module loading behavior, which is significant as it deviates from the norm of loading .dll files. This activity is crucial for SOC monitoring because it can indicate the presence of malware like NjRAT, which uses this technique to load malicious modules. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, maintain persistence, and further compromise the host system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1129"], "nist": ["DE.CM"]} known_false_positives = unknown. @@ -12174,7 +11994,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a recently disclosed arbitraty command execution using Windows msdt.exe - a Diagnostics Troubleshooting Wizard. The sample identified will use the ms-msdt:/ protocol handler to load msdt.exe to retrieve a remote payload. During triage, review file modifications for html. Identify parallel process execution that may be related, including an Office Product. +explanation = The following analytic detects arbitrary command execution using Windows msdt.exe, a Diagnostics Troubleshooting Wizard. It leverages Endpoint Detection and Response (EDR) data to identify instances where msdt.exe is invoked via the ms-msdt:/ protocol handler to retrieve a remote payload. This activity is significant as it can indicate an exploitation attempt leveraging msdt.exe to execute arbitrary commands, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter as needed. Added .xml to potentially capture any answer file usage. Remove as needed. @@ -12184,7 +12004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the potential exfiltration of data using PowerShell's Invoke-RestMethod. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded. +explanation = The following analytic detects potential data exfiltration using PowerShell's Invoke-RestMethod. It leverages PowerShell Script Block Logging to identify scripts that attempt to upload files via HTTP POST requests. This activity is significant as it may indicate an attacker is exfiltrating sensitive data, such as desktop screenshots or files, to an external command and control (C2) server. If confirmed malicious, this could lead to data breaches, loss of sensitive information, and further compromise of the affected systems. Immediate investigation is recommended to determine the intent and scope of the activity. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1041"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited. Filter as needed. @@ -12194,7 +12014,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies potential data exfiltration using the PowerShell net.webclient command. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded. +explanation = The following analytic identifies potential data exfiltration using the PowerShell `net.webclient` command with the `UploadString` method. It leverages PowerShell Script Block Logging to detect instances where this command is executed. This activity is significant as it may indicate an attempt to upload sensitive data, such as desktop screenshots or files, to an external or internal URI, often associated with malware like Winter-Vivern. If confirmed malicious, this could lead to unauthorized data transfer, compromising sensitive information and potentially leading to further exploitation of the compromised host. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1041"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited. Filter as needed. @@ -12204,7 +12024,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when a certificate is exported from the Windows Certificate Store. This analytic utilizes the Certificates Lifecycle log channel event ID 1007. EventID 1007 is focused on the Export of a certificate from the local certificate store. In addition, review the ProcessName field as it will help to determine automation/Admin or adversary extracting the certificate. Depending on the organization, the certificate may be used for authentication to the VPN or private resources. +explanation = The following analytic detects the export of a certificate from the Windows Certificate Store. It leverages the Certificates Lifecycle log channel, specifically event ID 1007, to identify this activity. Monitoring certificate exports is crucial as certificates can be used for authentication to VPNs or private resources. If malicious actors export certificates, they could potentially gain unauthorized access to sensitive systems or data, leading to significant security breaches. how_to_implement = To implement this analytic, you must collect Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational or Microsoft-Windows-CertificateServicesClient-Lifecycle-User/Operational. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552", "T1649"], "nist": ["DE.AE"]} known_false_positives = False positives may be generated based on an automated process or service that exports certificates on the regular. Review is required before setting to alert. Monitor for abnormal processes performing an export. @@ -12214,7 +12034,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of the Invoke-ShareFinder PowerShell commandlet part of PowerView. This module obtains the list of all active domain computers and lists the active shares on each computer. Network file shares in Active Directory environments may contain sensitive information like backups, scripts, credentials, etc. Adversaries who have obtained a foothold in an AD network may leverage PowerView to identify secrets and leverage them for Privilege Escalation or Lateral Movement. +explanation = The following analytic detects the execution of the Invoke-ShareFinder PowerShell cmdlet from PowerView. This detection leverages PowerShell Script Block Logging to identify instances where this specific command is executed. Monitoring this activity is crucial as it indicates an attempt to enumerate network file shares, which may contain sensitive information such as backups, scripts, and credentials. If confirmed malicious, this activity could enable an attacker to escalate privileges or move laterally within the network, potentially compromising additional systems and sensitive data. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.CM"]} known_false_positives = Security teams may leverage PowerView proactively to identify and remediate sensitive file shares. Filter as needed. @@ -12224,7 +12044,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a possible windows application having a FTP connection in a non common installation path in windows operating system.This network protocol is being used by adversaries, threat actors and malware like AgentTesla as a Command And Control communication to transfer its collected stolen information like the desktop screenshots, browser information and system information of a targeted or compromised host. +explanation = The following analytic detects FTP connections initiated by processes located in non-standard installation paths on Windows systems. It leverages Sysmon EventCode 3 to identify network connections where the process image path does not match common directories like "Program Files" or "Windows\System32". This activity is significant as FTP is often used by adversaries and malware, such as AgentTesla, for Command and Control (C2) communications to exfiltrate stolen data. If confirmed malicious, this could lead to unauthorized data transfer, exposing sensitive information and compromising the integrity of the affected host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 3 connection events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]} known_false_positives = third party application may use this network protocol as part of its feature. Filter is needed. @@ -12234,7 +12054,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious file creation in the critical folder like "System32\Drivers" folder without file extension. This artifacts was seen in latest hermeticwiper where it drops its driver component in Driver Directory both the compressed(without file extension) and the actual driver component (with .sys file extension). This TTP is really a good indication that a host might be compromised by this destructive malware that wipes the boot sector of the system. +explanation = The following analytic detects the creation of files without extensions in critical folders like "System32\Drivers." It leverages data from the Endpoint.Filesystem datamodel, focusing on file paths and creation times. This activity is significant as it may indicate the presence of destructive malware, such as HermeticWiper, which drops driver components in these directories. If confirmed malicious, this behavior could lead to severe system compromise, including boot sector wiping, resulting in potential data loss and system inoperability. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} known_false_positives = Unknown at this point @@ -12244,7 +12064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic aims to identify potential adversaries who manipulate the security permissions of specific files or directories. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. By modifying the security permissions, adversaries seek to evade detection and impede access to their component files. Such actions indicate a deliberate effort to maintain control over compromised systems and hinder investigation or remediation efforts. Detecting these security permission changes can serve as a valuable indicator of an ongoing attack and enable timely response to mitigate the impact of the adversary's activities. +explanation = The following analytic identifies the modification of security permissions on files or directories using tools like icacls.exe, cacls.exe, or xcacls.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line executions. This activity is significant as it is commonly used by Advanced Persistent Threats (APTs) and coinminer scripts to evade detection and maintain control over compromised systems. If confirmed malicious, this behavior could allow attackers to hinder investigation, impede remediation efforts, and maintain persistent access to the compromised environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222.001", "T1222"], "nist": ["DE.CM"]} known_false_positives = Unknown. It is possible some administrative scripts use ICacls. Filter as needed. @@ -12254,7 +12074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-DomainOU` commandlet. `Get-DomainOU` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Identifying the use of `Get-DomainOU` is crucial as adversaries and Red Teams might employ it to gain insights into organizational units within Active Directory, potentially aiding in lateral movement or privilege escalation strategies. +explanation = The following analytic detects the execution of the `Get-DomainOU` cmdlet, a part of the PowerView toolkit used for Windows domain enumeration. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. Detecting `Get-DomainOU` usage is significant as adversaries may use it to gather information about organizational units within Active Directory, which can facilitate lateral movement or privilege escalation. If confirmed malicious, this activity could allow attackers to map the domain structure, aiding in further exploitation and persistence within the network. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. @@ -12264,7 +12084,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-InterestingDomainAcl` commandlet. `Find-InterestingDomainAcl` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-InterestingDomainAcl` is crucial as adversaries and Red Teams might employ it to identify unusual or misconfigured Access Control Lists (ACLs) within the domain. Such ACLs can provide attackers with insights into potential privilege escalation opportunities or weak security postures within Active Directory. +explanation = The following analytic detects the execution of the `Find-InterestingDomainAcl` cmdlet, part of the PowerView toolkit, using PowerShell Script Block Logging (EventCode=4104). This detection leverages logs to identify when this command is run, which is significant as adversaries may use it to find misconfigured or unusual Access Control Lists (ACLs) within a domain. If confirmed malicious, this activity could allow attackers to identify privilege escalation opportunities or weak security configurations in Active Directory, potentially leading to unauthorized access or further exploitation. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. @@ -12274,7 +12094,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of the findstr command employed to search for unsecured credentials Group Policy Preferences (GPP). GPP are tools that allow administrators to create domain policies with embedded credentials. These policies allow administrators to set local accounts. These group policies are stored in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL share and decrypt the password (using the AES key that has been made public). While Microsoft released a patch that impedes Administrators to create unsecure credentials, existing Group Policy Preferences files with passwords are not removed from SYSVOL. +explanation = The following analytic detects the use of the findstr command to search for unsecured credentials in Group Policy Preferences (GPP). It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving findstr.exe with references to SYSVOL and cpassword. This activity is significant because it indicates an attempt to locate and potentially decrypt embedded credentials in GPP, which could lead to unauthorized access. If confirmed malicious, this could allow an attacker to escalate privileges or gain access to sensitive systems and data within the domain. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552", "T1552.006"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage findstr to find passwords in GPO to validate exposure. Filter as needed. @@ -12284,7 +12104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic utilizes PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-ForestDomain` commandlet. `Get-ForestDomain` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Get-ForestDomain` is essential as adversaries and Red Teams might employ it to gain insights into the forest and domain configurations of an Active Directory environment. Such information can provide attackers with a broader understanding of the domain structure and potential avenues for lateral movement or privilege escalation. +explanation = The following analytic detects the execution of the `Get-ForestDomain` cmdlet, a component of the PowerView toolkit used for Windows domain enumeration. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. Detecting `Get-ForestDomain` is significant because adversaries and Red Teams use it to gather detailed information about Active Directory forest and domain configurations. If confirmed malicious, this activity could enable attackers to understand the domain structure, facilitating lateral movement or privilege escalation within the environment. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. @@ -12294,7 +12114,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a powershell script that enumerate camera mounted to the targeted host. This technique was seen in DCRat malware, where it runs a powershell command to look for camera information that will be pass on to its C2 server. This anomaly detection can be a good pivot to check who and why this enumeration is needed and what parent process execute this powershell script command. +explanation = The following analytic detects a PowerShell script that enumerates camera devices on the targeted host. This detection leverages PowerShell Script Block Logging, specifically looking for commands querying Win32_PnPEntity for camera-related information. This activity is significant as it is commonly observed in DCRat malware, which collects camera data to send to its command-and-control server. If confirmed malicious, this behavior could indicate an attempt to gather sensitive visual information from the host, potentially leading to privacy breaches or further exploitation. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592.001", "T1592"], "nist": ["DE.AE"]} known_false_positives = Administrators may execute this powershell command to get hardware information related to camera on $dest$. @@ -12304,7 +12124,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process that loads the samlib.dll module. This module is being abused by adversaries, threat actors and red teamers to access information of SAM objects or access credentials information in DC. This hunting query can be a good indicator that a process is capable of accessing the SAM object. +explanation = The following analytic detects processes loading the samlib.dll or samcli.dll modules, which are often abused to access Security Account Manager (SAM) objects or credentials on domain controllers. This detection leverages Sysmon EventCode 7 to identify these DLLs being loaded outside typical system directories. Monitoring this activity is crucial as it may indicate attempts to gather sensitive identity information. If confirmed malicious, this behavior could allow attackers to obtain credentials, escalate privileges, or further infiltrate the network. how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1589.001", "T1589"], "nist": ["DE.AE"]} known_false_positives = this module can be loaded by a third party application. Filter is needed. @@ -12314,7 +12134,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies process that attempts to connect to a known IP web services. This technique is commonly used by trickbot and other malware to perform reconnaissance against the infected machine and look for its IP address. +explanation = The following analytic detects processes attempting to connect to known IP check web services. This behavior is identified using Sysmon EventCode 22 logs, specifically monitoring DNS queries to services like "wtfismyip.com" and "ipinfo.io". This activity is significant as it is commonly used by malware, such as Trickbot, for reconnaissance to determine the infected machine's IP address. If confirmed malicious, this could allow attackers to gather network information, aiding in further attacks or lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from your endpoints like EventCode 22. If you are using Sysmon, you must have at least version 12 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590.005", "T1590"], "nist": ["DE.AE"]} known_false_positives = Filter internet browser application to minimize the false positive of this detection. @@ -12324,7 +12144,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the Get-ADComputer commandlet used with specific parameters to discover Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the Get-ADComputer cmdlet with parameters indicating a search for Windows endpoints with Kerberos Unconstrained Delegation. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific activity. This behavior is significant as it may indicate an attempt by adversaries or Red Teams to gain situational awareness and perform Active Directory discovery. If confirmed malicious, this activity could allow attackers to identify high-value targets for further exploitation, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting. @@ -12334,7 +12154,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-LocalAdminAccess` commandlet. `Find-LocalAdminAccess` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-LocalAdminAccess` is vital as adversaries and Red Teams might employ it to identify machines where the current user context has local administrator access. Such information can provide attackers with potential targets for lateral movement or privilege escalation within the network. +explanation = The following analytic detects the execution of the `Find-LocalAdminAccess` cmdlet using PowerShell Script Block Logging (EventCode=4104). This cmdlet is part of PowerView, a toolkit for Windows domain enumeration. Identifying the use of `Find-LocalAdminAccess` is crucial as adversaries may use it to find machines where the current user has local administrator access, facilitating lateral movement or privilege escalation. If confirmed malicious, this activity could allow attackers to target and compromise additional systems within the network, significantly increasing their control and access to sensitive information. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed. @@ -12344,7 +12164,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event IDs 5136 and 51137 to identify the creation of a new Group Policy Object. With GPOs, system administrators can manage and configure applications, software operations, and user settings throughout an entire organization. GPOs can be abused and leveraged by adversaries to escalate privileges or deploy malware across an Active Directory network. As an example, the Lockbit ransomware malware will create new group policies on the domain controller that are then pushed out to every device on the network. Security teams should monitor the creation of new Group Policy Objects. +explanation = The following analytic detects the creation of a new Group Policy Object (GPO) by leveraging Event IDs 5136 and 5137. This detection uses directory service change events to identify when a new GPO is created. Monitoring GPO creation is crucial as adversaries can exploit GPOs to escalate privileges or deploy malware across an Active Directory network. If confirmed malicious, this activity could allow attackers to control system configurations, deploy ransomware, or propagate malware, leading to widespread compromise and significant operational disruption. how_to_implement = To successfully implement this search, the Advanced Security Audit policy setting `Audit Directory Service Changes` within `DS Access` needs to be enabled. Furthermore, the appropriate system access control lists (SACL) need to be created as the used events are not logged by default. A good guide to accomplish this can be found here https://jgspiers.com/audit-group-policy-changes/. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1484", "T1484.001", "T1078.002"], "nist": ["DE.CM"]} known_false_positives = Group Policy Objects are created as part of regular administrative operations, filter as needed. @@ -12354,7 +12174,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects creation of hidden scheculed tasks such that it this task is not visible on the UI. Such behavior is indicative of certain malware, such as Industroyer2, or attacks leveraging living-off-the-land binaries (LOLBINs) to download additional payloads to a compromised machine. This analytic relies on the Windows Security EventCode 4698, indicating the creation of a scheduled task. The search focuses on identifying instances where the 'Hidden' setting is enabled, signaling potential nefarious activity. To implement this search, you need to ingest logs with task scheduling details from your endpoints. As false positives are currently unknown, it is advised to tune and filter based on the known use of task scheduling in your environment. This analytic provides crucial visibility into stealthy, potentially harmful scheduled tasks on Windows systems. +explanation = The following analytic detects the creation of hidden scheduled tasks on Windows systems, which are not visible in the UI. It leverages Windows Security EventCode 4698 to identify tasks where the 'Hidden' setting is enabled. This behavior is significant as it may indicate malware activity, such as Industroyer2, or the use of living-off-the-land binaries (LOLBINs) to download additional payloads. If confirmed malicious, this activity could allow attackers to execute code stealthily, maintain persistence, or further compromise the system by downloading additional malicious payloads. how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -12364,7 +12184,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious registry modification to hide common windows notification feature from compromised host. This technique was seen in some ransomware family to add more impact to its payload that are visually seen by user aside from the encrypted files and ransomware notes. Even this a good anomaly detection, administrator may implement this changes for auditing or security reason. In this scenario filter is needed. +explanation = The following analytic detects suspicious registry modifications aimed at hiding common Windows notification features on a compromised host. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant as it is often used by ransomware to obscure visual indicators, increasing the impact of the attack. If confirmed malicious, this could prevent users from noticing critical system alerts, thereby aiding the attacker in maintaining persistence and furthering their malicious activities undetected. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12374,7 +12194,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search identifies a high frequency of file deletions relative to the process name and process ID. Such events typically occur when ransomware attempts to encrypt files with specific extensions, leading Sysmon to treat the original files as deleted as soon as they are replaced with encrypted data. +explanation = The following analytic identifies a high frequency of file deletions by monitoring Sysmon EventCodes 23 and 26 for specific file extensions. This detection leverages Sysmon logs to track deleted target filenames, process names, and process IDs. Such activity is significant as it often indicates ransomware behavior, where files are encrypted and the originals are deleted. If confirmed malicious, this activity could lead to extensive data loss and operational disruption, as ransomware can render critical files inaccessible, demanding a ransom for their recovery. how_to_implement = To successfully implement this search, you need to ingest logs that include the deleted target file name, process name, and process ID from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]} known_false_positives = Users may delete a large number of pictures or files in a folder, which could trigger this detection. Additionally, heavy usage of PowerBI and Outlook may also result in false positives. @@ -12384,7 +12204,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a process loading version.dll that is not in %windir%\\system32 or %windir%\\syswow64 dir path. This event is seen in ransomware and APT malware that executes malicious version.dll placed in the same folder of onedrive application that will execute that module. This technique is known to be DLL side loading. This technique was used to execute an agent of Brute Ratel C4 red teaming tools to serve as remote admin tool to collect and compromise target host. +explanation = The following analytic detects a process loading a version.dll file from a directory other than %windir%\system32 or %windir%\syswow64. This detection leverages Sysmon EventCode 7 to identify instances where an unsigned or improperly located version.dll is loaded. This activity is significant as it is a common technique used in ransomware and APT malware campaigns, including Brute Ratel C4, to execute malicious code via DLL side loading. If confirmed malicious, this could allow attackers to execute arbitrary code, maintain persistence, and potentially compromise the target host. how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12394,7 +12214,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies all processes requesting access into Lsass.exe. his behavior may be related to credential dumping or applications requiring access to credentials. Triaging this event will require understanding the GrantedAccess from the SourceImage. In addition, whether the account is privileged or not. Review the process requesting permissions and review parallel processes. +explanation = The following analytic identifies processes attempting to access Lsass.exe, which may indicate credential dumping or applications needing credential access. It leverages Sysmon EventCode 10 to detect such activities by analyzing fields like TargetImage, GrantedAccess, and SourceImage. This behavior is significant as unauthorized access to Lsass.exe can lead to credential theft, posing a severe security risk. If confirmed malicious, attackers could gain access to sensitive credentials, potentially leading to privilege escalation and further compromise of the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.AE"]} known_false_positives = False positives will occur based on GrantedAccess and SourceUser, filter based on source image as needed. Utilize this hunting analytic to tune out false positives in TTP or anomaly analytics. @@ -12404,7 +12224,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic will identify any protocol handlers utilized on the command-line. A protocol handler is an application that knows how to handle particular types of links: for example, a mail client is a protocol handler for "mailto:" links. When the user clicks a "mailto:" link, the browser opens the application selected as the handler for the "mailto:" protocol (or offers them a choice of handlers, depending on their settings). To identify protocol handlers we can use NirSoft https://www.nirsoft.net/utils/url_protocol_view.html URLProtocolView or query the registry using PowerShell. +explanation = The following analytic identifies the use of protocol handlers executed via the command line. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because protocol handlers can be exploited to execute arbitrary commands or launch applications, potentially leading to unauthorized actions. If confirmed malicious, an attacker could use this technique to gain code execution, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} known_false_positives = False positives will be found. https and http is a URL Protocol handler that will trigger this analytic. Tune based on process or command-line. @@ -12414,7 +12234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the process AppCmd.exe installing a new module into IIS. AppCmd is a utility to manage IIS web sites and App Pools. An adversary may run this command to install a webshell or backdoor. This has been found to be used for credit card scraping, persistence, and further post-exploitation. An administrator may run this to install new modules for a web site or during IIS updates. +explanation = The following analytic detects the execution of AppCmd.exe to install a new module in IIS. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as adversaries may use it to install webshells or backdoors, leading to credit card scraping, persistence, and further post-exploitation. If confirmed malicious, this could allow attackers to maintain persistent access, execute arbitrary code, and potentially exfiltrate sensitive information from the compromised web server. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]} known_false_positives = False positives may be present until properly tuned. Filter as needed. @@ -12434,7 +12254,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes EventCode 2282 which generates when a Module DLL could not be loaded due to a configuration problem. This typically occurs when a IIS module is installed but is failing to load. This typically results in thousands of events until the issue is resolved. Review the module that is failing and determine if it is legitimate or not. +explanation = The following analytic detects when an IIS Module DLL fails to load due to a configuration problem, identified by EventCode 2282. This detection leverages Windows Application event logs to identify repeated failures in loading IIS modules. Such failures can indicate misconfigurations or potential tampering with IIS components. If confirmed malicious, this activity could lead to service disruptions or provide an attacker with opportunities to exploit vulnerabilities within the IIS environment. Immediate investigation is required to determine the legitimacy of the failing module and to mitigate any potential security risks. how_to_implement = IIS must be installed and Application event logs must be collected in order to utilize this analytic. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]} known_false_positives = False positives will be present until all module failures are resolved or reviewed. @@ -12444,7 +12264,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses the Windows Event log - Microsoft-IIS-Configuration/Operational - which must be enabled and logged on Windows IIS servers before it can be Splunked. The following analytic identifies newly installed IIS modules. Per Microsoft, IIS modules are not commonly added to a production IIS server, so alerting on this event ID should be enabled.IIS modules can be installed at a global level or at a site level. In detecting malicious IIS modules, it is important to check both the global and site level for unauthorized modules. Regular monitoring of these locations for such modules and comparing against a known good list can help detect and identify malicious IIS modules. +explanation = The following analytic detects the addition of new IIS modules on a Windows IIS server. It leverages the Windows Event log - Microsoft-IIS-Configuration/Operational, specifically EventCode 29, to identify this activity. This behavior is significant because IIS modules are rarely added to production servers, and unauthorized modules could indicate malicious activity. If confirmed malicious, an attacker could use these modules to execute arbitrary code, escalate privileges, or maintain persistence within the environment, potentially compromising the server and sensitive data. how_to_implement = You must enabled the IIS Configuration Operational log before ingesting in Splunk. Setup and inputs may be found here https://gist.github.com/MHaggis/64396dfd9fc3734e1d1901a8f2f07040. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present when updates or an administrator adds a new module to IIS. Monitor and filter as needed. @@ -12454,7 +12274,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a process that imports applocker xml policy using PowerShell commandlet. This technique was seen in Azorult malware where it drop an xml Applocker policy that will deny several AV products and further executed the PowerShell Applocker commandlet. +explanation = The following analytic detects the use of a PowerShell commandlet to import an AppLocker XML policy. This behavior is identified by monitoring processes that execute the "Import-Module Applocker" and "Set-AppLockerPolicy" commands with the "-XMLPolicy" parameter. This activity is significant because it can indicate an attempt to disable or bypass security controls, as seen in the Azorult malware. If confirmed malicious, this could allow an attacker to disable antivirus products, leading to further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = Administrators may execute this command that may cause some false positive. @@ -12464,7 +12284,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to change the health check interval of Windows Defender. Specifically, a value of 1 typically signifies that Windows Defender would perform health checks at a much higher frequency than the default settings. However, it's important to note that modifying this value to 1 might not necessarily conform to the actual behavior, as certain registry settings may have specific accepted values or a defined range that differs from a simple binary representation. Changing registry values, especially those related to system services, should be approached cautiously. Incorrect modifications can potentially impact system stability or performance. Always ensure you understand the implications and have a backup before altering registry settings. +explanation = The following analytic detects modifications to the Windows registry that change the health check interval of Windows Defender. It leverages data from the Endpoint datamodel, specifically monitoring changes to the "ServiceKeepAlive" registry path with a value of "0x00000001". This activity is significant because altering Windows Defender settings can impair its ability to perform timely health checks, potentially leaving the system vulnerable. If confirmed malicious, this could allow an attacker to disable or delay security scans, increasing the risk of undetected malware or other malicious activities. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12474,7 +12294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to change Windows Defender Quick Scan Interval. The "QuickScanInterval" in Windows Defender, specifically within the context of antivirus software, typically refers to the interval or frequency at which the system conducts quick scans for malware or potential threats. This setting dictates how often Windows Defender performs quick scans on the system. Quick scans are less comprehensive than full system scans but provide a faster way to check critical areas for potential threats or malware. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications to the Windows registry that change the Windows Defender Quick Scan Interval. It leverages data from the Endpoint.Registry data model, focusing on changes to the "QuickScanInterval" registry path. This activity is significant because altering the scan interval can impair Windows Defender's ability to detect malware promptly, potentially allowing threats to persist undetected. If confirmed malicious, this modification could enable attackers to bypass security measures, maintain persistence, and execute further malicious activities without being detected by quick scans. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12484,7 +12304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to change the ThrottleDetectionEventsRate of Windows Defender. The ThrottleDetectionEventsRate registry setting in Windows Defender is related to controlling the rate at which detection events are logged or reported by Windows Defender Antivirus. This registry setting determines how frequently Windows Defender logs or reports detection events. Adjusting the ThrottleDetectionEventsRate value can impact the logging frequency of detection events such as malware detections, scanning results, or security-related events recorded by Windows Defender. A higher value might mean that detection events are reported less frequently, potentially reducing the volume of recorded events, while a lower value could increase the reporting frequency, resulting in more frequent logs of detection events. +explanation = The following analytic detects modifications to the ThrottleDetectionEventsRate registry setting in Windows Defender. It leverages data from the Endpoint.Registry datamodel to identify changes in the registry path related to Windows Defender's event logging rate. This activity is significant because altering the ThrottleDetectionEventsRate can reduce the frequency of logged detection events, potentially masking malicious activities. If confirmed malicious, this could allow an attacker to evade detection by decreasing the visibility of security events, thereby hindering incident response and forensic investigations. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12494,7 +12314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to change the Windows Defender Wpp Tracing levels. The "WppTracingLevel" registry setting is typically related to Windows software tracing and diagnostics, specifically involving Windows Software Trace Preprocessor (WPP) tracing. WPP tracing is a mechanism used by developers to instrument code for diagnostic purposes, allowing for the collection of detailed logs and traces during software execution. It helps in understanding the behavior of the software, identifying issues, and analyzing its performance. Without specific documentation or references to "WppTracingLevel" within Windows Defender settings or its functionalities, it's challenging to provide precise details about its intended use or configuration within Windows Defender. Modifying registry settings without understanding their implications can affect system behavior or security. Always proceed cautiously and ensure changes align with best practices and organizational requirements. +explanation = The following analytic detects modifications to the Windows registry specifically targeting the "WppTracingLevel" setting within Windows Defender. This detection leverages data from the Endpoint.Registry data model to identify changes in the registry path associated with Windows Defender tracing levels. Such modifications are significant as they can impair the diagnostic capabilities of Windows Defender, potentially hiding malicious activities. If confirmed malicious, this activity could allow an attacker to evade detection and maintain persistence within the environment, leading to further compromise and data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12504,7 +12324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to change or disable Windows Defender smartscreen app install control. Microsoft Edge's App Install Control feature helps manage the installation of web-based applications. When attackers modify "ConfigureAppInstallControlEnabled" to 0, they are likely attempting to disable the App Install Control feature in Microsoft Edge. This change might allow users to bypass restrictions imposed by the browser on the installation of web-based applications. Disabling this feature might increase the risk of users being able to install potentially malicious or untrusted web applications without restrictions or controls imposed by the browser. This action could potentially lead to security vulnerabilities or compromise if users inadvertently install harmful applications. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender SmartScreen App Install Control feature. It leverages data from the Endpoint.Registry data model to identify changes to specific registry values. This activity is significant because disabling App Install Control can allow users to install potentially malicious web-based applications without restrictions, increasing the risk of security vulnerabilities. If confirmed malicious, this action could lead to the installation of harmful applications, potentially compromising the system and exposing sensitive information. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12514,7 +12334,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to define the threat action of Windows Defender. The ThreatSeverityDefaultAction registry setting in Windows Defender is used to define the default action taken by Windows Defender when it encounters threats of specific severity levels. A setting like ThreatSeverityDefaultAction is designed to define how Windows Defender responds to threats based on their severity. For example, it might determine whether Windows Defender quarantines, removes, or takes other actions against threats based on their severity levels. In this context, a registry value of 1 typically indicates an action to "clean," aiming to disinfect or resolve the detected threat, while a registry value of 9 signifies "no action," meaning that the antivirus software refrains from taking immediate steps against the identified threat. +explanation = The following analytic detects modifications to the Windows Defender ThreatSeverityDefaultAction registry setting. It leverages data from the Endpoint.Registry datamodel to identify changes in registry values that define how Windows Defender responds to threats. This activity is significant because altering these settings can impair the system's defense mechanisms, potentially allowing threats to go unaddressed. If confirmed malicious, this could enable attackers to bypass antivirus protections, leading to persistent threats and increased risk of data compromise or further system exploitation. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12524,7 +12344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The search looks for the deletion of Windows Defender context menu within the registry. This is consistent behavior with RAT malware across a fleet of endpoints. This particular behavior is executed when an adversary gains access to an endpoint and begins to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. +explanation = The following analytic detects the deletion of the Windows Defender context menu entry from the registry. It leverages data from the Endpoint datamodel, specifically monitoring registry actions where the path includes "*\\shellex\\ContextMenuHandlers\\EPP" and the action is 'deleted'. This activity is significant as it is commonly associated with Remote Access Trojan (RAT) malware attempting to disable security features. If confirmed malicious, this could allow an attacker to impair defenses, facilitating further malicious activities such as unauthorized access, persistence, and data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12534,7 +12354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The search looks for the deletion of Windows Defender main profile within the registry. This was used by RAT malware across a fleet of endpoints. This particular behavior is typically executed when an adversary gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. +explanation = The following analytic detects the deletion of the Windows Defender main profile registry key. It leverages data from the Endpoint.Registry datamodel, specifically monitoring for deleted actions within the Windows Defender registry path. This activity is significant as it indicates potential tampering with security defenses, often associated with Remote Access Trojans (RATs) and other malware. If confirmed malicious, this action could allow an attacker to disable Windows Defender, reducing the system's ability to detect and respond to further malicious activities, thereby compromising endpoint security. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12544,7 +12364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry by the Applocker utility that contains details or registry data values related to denying the execution of several security products. This technique was seen in Azorult malware where it drops an xml Applocker policy that will deny several AV products and then loaded by using PowerShell Applocker commandlet. +explanation = The following analytic detects modifications in the Windows registry by the Applocker utility that deny the execution of various security products. This detection leverages data from the Endpoint.Registry datamodel, focusing on specific registry paths and values indicating a "Deny" action against known antivirus and security software. This activity is significant as it may indicate an attempt to disable security defenses, a tactic observed in malware like Azorult. If confirmed malicious, this could allow attackers to bypass security measures, facilitating further malicious activities and persistence within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on organization use of Applocker. Filter as needed. @@ -12554,7 +12374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender Controlled Folder Access feature. The EnableControlledFolderAccess registry setting is associated with the Controlled Folder Access feature in Windows Defender. Controlled Folder Access is a security feature designed to protect certain folders from unauthorized access or modification by malicious applications, including ransomware. When EnableControlledFolderAccess is set to 0, it usually indicates that the Controlled Folder Access feature within Windows Defender is not active. Consequently, the protection mechanism for the specified folders against unauthorized access by potentially malicious applications or ransomware is not enabled. +explanation = The following analytic detects a modification in the Windows registry that disables the Windows Defender Controlled Folder Access feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the EnableControlledFolderAccess registry setting. This activity is significant because Controlled Folder Access is designed to protect critical folders from unauthorized access, including ransomware attacks. If this activity is confirmed malicious, it could allow attackers to bypass a key security feature, potentially leading to unauthorized access or modification of sensitive files. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12564,7 +12384,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable firewall and network protection section settings of windows security. The specific impact of this change depends on the context and the purpose behind modifying this registry value. In general, setting UILockdown to 1 might imply enforcing a restriction or lockdown in the user interface (UI) related to firewall and network protection settings within Windows Defender Security Center. This could potentially restrict users from modifying certain firewall or network protection settings through the UI. +explanation = The following analytic detects modifications in the Windows registry to disable firewall and network protection settings within Windows Defender Security Center. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the UILockdown registry value. This activity is significant as it may indicate an attempt to impair system defenses, potentially restricting users from modifying firewall or network protection settings. If confirmed malicious, this could allow an attacker to weaken the system's security posture, making it more vulnerable to further attacks and unauthorized access. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12574,7 +12394,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender protocol recognition feature. The DisableProtocolRecognition setting in Windows Defender is not a commonly known or documented registry setting. It's possible that this specific setting might not exist within the standard Windows Defender configurations or that it might be specific to certain environments, versions, or configurations. It might potentially control or influence the antivirus software's ability to recognize and handle specific protocols or communication methods used by malware or suspicious software. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender protocol recognition feature. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableProtocolRecognition" setting. This activity is significant because disabling protocol recognition can hinder Windows Defender's ability to detect and respond to malware or suspicious software. If confirmed malicious, this action could allow an attacker to bypass antivirus defenses, facilitating further malicious activities such as data exfiltration or system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12584,7 +12404,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender PUA protection. Setting PUAProtection to 0 typically disables the detection and protection against Potentially Unwanted Applications by Microsoft Defender Antivirus. Potentially Unwanted Applications include software that may not be inherently malicious but could exhibit behaviors that users may find undesirable, such as adware, browser toolbars, or software bundlers. Disabling this feature might be preferred in certain situations, but it's essential to consider potential security implications. Enabling PUA protection provides an additional layer of defense against software that might negatively impact user experience or security. +explanation = The following analytic detects a modification in the Windows registry to disable Windows Defender PUA protection by setting PUAProtection to 0. This detection leverages data from the Endpoint.Registry datamodel, focusing on registry path changes related to Windows Defender. Disabling PUA protection is significant as it reduces defenses against Potentially Unwanted Applications (PUAs), which, while not always malicious, can negatively impact user experience and security. If confirmed malicious, this activity could allow an attacker to introduce adware, browser toolbars, or other unwanted software, potentially compromising system integrity and user productivity. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12594,7 +12414,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable windows defender realtime signature delivery feature. This setting governs how Windows Defender Antivirus receives updated signature definitions for identifying and combating malware threats in real-time. The actual impact and behaviors associated with different values for RealtimeSignatureDelivery can vary based on specific Windows Defender configurations and policies. For instance, setting this value to 0 or 1 might control whether real-time signatures are delivered via different methods such as through Windows Update or directly from Microsoft's cloud-based services. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender real-time signature delivery feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender signature updates. This activity is significant because disabling real-time signature delivery can prevent Windows Defender from receiving timely malware definitions, reducing its effectiveness. If confirmed malicious, this action could allow attackers to bypass malware detection, leading to potential system compromise and persistent threats. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12604,7 +12424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender web content evaluation. The "EnableWebContentEvaluation" registry entry typically relates to security settings within Microsoft Edge or Internet Explorer, enabling the evaluation of web content for security purposes. When attackers modify "EnableWebContentEvaluation" to 0, they might attempt to disable the browser's capability to evaluate web content for security purposes. Disabling this feature could potentially impact the browser's ability to assess the security risks associated with web content, such as potentially malicious scripts, active content, or unsafe web elements. By turning off content evaluation, attackers might aim to exploit security vulnerabilities present in web content without triggering security warnings or blocks. This manipulation increases the risk of users accessing or interacting with malicious content, potentially leading to security compromises or system exploitation. +explanation = The following analytic detects modifications to the Windows registry entry "EnableWebContentEvaluation" to disable Windows Defender web content evaluation. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes where the registry value is set to "0x00000000". This activity is significant as it indicates an attempt to impair browser security features, potentially allowing malicious web content to bypass security checks. If confirmed malicious, this could lead to users interacting with harmful scripts or unsafe web elements, increasing the risk of system exploitation and security breaches. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12614,7 +12434,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender audit application guard. Microsoft Defender Application Guard provides enhanced security by isolating potentially malicious documents and websites in a containerized environment, protecting the system against various threats. Auditing and logging are essential components of security measures, providing visibility into activities within the isolated environment. Disabling auditing events within Application Guard might not be a standard or recommended practice since auditing is crucial for security monitoring and threat detection within the isolated container. However, there might be settings or configurations related to audit policies in the broader Windows Defender or operating system settings. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications to the Windows registry that disable Windows Defender Application Guard auditing. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because disabling auditing can hinder security monitoring and threat detection within the isolated environment, making it easier for malicious activities to go unnoticed. If confirmed malicious, this action could allow attackers to bypass Windows Defender protections, potentially leading to unauthorized access, data exfiltration, or further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12624,7 +12444,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender file hashes computation. The EnableFileHashComputation registry setting likely pertains to whether Windows Defender's MpEngine (Malware Protection Engine) computes file hashes. Setting this value to 0 might disable the file hash computation feature within Windows Defender, which could affect certain malware detection or scanning functionalities that rely on file hash analysis. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications to the Windows registry that disable Windows Defender's file hash computation by setting the EnableFileHashComputation value to 0. This detection leverages data from the Endpoint.Registry data model, focusing on changes to the specific registry path associated with Windows Defender. Disabling file hash computation can significantly impair Windows Defender's ability to detect and scan for malware, making it a critical behavior to monitor. If confirmed malicious, this activity could allow attackers to bypass Windows Defender, facilitating undetected malware execution and persistence in the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12634,7 +12454,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender generic ports. This registry can disable the sending of Watson events in Windows Defender. This is by preventing the transmission of generic or non-specific error reports to Microsoft's Windows Error Reporting service, commonly known as Watson. This kind of setting could potentially be employed to limit or control the data sent to Microsoft for error analysis, often in scenarios where privacy or specific reporting requirements are in place. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications in the Windows registry to disable Windows Defender generic reports. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "DisableGenericRePorts" registry value. This activity is significant as it can prevent the transmission of error reports to Microsoft's Windows Error Reporting service, potentially hiding malicious activities. If confirmed malicious, this action could allow attackers to bypass Windows Defender detections, reducing the visibility of their activities and increasing the risk of undetected system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12644,7 +12464,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender exploit guard network protection. The EnableNetworkProtection registry entry controls the activation or deactivation of Network Protection within Windows Defender Exploit Guard. When set to 1, it typically signifies that Network Protection is enabled, offering additional security measures against network-based threats by analyzing and blocking potentially malicious network activity. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications to the Windows registry that disable Windows Defender Network Protection. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the EnableNetworkProtection registry entry. This activity is significant because disabling Network Protection can leave the system vulnerable to network-based threats by preventing Windows Defender from analyzing and blocking malicious network activity. If confirmed malicious, this action could allow attackers to bypass security measures, potentially leading to unauthorized access, data exfiltration, or further compromise of the network. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12654,7 +12474,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable windows defender report infection information. Setting this registry key to 1, Instructs Windows Defender not to report detailed information about infections or threats detected on the system to Microsoft. Enabling this setting might limit or prevent the transmission of specific data related to infections, such as details about the detected malware, to Microsoft's servers for analysis or logging purposes. This registry is being abused by adversaries, threat actors and red-teamers to bypasses Windows Defender detections. +explanation = The following analytic detects modifications to the Windows registry that disable Windows Defender's infection reporting. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the "DontReportInfectionInformation" registry key. This activity is significant because it can prevent Windows Defender from reporting detailed threat information to Microsoft, potentially allowing malware to evade detection. If confirmed malicious, this action could enable attackers to bypass security measures, maintain persistence, and avoid detection, leading to prolonged unauthorized access and potential data breaches. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12664,7 +12484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender Scan On Update. The "DisableScanOnUpdate" registry setting in Windows Defender, when set to a value of 1, typically signifies the feature that prevents automatic scans from initiating when updates to Windows Defender or its antivirus definitions are installed. Any modifications to registry settings, it's important to ensure that changes align with security policies and best practices. Incorrect settings might affect the system's security or functionality. Always consider the implications and ensure changes are made based on accurate information and organizational requirements. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender Scan On Update feature. It leverages data from the Endpoint.Registry datamodel, specifically looking for changes to the "DisableScanOnUpdate" registry setting with a value of "0x00000001". This activity is significant because disabling automatic scans can leave systems vulnerable to malware and other threats. If confirmed malicious, this action could allow attackers to bypass Windows Defender, facilitating further compromise and persistence within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12674,7 +12494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable windows defender Signature Retirement. The DisableSignatureRetirement registry setting in Windows Defender controls the retirement or expiration of antivirus signatures used by Windows Defender Antivirus. When DisableSignatureRetirement is set to 1, it usually indicates that Windows Defender won't automatically retire or expire antivirus signatures. Antivirus signatures are files containing information about known malware and are used by Windows Defender to detect and protect against threats. Disabling signature retirement might prevent Windows Defender from automatically removing or retiring older or less relevant antivirus signatures. This can potentially increase the number of signatures in use and might impact system resources or the effectiveness of threat detection. +explanation = The following analytic detects modifications to the Windows registry that disable Windows Defender Signature Retirement. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the DisableSignatureRetirement registry setting. This activity is significant because disabling signature retirement can prevent Windows Defender from removing outdated antivirus signatures, potentially reducing its effectiveness in detecting threats. If confirmed malicious, this action could allow an attacker to evade detection by using older, less relevant signatures, thereby compromising the system's security posture. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12684,7 +12504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable windows defender phishing filter. This setting controls whether users can manually disable or modify the browser's built-in phishing filter. When attackers modify "PreventOverride" to 0, it might indicate an attempt to disable the prevention of user overrides for the phishing filter within Microsoft Edge. This change allows users to bypass or disable the built-in phishing protection provided by the browser. By allowing users to override the phishing filter, attackers may attempt to deceive users into visiting phishing websites or malicious pages without triggering warnings or protections from the browser's built-in security measures. This manipulation increases the risk of users unknowingly accessing potentially harmful websites, leading to potential security incidents or compromises. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender phishing filter. It leverages data from the Endpoint.Registry data model, focusing on changes to specific registry values related to Microsoft Edge's phishing filter settings. This activity is significant because disabling the phishing filter can allow attackers to deceive users into visiting malicious websites without triggering browser warnings. If confirmed malicious, this could lead to users unknowingly accessing harmful sites, resulting in potential security incidents or data compromises. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12694,7 +12514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to override windows defender smartscreen prompt. The "PreventSmartScreenPromptOverride" registry setting is associated with the Windows SmartScreen feature, specifically related to controlling whether users can override SmartScreen prompts. When attackers modify "PreventSmartScreenPromptOverride" to 0, it signifies an attempt to disable the prevention of user overrides for SmartScreen prompts. By doing so, attackers aim to allow users to bypass or ignore SmartScreen warnings or prompts. This change increases the risk by permitting users to disregard warnings about potentially unsafe or malicious files or websites that would typically trigger SmartScreen alerts. It could lead to users unintentionally executing or accessing malicious content, potentially resulting in security incidents or system compromises. +explanation = The following analytic detects modifications to the Windows registry that override the Windows Defender SmartScreen prompt. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "PreventSmartScreenPromptOverride" registry setting. This activity is significant because it indicates an attempt to disable the prevention of user overrides for SmartScreen prompts, potentially allowing users to bypass security warnings. If confirmed malicious, this could lead to users inadvertently executing or accessing harmful content, increasing the risk of security incidents or system compromises. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12704,7 +12524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to set windows defender smart screen level to warn. Setting the ShellSmartScreenLevel to warn implies a SmartScreen configuration where the system displays a warning prompt when users attempt to run or access potentially risky or unrecognized files or applications. This warning serves as a cautionary alert to users, advising them about the potential risks associated with the file or application they are trying to execute. Changing SmartScreen settings to "warn" might be employed by attackers to reduce the likelihood of triggering immediate suspicion from users when running malicious executables. By setting it to "warn," the system prompts a cautionary warning rather than outright blocking the execution, potentially increasing the chances of users proceeding with running the file despite the warning. +explanation = The following analytic detects modifications to the Windows registry that set the Windows Defender SmartScreen level to "warn." This detection leverages data from the Endpoint.Registry data model, specifically monitoring changes to the ShellSmartScreenLevel registry value. This activity is significant because altering SmartScreen settings to "warn" can reduce immediate suspicion from users, allowing potentially malicious executables to run with just a warning prompt. If confirmed malicious, this could enable attackers to execute harmful files, increasing the risk of successful malware deployment and subsequent system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12714,7 +12534,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic refers to a detection mechanism designed to identify when the Hypervisor-protected Code Integrity (HVCI) feature is disabled within the Windows registry. HVCI is a security feature in Windows 10 and Windows Server 2016 that helps protect the kernel and system processes from being tampered with by malicious code. HVCI relies on hardware-assisted virtualization and Microsoft's Hyper-V hypervisor to ensure that only kernel-mode code that has been signed by Microsoft or the system's hardware manufacturer can be executed. This prevents attackers from exploiting vulnerabilities to run unsigned code, like kernel-mode rootkits or other malicious software, at the kernel level. Disabling HVCI may expose the system to security risks and could be an indicator of a potential compromise or unauthorized activity. The analytic aims to detect and report events or configurations that lead to the disabling of HVCI. +explanation = The following analytic detects the disabling of Hypervisor-protected Code Integrity (HVCI) by monitoring changes in the Windows registry. It leverages data from the Endpoint datamodel, specifically focusing on registry paths and values related to HVCI settings. This activity is significant because HVCI helps protect the kernel and system processes from tampering by malicious code. If confirmed malicious, disabling HVCI could allow attackers to execute unsigned kernel-mode code, potentially leading to kernel-level rootkits or other severe security breaches. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = False positives will be limited to administrative scripts disabling HVCI. Filter as needed. @@ -12724,7 +12544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The search looks for the Registry Key DefenderApiLogger or DefenderAuditLogger set to disable. This is consistent with RAT malware across a fleet of endpoints. This particular behavior is typically executed when an adversary gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. +explanation = The following analytic detects the disabling of Windows Defender logging by identifying changes to the Registry keys DefenderApiLogger or DefenderAuditLogger set to disable. It leverages data from the Endpoint.Registry datamodel to monitor specific registry paths and values. This activity is significant as it is commonly associated with Remote Access Trojan (RAT) malware attempting to evade detection. If confirmed malicious, this action could allow an attacker to conceal their activities, making it harder to detect further malicious actions and maintain persistence on the compromised endpoint. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search. @@ -12734,7 +12554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execute rmdir commandline to delete files and directory tree. This technique has been observed in the actions of various malware strains, such as DarkGate, as they attempt to eliminate specific files or components during their cleanup operations within compromised hosts. Notably, this deletion method doesn't exclusively require elevated privileges and can be executed by regular users or network administrators, although it's not the typical approach used for file deletion. +explanation = The following analytic detects the execution of the 'rmdir' command with '/s' and '/q' options to delete files and directory trees. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. This activity is significant as it may indicate malware attempting to remove traces or components during cleanup operations. If confirmed malicious, this behavior could allow attackers to eliminate forensic evidence, hinder incident response efforts, and maintain persistence by removing indicators of compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.AE"]} known_false_positives = user and network administrator can execute this command. @@ -12744,7 +12564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects programs that have been started by forfiles.exe. According to Microsoft, the 'The forfiles command lets you run a command on or pass arguments to multiple files'. While this tool can be used to start legitimate programs, usually within the context of a batch script, it has been observed being used to evade protections on command line execution. +explanation = The following analytic detects the execution of programs initiated by forfiles.exe. This command is typically used to run commands on multiple files, often within batch scripts. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where forfiles.exe is the parent process. This activity is significant because forfiles.exe can be exploited to bypass command line execution protections, making it a potential vector for malicious activity. If confirmed malicious, this could allow attackers to execute arbitrary commands, potentially leading to unauthorized access or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.CM"]} known_false_positives = Some legacy applications may be run using pcalua.exe. Similarly, forfiles.exe may be used in legitimate batch scripts. Filter these results as needed. @@ -12754,7 +12574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects programs that have been started by pcalua.exe. pcalua.exe is the Microsoft Windows Program Compatability Assistant. While this tool can be used to start legitimate programs, it has been observed being used to evade protections on command line execution. +explanation = The following analytic detects programs initiated by pcalua.exe, the Microsoft Windows Program Compatibility Assistant. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process information. While pcalua.exe can start legitimate programs, it is significant because attackers may use it to bypass command line execution protections. If confirmed malicious, this activity could allow attackers to execute arbitrary commands, potentially leading to unauthorized actions, privilege escalation, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.CM"]} known_false_positives = Some legacy applications may be run using pcalua.exe. Filter these results as needed. @@ -12764,7 +12584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious excessive usage of forfiles.exe process. This event was seen in post exploitation tool WINPEAS that was used by Ransomware Prestige. Forfiles command lets you run a command on or pass arguments to multiple files. This Windows OS built-in tool being abused to list all files in specific directory or drive. +explanation = The following analytic detects excessive usage of the forfiles.exe process, which is often indicative of post-exploitation activities. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include process GUID, process name, and parent process. This activity is significant because forfiles.exe can be abused to execute commands on multiple files, a technique used by ransomware like Prestige. If confirmed malicious, this behavior could allow attackers to enumerate files, potentially leading to data exfiltration or further malicious actions. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12774,7 +12594,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS built-in tool FSUTIL to discover file system information. This tool is being abused or used by several adversaries or threat actor to query/list all drives, drive type, volume information or volume statistics by using the FSINFO parameter of this tool. This technique was seen in WINPEAS post exploitation tool that is being used by ransomware prestige to gain privilege and persistence to the targeted host. +explanation = The following analytic identifies the execution of the Windows built-in tool FSUTIL with the FSINFO parameter to discover file system information. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. Monitoring this activity is significant because FSUTIL can be abused by adversaries to gather detailed information about the file system, aiding in further exploitation. If confirmed malicious, this activity could enable attackers to map the file system, identify valuable data, and plan subsequent actions such as privilege escalation or persistence. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12784,7 +12604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows Explorer process with a URL within the command-line. Explorer.exe is known Windows process that handles start menu, taskbar, desktop and file manager. Many adversaries abuse this process, like DCRat malware, where it attempts to open the URL with the default browser application on the target host by putting the URL as a parameter on explorer.exe process. This anomaly detection might be a good pivot to check which user and how this process was executed, what is the parent process and what is the URL link. This technique is not commonly used to open an URL. +explanation = The following analytic identifies instances where the Windows Explorer process (explorer.exe) is executed with a URL in its command line. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because adversaries, such as those using DCRat malware, may abuse explorer.exe to open URLs with the default browser, which is an uncommon and suspicious behavior. If confirmed malicious, this technique could allow attackers to download and execute malicious payloads, leading to potential system compromise and further malicious activities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on legitimate applications or third party utilities. Filter out any additional parent process names. @@ -12794,7 +12614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the creation or modification of registry keys associated with new Outlook form installations that could indicate exploitation of CVE-2024-21378. The vulnerability allows for authenticated remote code execution via synced form objects by abusing the InProcServer32 registry key. The attack involves syncing malicious form objects that carry special properties and attachments used to "install" the form on a client, potentially leading to arbitrary file and registry key creation under HKEY_CLASSES_ROOT (HKCR), and ultimately, remote code execution. This detection focuses on monitoring for registry modifications involving InProcServer32 keys or equivalent that are linked to Outlook form installations, which are indicative of an attempt to exploit this vulnerability. +explanation = The following analytic detects the creation or modification of registry keys associated with new Outlook form installations, potentially indicating exploitation of CVE-2024-21378. It leverages data from the Endpoint.Registry datamodel, focusing on registry paths involving InProcServer32 keys linked to Outlook forms. This activity is significant as it may signify an attempt to achieve authenticated remote code execution via malicious form objects. If confirmed malicious, this could allow an attacker to create arbitrary files and registry keys, leading to remote code execution and potential full system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1566", "T1112"], "nist": ["DE.AE"]} known_false_positives = False positives are possible if the organization adds new forms to Outlook via an automated method. Filter by name or path to reduce false positives. @@ -12804,7 +12624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process that loads the credui.dll module. This legitimate module is typically abused by adversaries, threat actors and red teamers to create a credential UI prompt dialog box to lure users for possible credential theft or can be used to dump the credentials of a targeted host. This hunting query is a good pivot to check why the process loaded this dll and if it is a legitimate file. This hunting query may hit false positive for a third party application that uses a credential login UI for user login. +explanation = The following analytic detects a process loading the credui.dll or wincredui.dll module. This detection leverages Sysmon EventCode 7 to identify instances where these DLLs are loaded by processes outside typical system directories. This activity is significant because adversaries often abuse these modules to create fake credential prompts or dump credentials, posing a risk of credential theft. If confirmed malicious, this activity could allow attackers to harvest user credentials, leading to unauthorized access and potential lateral movement within the network. how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1056.002", "T1056"], "nist": ["DE.AE"]} known_false_positives = this module can be loaded by a third party application. Filter is needed. @@ -12814,10 +12634,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies instances where the Windows InstallUtil.exe binary loads `vaultcli.dll` and `Samlib.dll`. This technique can be employed to execute code that bypasses application control and captures credentials using tools like Mimikatz. \ -When `InstallUtil.exe` is used maliciously, it typically specifies the path to an executable on the filesystem. It is important to observe the parent process in such cases. Suspicious activity often involves being spawned from non-standard processes such as `Cmd.exe`, `PowerShell.exe`, or `Explorer.exe`. \ -Conversely, when used by developers, it is usually accompanied by multiple command-line switches/arguments and originates from Visual Studio. \ -During triage, review any resulting network connections, file modifications, and concurrent processes. Capture any artifacts for further review.' +explanation = The following analytic detects instances where the Windows InstallUtil.exe binary loads `vaultcli.dll` and `Samlib.dll`. This detection leverages Sysmon EventCode 7 to identify these specific DLL loads. This activity is significant because it can indicate an attempt to execute code that bypasses application control and captures credentials using tools like Mimikatz. If confirmed malicious, this behavior could allow an attacker to steal credentials, potentially leading to unauthorized access and further compromise of the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and module loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]} known_false_positives = Typically, this will not trigger because, by its very nature, InstallUtil does not require credentials. Filter as needed. @@ -12837,10 +12654,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows InstallUtil.exe binary making a remote network connection. This technique may be used to download and execute code while bypassing application control. \ -When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \ -If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \ -During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further. +explanation = The following analytic detects the Windows InstallUtil.exe binary making a remote network connection. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and network telemetry. This activity is significant because InstallUtil.exe can be exploited to download and execute malicious code, bypassing application control mechanisms. If confirmed malicious, an attacker could achieve code execution, potentially leading to further system compromise, data exfiltration, or lateral movement within the network. Analysts should review the parent process, network connections, and any associated file modifications to determine the legitimacy of this activity. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements. @@ -12850,11 +12664,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows InstallUtil.exe binary. This will execute code while bypassing application control using the `/u` (uninstall) switch. \ -InstallUtil uses the functions install and uninstall within the System.Configuration.Install namespace to process .net assembly. Install function requires admin privileges, however, uninstall function can be run as an unprivileged user. \ -When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \ -If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \ -During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further. +explanation = The following analytic detects the use of the Windows InstallUtil.exe binary with the `/u` (uninstall) switch, which can execute code while bypassing application control. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This activity is significant because it can indicate an attempt to execute malicious code without administrative privileges. If confirmed malicious, an attacker could achieve code execution, potentially leading to further system compromise or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present. Filter as needed by parent process or application. @@ -12864,11 +12674,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows InstallUtil.exe binary making a remote network connection. This technique may be used to download and execute code while bypassing application control using the `/u` (uninstall) switch. \ -InstallUtil uses the functions install and uninstall within the System.Configuration.Install namespace to process .net assembly. Install function requires admin privileges, however, uninstall function can be run as an unprivileged user. \ -When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \ -If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \ -During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further. +explanation = The following analytic identifies the use of Windows InstallUtil.exe making a remote network connection using the `/u` (uninstall) switch. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process and network activity data. This behavior is significant as it may indicate an attempt to download and execute code while bypassing application control mechanisms. If confirmed malicious, this activity could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements. @@ -12878,10 +12684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows InstallUtil.exe binary passing a HTTP request on the command-line. This technique may be used to download and execute code while bypassing application control. \ -When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \ -If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \ -During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further. +explanation = The following analytic detects the use of Windows InstallUtil.exe with an HTTP or HTTPS URL in the command line. This is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions containing URLs. This activity is significant as it may indicate an attempt to download and execute malicious code, potentially bypassing application control mechanisms. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, or persistent access within the environment. Analysts should review the parent process, network connections, file modifications, and related processes for further investigation. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]} known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements. @@ -12891,7 +12694,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of a delivered ISO file that has been mounted and the afformention lnk or file opened within it. When the ISO file is opened, the files are saved in the %USER%\AppData\Local\Temp\\ path. The analytic identifies .iso.lnk written to the path. The name of the ISO file is prepended. +explanation = The following analytic detects the creation of .iso.lnk files in the %USER%\AppData\Local\Temp\\ path, indicating that an ISO file has been mounted and accessed. This detection leverages the Endpoint.Filesystem data model, specifically monitoring file creation events in the Windows Recent folder. This activity is significant as it may indicate the delivery and execution of potentially malicious payloads via ISO files. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1566.001", "T1566", "T1204.001", "T1204"], "nist": ["DE.AE"]} known_false_positives = False positives may be high depending on the environment and consistent use of ISOs mounting. Restrict to servers, or filter out based on commonly used ISO names. Filter as needed. @@ -12901,7 +12704,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the process name of java.exe and w3wp.exe spawning a Windows shell. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell). The shells included in the macro are "cmd.exe", "powershell.exe". Upon triage, review parallel processes and command-line arguments to determine legitimacy. +explanation = The following analytic identifies instances where java.exe or w3wp.exe spawns a Windows shell, such as cmd.exe or powershell.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant as it may indicate exploitation attempts, such as those related to CVE-2021-44228 (Log4Shell). If confirmed malicious, attackers could execute arbitrary commands, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on that. @@ -12911,7 +12714,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a local successful authentication event on a Windows endpoint using the Kerberos package. The target user security identified will be set to the built-in local Administrator account, along with the remote address as localhost - 127.0.0.1. This may be indicative of a kerberos relay attack. Upon triage, review for recently ran binaries on disk. In addition, look for new computer accounts added to Active Directory and other anomolous AD events. +explanation = The following analytic identifies a local successful authentication event on a Windows endpoint using the Kerberos package. It detects EventCode 4624 with LogonType 3 and source address 127.0.0.1, indicating a login to the built-in local Administrator account. This activity is significant as it may suggest a Kerberos relay attack, a method attackers use to escalate privileges. If confirmed malicious, this could allow an attacker to gain unauthorized access to sensitive systems, execute arbitrary code, or create new accounts in Active Directory, leading to potential system compromise. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4624 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]} known_false_positives = False positives are possible, filtering may be required to restrict to workstations vs domain controllers. Filter as needed. @@ -12921,7 +12724,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify instances where Dynamic Link Libraries (DLLs) with a known history of being exploited are created in locations that are not typical for their use. This could indicate that an attacker is attempting to exploit the DLL search order hijacking or sideloading techniques. DLL search order hijacking involves tricking an application into loading a malicious DLL instead of the legitimate one it was intending to load. This is often achieved by placing the malicious DLL in a directory that is searched before the directory containing the legitimate DLL. Sideloading, similarly, involves placing a malicious DLL with the same name as a legitimate DLL that an application is known to load, in a location that the application will search before finding the legitimate version. Both of these techniques can be used by attackers to execute arbitrary code, maintain persistence on a system, and potentially elevate their privileges, all while appearing as legitimate operations to the untrained eye. This analytic aims to shed light on such suspicious activities by monitoring for the creation of known abused DLLs in unconventional locations, thereby helping in the early detection of these stealthy attack techniques. +explanation = The following analytic identifies the creation of Dynamic Link Libraries (DLLs) with a known history of exploitation in atypical locations. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and filesystem events. This activity is significant as it may indicate DLL search order hijacking or sideloading, techniques used by attackers to execute arbitrary code, maintain persistence, or escalate privileges. If confirmed malicious, this activity could allow attackers to blend in with legitimate operations, posing a severe threat to system integrity and security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` and `Filesystem` nodes of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574.002", "T1574"], "nist": ["DE.AE"]} known_false_positives = This analytic may flag instances where DLLs are loaded by user mode programs for entirely legitimate and benign purposes. It is important for users to be aware that false positives are not only possible but likely, and that careful tuning of this analytic is necessary to distinguish between malicious activity and normal, everyday operations of applications. This may involve adjusting thresholds, whitelisting known good software, or incorporating additional context from other security tools and logs to reduce the rate of false positives. @@ -12931,7 +12734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a potential suspicious process loading dll modules related to Graphicalproton backdoor implant of SVR. These DLL modules have been observed in SVR attacks, commonly used to install backdoors on targeted hosts. This anomaly detection highlights the need for thorough investigation and immediate mitigation measures to safeguard the network against potential breaches. +explanation = The following analytic detects the loading of DLL modules associated with the GraphicalProton backdoor implant, commonly used by SVR in targeted attacks. It leverages Sysmon EventCode 7 to identify specific DLLs loaded by processes. This activity is significant as it may indicate the presence of a sophisticated backdoor, warranting immediate investigation. If confirmed malicious, the attacker could gain persistent access to the compromised host, potentially leading to further exploitation and data exfiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -12951,8 +12754,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4769, `A Kerberos service ticket was requested`, to identify more than 30 computer service ticket requests from one source. When a domain joined endpoint connects to other remote endpoint, it will first request a Kerberos Service Ticket with the computer name as the Service Name. A user requesting a large number of computer service tickets for different endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. \ -Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold as needed. +explanation = The following analytic detects a high volume of Kerberos service ticket requests, specifically more than 30, from a single source within a 5-minute window. It leverages Event ID 4769, which logs when a Kerberos service ticket is requested, focusing on requests with computer names as the Service Name. This behavior is significant as it may indicate malicious activities such as lateral movement, malware staging, or reconnaissance. If confirmed malicious, an attacker could gain unauthorized access to multiple endpoints, potentially compromising the entire network. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1135", "T1078"], "nist": ["DE.AE"]} known_false_positives = An single endpoint requesting a large number of kerberos service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems. @@ -12972,7 +12774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Ldifde.exe, which provides the ability to create, modify, or delete LDAP directory objects. Natively, the binary is only installed on a domain controller. However, adversaries or administrators may install the Windows Remote Server Admin Tools for ldifde.exe. Ldifde.exe is a Microsoft Windows command-line utility used to import or export LDAP directory entries. LDAP stands for Lightweight Directory Access Protocol, which is a protocol used for accessing and managing directory information services over an IP network. LDIF, on the other hand, stands for LDAP Data Interchange Format, a standard plain-text data interchange format for representing LDAP directory entries. -i This is a flag used with Ldifde.exe to denote import mode. In import mode, Ldifde.exe takes an LDIF file and imports its contents into the LDAP directory. The data in the LDIF file might include new objects to be created, or modifications or deletions to existing objects. -f This flag is used to specify the filename of the LDIF file that Ldifde.exe will import from (in the case of the -i flag) or export to (without the -i flag). For example, if you wanted to import data from a file called data.ldif, you would use the command ldifde -i -f data.ldif. Keep in mind that while the use of Ldifde.exe is legitimate in many contexts, it can also be used maliciously. For instance, an attacker who has gained access to a domain controller could potentially use Ldifde.exe to export sensitive data or make unauthorized changes to the directory. Therefore, it's important to monitor for unusual or unauthorized use of this tool. +explanation = The following analytic identifies the use of Ldifde.exe, a command-line utility for creating, modifying, or deleting LDAP directory objects. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution and command-line arguments. Monitoring Ldifde.exe is significant because it can be used by attackers to manipulate directory objects, potentially leading to unauthorized changes or data exfiltration. If confirmed malicious, this activity could allow an attacker to gain control over directory services, escalate privileges, or access sensitive information within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1105", "T1069.002"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter as needed. @@ -12982,7 +12784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain organizational unit for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell Script Block Logging (EventCode=4104) to query Active Directory for domain organizational units. This detection leverages PowerShell operational logs to identify script blocks containing `[adsisearcher]`, `objectcategory=organizationalunit`, and `findAll()`. This activity is significant as it indicates potential reconnaissance efforts by adversaries to gain situational awareness of the domain structure. If confirmed malicious, this could lead to further exploitation, such as privilege escalation or lateral movement within the network. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -12992,7 +12794,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages events 4625 and 4624 to identify an endpoint using the builtin local Administrator account to authenticate to a large numbers of endpoints. Specifically, the logic will trigger when an endpoints attempts to authenticate to more than 30 target computers within a 5 minute timespan. This behavior could represent an adversary who has obtained access to local credentials and is trying to validate if these credentials work on other hosts to escalate their privileges. As environments differ across organizations, security teams should customize the thresholds of this detection as needed. +explanation = The following analytic detects attempts to authenticate using the built-in local Administrator account across more than 30 endpoints within a 5-minute window. It leverages Windows Event Logs, specifically events 4625 and 4624, to identify this behavior. This activity is significant as it may indicate an adversary attempting to validate stolen local credentials across multiple hosts, potentially leading to privilege escalation. If confirmed malicious, this could allow the attacker to gain widespread access and control over numerous systems within the network, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.004"], "nist": ["DE.CM"]} known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed. @@ -13002,7 +12804,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry related to the Local Security Authority (LSA) in Windows. This registry value is used to determine whether the system should store passwords in the weaker Lan Manager (LM) hash format. Setting it to 0 disables this feature, meaning LM hashes will be stored. Modifying these settings should be done carefully and with a clear understanding of the impact it might have on system security and functionality. This command is often used in security configurations to enforce stronger password storage methods and prevent the storage of weaker LM hashes, which are more susceptible to certain types of attacks. This TTP detection can be a good indicator of any process or user that tries to modify the LSA security configuration. +explanation = The following analytic detects modifications to the Windows registry related to the Local Security Authority (LSA) NoLMHash setting. It identifies when the registry value is set to 0, indicating that the system will store passwords in the weaker Lan Manager (LM) hash format. This detection leverages registry activity logs from endpoint data sources like Sysmon or EDR tools. Monitoring this activity is crucial as it can indicate attempts to weaken password storage security. If confirmed malicious, this could allow attackers to exploit weaker LM hashes, potentially leading to unauthorized access and credential theft. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.004"], "nist": ["DE.CM"]} known_false_positives = Administrator may change this registry setting. @@ -13012,7 +12814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a possible windows application having a SMTP connection in a non common installation path in windows operating system.This network protocol is being used by adversaries, threat actors and malware like AgentTesla as a Command And Control communication to transfer its collected stolen information like the desktop screenshots, browser information and system information of a targeted or compromised host. +explanation = The following analytic detects a Windows application establishing an SMTP connection from a non-common installation path. It leverages Sysmon EventCode 3 to identify processes not typically associated with email clients (e.g., Thunderbird, Outlook) making SMTP connections. This activity is significant as adversaries, including malware like AgentTesla, use such connections for Command and Control (C2) communication to exfiltrate stolen data. If confirmed malicious, this behavior could lead to unauthorized data exfiltration, including sensitive information like desktop screenshots, browser data, and system details, compromising the affected host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 3 connection events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]} known_false_positives = third party application may use this network protocol as part of its feature. Filter is needed. @@ -13022,7 +12824,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious process that delete mark-of-the-web data stream. This technique has been observed in various instances of malware and adversarial activities aimed at circumventing security restrictions within the Windows Operating System, particularly pertaining to files downloaded from the internet. An example of this scenario is demonstrated by Ave Maria RAT, which attempts to delete this data stream as a means to evade such restrictions. +explanation = The following analytic identifies a suspicious process that deletes the Mark-of-the-Web (MOTW) data stream. It leverages Sysmon EventCode 23 to detect when a file's Zone.Identifier stream is removed. This activity is significant because it is a common technique used by malware, such as Ave Maria RAT, to bypass security restrictions on files downloaded from the internet. If confirmed malicious, this behavior could allow an attacker to execute potentially harmful files without triggering security warnings, leading to further compromise of the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the deleted target file name, process name and process id from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.005"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13032,7 +12834,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious parent process of explorer.exe. Explorer is usually executed by userinit.exe that will exit after execution that causes the main explorer.exe no parent process. Some malware like qakbot spawn another explorer.exe to inject its code. This TTP detection is a good indicator that a process spawning explorer.exe might inject code or masquerading its parent child process to evade detections. +explanation = The following analytic identifies instances where explorer.exe is spawned by unusual parent processes such as cmd.exe, powershell.exe, or regsvr32.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant because explorer.exe is typically initiated by userinit.exe, and deviations from this norm can indicate code injection or process masquerading attempts by malware like Qakbot. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13042,7 +12844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious msdtc.exe with specific command-line parameters, particularly -a or -b, which are regarded as potential indicators of the presence of the insidious PlugX malware. This malware is notorious for its covert operations and is frequently utilized by threat actors for unauthorized access, data exfiltration, and espionage. The analytic's focus on the -a or -b command-line parameters within msdtc.exe is rooted in the PlugX malware's sophisticated tactic of masquerading its activities. To elude detection, PlugX employs a technique where it injects a concealed, headless PlugX Dynamic Link Library (DLL) module into the legitimate msdtc.exe process. By leveraging these specific command-line parameters, the malware attempts to disguise its presence within a system's legitimate processes, thereby evading immediate suspicion. +explanation = The following analytic identifies the execution of msdtc.exe with specific command-line parameters (-a or -b), which are indicative of the PlugX malware. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because PlugX uses these parameters to masquerade its malicious operations within legitimate processes, making it harder to detect. If confirmed malicious, this behavior could allow attackers to gain unauthorized access, exfiltrate data, and conduct espionage, severely compromising the affected system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13052,7 +12854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = As simple as it sounds, this analytic identifies when the native mimikatz.exe binary executes on Windows. It does look for the original file name as well, just in case the binary is renamed. Adversaries sometimes bring in the default binary and run it directly. Benjamin Delpy originally created Mimikatz as a proof of concept to show Microsoft that its authentication protocols were vulnerable to an attack. Instead, he inadvertently created one of the most widely used and downloaded threat actor tools of the past 20 years. Mimikatz is an open-source application that allows users to view and save authentication credentials such as Kerberos tickets. +explanation = The following analytic identifies the execution of the native mimikatz.exe binary on Windows systems, including instances where the binary is renamed. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because Mimikatz is a widely used tool for extracting authentication credentials, posing a severe security risk. If confirmed malicious, this activity could allow attackers to obtain sensitive credentials, escalate privileges, and move laterally within the network, leading to potential data breaches and system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as this is directly looking for Mimikatz, the credential dumping utility. @@ -13072,7 +12874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry related to authentication level settings. This registry is the configuration for authentication level settings within the Terminal Server Client settings in Windows. AuthenticationLevelOverride might be used to control or override the authentication level used by the Terminal Server Client for remote connections. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. +explanation = The following analytic detects modifications to the Windows registry key "AuthenticationLevelOverride" within the Terminal Server Client settings. It leverages data from the Endpoint.Registry datamodel to identify changes where the registry value is set to 0x00000000. This activity is significant as it may indicate an attempt to override authentication levels for remote connections, a tactic used by DarkGate malware for malicious installations. If confirmed malicious, this could allow attackers to gain unauthorized remote access, potentially leading to data exfiltration or further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13082,7 +12884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will "Treat minor updates like other updates". +explanation = The following analytic identifies a suspicious modification to the Windows auto update configuration registry. It detects changes to the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\\AutoInstallMinorUpdates" with a value of "0x00000000". This activity is significant as it is commonly used by adversaries, including malware like RedLine Stealer, to bypass detection and deploy additional payloads. If confirmed malicious, this modification could allow attackers to evade defenses, potentially leading to further system compromise and exploitation of zero-day vulnerabilities. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13092,7 +12894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update notification. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will switch the automatic windows update to "Notify before download". +explanation = The following analytic detects a suspicious modification to the Windows registry that changes the auto-update notification setting to "Notify before download." This detection leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because it is a known technique used by adversaries, including malware like RedLine Stealer, to evade detection and potentially deploy additional payloads. If confirmed malicious, this modification could allow attackers to bypass security measures, maintain persistence, and exploit vulnerabilities on the target host. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13102,7 +12904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious registry modification to change the default icon association of windows to ransomware . This technique was seen in Lockbit ransomware where it modified the default icon association of the compromised Windows OS host with its dropped ransomware icon file as part of its defacement payload. This registry is not commonly modified by a normal user so having this anomaly detection may help to catch possible lockbit ransomware infection or other malware. +explanation = The following analytic detects suspicious modifications to the Windows registry's default icon settings, a technique associated with Lockbit ransomware. It leverages data from the Endpoint Registry data model, focusing on changes to registry paths under "*HKCR\\*\\defaultIcon\\(Default)*". This activity is significant as it is uncommon for normal users to modify these settings, and such changes can indicate ransomware infection or other malware. If confirmed malicious, this could lead to system defacement and signal a broader ransomware attack, potentially compromising sensitive data and system integrity. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -13112,7 +12914,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry related to DisableRestrictedAdmin. This registry entry is used to control the behavior of Restricted Admin mode, which is a security feature that limits the exposure of sensitive credentials when connecting remotely to another computer. When this registry value is set to 0 it indicates that Restricted Admin mode is enabled (default behavior). As with any modifications to registry settings, changing this entry should be approached cautiously, ensuring a clear understanding of the implications for system security and functionality. Unauthorized changes to these security settings can pose risks and should be monitored closely for any signs of tampering or unauthorized alterations. +explanation = The following analytic detects modifications to the Windows registry entry "DisableRestrictedAdmin," which controls the Restricted Admin mode behavior. This detection leverages registry activity logs from endpoint data sources like Sysmon or Carbon Black. Monitoring this activity is crucial as changes to this setting can disable a security feature that limits credential exposure during remote connections. If confirmed malicious, an attacker could weaken security controls, increasing the risk of credential theft and unauthorized access to sensitive systems. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrator may change this registry setting. Filter as needed. @@ -13122,7 +12924,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to disable toast notifications. This Windows Operating System feature is responsible for alerting or notifying user if application or OS need some updates. Adversaries and malwares like Azorult abuse this technique to disable important update notification in compromised host. This anomaly detection is a good pivot to look for further events related to defense evasion and execution. +explanation = The following analytic detects modifications to the Windows registry that disable toast notifications. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\PushNotifications\\ToastEnabled*" with a value set to "0x00000000". This activity is significant because disabling toast notifications can prevent users from receiving critical system and application updates, which adversaries like Azorult exploit for defense evasion. If confirmed malicious, this action could allow attackers to operate undetected, leading to prolonged persistence and potential further compromise of the system. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13132,7 +12934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender raw write notification feature. This policy controls whether raw volume write notifications are sent to behavior monitoring or not. This registry was recently identified in Azorult malware to bypass Windows Defender detections or behavior monitoring in terms of volume write. +explanation = The following analytic detects modifications to the Windows registry that disable the Windows Defender raw write notification feature. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the registry path associated with Windows Defender's real-time protection settings. This activity is significant because disabling raw write notifications can allow malware, such as Azorult, to bypass Windows Defender's behavior monitoring, potentially leading to undetected malicious activities. If confirmed malicious, this could enable attackers to execute code, persist in the environment, and access sensitive information without detection. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. Filter as needed. @@ -13142,7 +12944,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification to disable Windows Defender notification. This technique was being abused by several adversaries, malware authors and also red-teamers to evade detection on the targeted machine. RedLine Stealer is one of the malware we've seen that uses this technique to bypass Windows defender detection. +explanation = The following analytic detects a suspicious registry modification aimed at disabling Windows Defender notifications. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows Defender Security Center\\Notifications\\DisableNotifications" with a value of "0x00000001". This activity is significant as it indicates an attempt to evade detection by disabling security alerts, a technique used by adversaries and malware like RedLine Stealer. If confirmed malicious, this could allow attackers to operate undetected, increasing the risk of further compromise and data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13152,7 +12954,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to disable windows center notifications. This Windows Operating System feature is responsible for alerting or notifying user if application or OS need some updates. Adversaries and malwares like Azorult abuse this technique to disable important update notification in compromised host. This anomaly detection is a good pivot to look for further events related to defense evasion and execution. +explanation = The following analytic detects modifications to the Windows registry aimed at disabling Windows Security Center notifications. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the registry path "*\\Windows\\CurrentVersion\\ImmersiveShell\\UseActionCenterExperience*" with a value of "0x00000000". This activity is significant as it can indicate an attempt by adversaries or malware, such as Azorult, to evade defenses by suppressing critical update notifications. If confirmed malicious, this could allow attackers to persist undetected, potentially leading to further exploitation and compromise of the host system. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13162,7 +12964,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to DisableRemoteDesktopAntiAlias. This registry setting might be intended to manage or control anti-aliasing behavior (smoothing of edges and fonts) within Remote Desktop sessions. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. +explanation = The following analytic detects modifications to the Windows registry key "DisableRemoteDesktopAntiAlias" with a value set to 0x00000001. This detection leverages data from the Endpoint datamodel, specifically monitoring changes in the Registry node. This activity is significant as it may indicate the presence of DarkGate malware, which alters this registry setting to enhance its remote desktop capabilities. If confirmed malicious, this modification could allow an attacker to maintain persistence and control over the compromised host, potentially leading to further exploitation and data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13172,7 +12974,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable security settings of Terminal Services. altering or disabling security settings within Terminal Services. Terminal Services, now known as Remote Desktop Services (RDS) in more recent Windows versions, allows users to access applications, data, and even an entire desktop remotely. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. +explanation = The following analytic detects modifications to the Windows registry that disable security settings for Terminal Services. It leverages the Endpoint data model, specifically monitoring changes to the registry path associated with Terminal Services security settings. This activity is significant because altering these settings can weaken the security posture of Remote Desktop Services, potentially allowing unauthorized remote access. If confirmed malicious, such modifications could enable attackers to gain persistent remote access to the system, facilitating further exploitation and data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13182,7 +12984,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to disable Windows error reporting settings. This Windows feature allows the user to report bugs, errors, failure or problems encountered in specific application or processes. Adversaries use this technique to hide any error or failure that some of its malicious components trigger. +explanation = The following analytic detects modifications in the Windows registry to disable Windows Error Reporting (WER) settings. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to registry paths related to WER with a value set to "0x00000001". This activity is significant as adversaries may disable WER to suppress error notifications, hiding the presence of malicious activities. If confirmed malicious, this could allow attackers to operate undetected, potentially leading to prolonged persistence and further exploitation within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13192,7 +12994,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies modification in the Windows registry to prevent user running specific computer programs that could aid them in manually removing malware or detecting it using security products. This technique was recently identified in Azorult malware where it uses this registry value to prevent several AV products to execute on the compromised host machine. +explanation = The following analytic detects modifications to the Windows registry aimed at preventing the execution of specific computer programs. It leverages data from the Endpoint.Registry datamodel, focusing on changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\DisallowRun*" with a value of "0x00000001". This activity is significant as it can indicate an attempt to disable security tools, a tactic used by malware like Azorult. If confirmed malicious, this could allow an attacker to evade detection and maintain persistence on the compromised host. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. Filter as needed. @@ -13202,7 +13004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will disable Windos update functionality, and may cause connection to public services such as the Windows Store to stop working. This policy applies only when this PC is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy. +explanation = The following analytic detects a suspicious modification to the Windows registry that disables automatic updates. It leverages data from the Endpoint datamodel, specifically monitoring changes to the registry path "*\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\DoNotConnectToWindowsUpdateInternetLocations" with a value of "0x00000001". This activity is significant as it can be used by adversaries, including malware like RedLine Stealer, to evade detection and prevent the system from receiving critical updates. If confirmed malicious, this could allow attackers to exploit vulnerabilities, persist in the environment, and potentially deploy additional payloads. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13212,7 +13014,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows Error Reporting registry to DontShowUI. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. When this registry value is present and set to a specific configuration, it can influence the behavior of error reporting dialogs or prompts, suppressing them from being displayed to the user.For instance, setting DontShowUI to a value of 1 often indicates that the Windows Error Reporting UI prompts will be suppressed, meaning users won't see error reporting pop-ups when errors occur. +explanation = The following analytic detects modifications to the Windows Error Reporting registry key "DontShowUI" to suppress error reporting dialogs. It leverages data from the Endpoint datamodel's Registry node to identify changes where the registry value is set to 0x00000001. This activity is significant as it is commonly associated with DarkGate malware, which uses this modification to avoid detection during its installation. If confirmed malicious, this behavior could allow attackers to maintain a low profile, avoiding user alerts and potentially enabling further malicious activities without user intervention. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13222,7 +13024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows linked connection configuration. This technique was being abused by several adversaries, malware like BlackByte ransomware to enable the linked connections feature, that allows network shares to be accessed using both standard and administrator-level privileges simultaneously. By default, Windows does not enable this feature to enhance security. +explanation = The following analytic detects a suspicious modification to the Windows registry setting for EnableLinkedConnections. It leverages data from the Endpoint.Registry datamodel to identify changes where the registry path is "*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLinkedConnections" and the value is set to "0x00000001". This activity is significant because enabling linked connections can allow network shares to be accessed with both standard and administrator-level privileges, a technique often abused by malware like BlackByte ransomware. If confirmed malicious, this could lead to unauthorized access to sensitive network resources, escalating the attacker's privileges. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13232,7 +13034,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows long path enable configuration. This technique was being abused by several adversaries, malware like BlackByte to enable long file path support in the operating system. By default, Windows has a limitation on the maximum length of a file path, which is set to 260 characters. Enabling the LongPathsEnabled setting allows you to work with file paths longer than 260 characters. +explanation = The following analytic detects a modification to the Windows registry setting "LongPathsEnabled," which allows file paths longer than 260 characters. This detection leverages data from the Endpoint.Registry datamodel, focusing on changes to the specific registry path and value. This activity is significant because adversaries, including malware like BlackByte, exploit this setting to bypass file path limitations, potentially aiding in evasion techniques. If confirmed malicious, this modification could facilitate the execution of long-path payloads, aiding in persistence and further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13242,7 +13044,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows max connection per server configuration. This particular technique has been observed in various threat actors, adversaries, and even in malware such as the Warzone (Ave Maria) RAT. By altering the max connection per server setting in the Windows registry, attackers can potentially increase the number of concurrent connections allowed to a remote server. This modification could be exploited for various malicious purposes, including facilitating distributed denial-of-service (DDoS) attacks or enabling more effective lateral movement within a compromised network. +explanation = The following analytic identifies a suspicious modification of the Windows registry setting for max connections per server. It detects changes to specific registry paths using data from the Endpoint.Registry datamodel. This activity is significant because altering this setting can be exploited by attackers to increase the number of concurrent connections to a remote server, potentially facilitating DDoS attacks or enabling more effective lateral movement within a compromised network. If confirmed malicious, this could lead to network disruption or further compromise of additional systems. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13252,7 +13054,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will allow "Logged-on user gets to choose whether or not to restart his or her compute". +explanation = The following analytic detects a suspicious modification to the Windows registry that disables automatic reboot with a logged-on user. This detection leverages the Endpoint data model to identify changes to the registry path `SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoRebootWithLoggedOnUsers` with a value of `0x00000001`. This activity is significant as it is commonly used by adversaries, including malware like RedLine Stealer, to evade detection and maintain persistence. If confirmed malicious, this could allow attackers to bypass security measures and deploy additional payloads without interruption. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13262,7 +13064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will "Disable Automatic Updates". +explanation = The following analytic identifies a suspicious modification to the Windows registry that disables automatic updates. It detects changes to the registry path `SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate` with a value of `0x00000001`. This activity is significant as it is commonly used by adversaries, including malware like RedLine Stealer, to evade detection and maintain persistence. If confirmed malicious, this could allow attackers to bypass security updates, leaving the system vulnerable to further exploitation and potential zero-day attacks. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13272,7 +13074,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies alterations in the Windows registry aimed at restricting wallpaper modifications. This tactic has been exploited by the Rhysida ransomware as a part of its destructive payload within compromised systems. By making this registry modification, the ransomware seeks to impede users from changing the wallpaper forcibly set by the malware, restricting the user's control over their system's visual settings. +explanation = The following analytic detects modifications to the Windows registry aimed at preventing wallpaper changes. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the "NoChangingWallPaper" registry value. This activity is significant as it is a known tactic used by Rhysida ransomware to enforce a malicious wallpaper, thereby limiting user control over system settings. If confirmed malicious, this registry change could indicate a ransomware infection, leading to further system compromise and user disruption. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13282,7 +13084,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to enable proxy. This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, facilitating connections to malicious Command and Control (C2) servers. Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially those aiming to leverage proxy configurations for unauthorized communication with malicious entities. +explanation = The following analytic detects modifications to the Windows registry key "ProxyEnable" to enable proxy settings. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the "Internet Settings\ProxyEnable" registry path. This activity is significant as it is commonly exploited by malware and adversaries to establish proxy communication, potentially connecting to malicious Command and Control (C2) servers. If confirmed malicious, this could allow attackers to redirect network traffic through a proxy, facilitating unauthorized communication and data exfiltration, thereby compromising the security of the affected host. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13292,7 +13094,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification in the Windows registry to setup proxy server. This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, facilitating connections to malicious Command and Control (C2) servers. Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially those aiming to leverage proxy configurations for unauthorized communication with malicious entities. +explanation = The following analytic detects modifications to the Windows registry key for setting up a proxy server. It leverages data from the Endpoint.Registry datamodel, focusing on changes to the "Internet Settings\\ProxyServer" registry path. This activity is significant as it can indicate malware or adversaries configuring a proxy to facilitate unauthorized communication with Command and Control (C2) servers. If confirmed malicious, this could allow attackers to establish persistent, covert channels for data exfiltration or further exploitation of the compromised host. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed. @@ -13302,7 +13104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry entry created by Qakbot malware as part of its malicious execution. This "Binary Data" Registry was created by newly spawn explorer.exe where its malicious code is injected to it. The registry consist of 8 random registry value name with encrypted binary data on its registry value data. This anomaly detections can be a good pivot for possible Qakbot malware infection or other malware that uses registry to save or store there config or malicious code on the registry data stream. +explanation = The following analytic detects the creation of a suspicious registry entry by Qakbot malware, characterized by 8 random registry value names with encrypted binary data. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry modifications under the "SOFTWARE\\Microsoft\\" path by processes like explorer.exe. This activity is significant as it indicates potential Qakbot infection, which uses the registry to store malicious code or configuration data. If confirmed malicious, this could allow attackers to maintain persistence and execute arbitrary code on the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -13312,7 +13114,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of reg.exe with "restore" parameter. This reg.exe parameter is commonly used to restore registry backup data in a targeted host. This approach or technique was also seen in post-exploitation tool like winpeas where it uses "reg save" and "reg restore" to check the registry modification restriction in targeted host after gaining access to it. +explanation = The following analytic detects the execution of reg.exe with the "restore" parameter, indicating an attempt to restore registry backup data on a host. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant as it may indicate post-exploitation actions, such as those performed by tools like winpeas, which use "reg save" and "reg restore" to manipulate registry settings. If confirmed malicious, this could allow an attacker to revert registry changes, potentially bypassing security controls and maintaining persistence. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = network administrator can use this command tool to backup registry before updates or modifying critical registries. @@ -13322,7 +13124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies modification of Windows registry using regedit.exe application with silent mode parameter. regedit.exe windows application is commonly used as GUI app to check or modify registry. This application is also has undocumented command-line parameter and one of those are silent mode parameter that performs action without stopping for confirmation with dialog box. Importing registry from .reg files need to monitor in a production environment since it can be used adversaries to import RMS registry in compromised host. +explanation = The following analytic detects the modification of the Windows registry using the regedit.exe application with the silent mode parameter. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because the silent mode allows registry changes without user confirmation, which can be exploited by adversaries to import malicious registry settings. If confirmed malicious, this could enable attackers to persist in the environment, escalate privileges, or manipulate system configurations, leading to potential system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may execute this command that may cause some false positive. Filter as needed. @@ -13332,7 +13134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify instances where three or more distinct analytics associated with Mitre ID T1112 - Modification of registry information are triggered. Such occurrences could indicate the presence of multiple malicious registry modifications on a host. Malicious actors frequently manipulate the Windows Registry to hide important configuration details within specific Registry keys. This technique allows them to obscure their activities, erase any evidence during cleanup operations, and establish continuous access and execution of malicious code. +explanation = 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. how_to_implement = 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers. @@ -13342,7 +13144,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to suppress windows defender notification. This technique was abuse by adversaries and threat actor to bypassed windows defender on the targeted host. Azorult malware is one of the malware use this technique that also disable toast notification and other windows features as part of its malicious behavior. +explanation = The following analytic detects modifications in the Windows registry to suppress Windows Defender notifications. It leverages data from the Endpoint.Registry datamodel, specifically targeting changes to the "Notification_Suppress" registry value. This activity is significant because adversaries, including those deploying Azorult malware, use this technique to bypass Windows Defender and disable critical notifications. If confirmed malicious, this behavior could allow attackers to evade detection, maintain persistence, and execute further malicious activities without alerting the user or security tools. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13352,7 +13154,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification to tamper Windows Defender protection. This technique was being abused by several adversaries, malware authors and also red-teamers to evade detection on the targeted machine. RedLine Stealer is one of the malware we've seen that uses this technique to bypass Windows defender detection. +explanation = The following analytic detects a suspicious modification to the Windows Defender Tamper Protection registry setting. It leverages data from the Endpoint datamodel, specifically targeting changes where the registry path is set to disable Tamper Protection. This activity is significant because disabling Tamper Protection can allow adversaries to make further undetected changes to Windows Defender settings, potentially leading to reduced security on the system. If confirmed malicious, this could enable attackers to evade detection, persist in the environment, and execute further malicious activities without interference from Windows Defender. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13362,7 +13164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that specifies an intranet server to host updates from Microsoft Update. +explanation = The following analytic detects a suspicious modification to the Windows Update configuration registry key, specifically targeting the UpdateServiceUrlAlternate setting. It leverages data from the Endpoint.Registry datamodel to identify changes to this registry path. This activity is significant because adversaries, including malware like RedLine Stealer, exploit this technique to bypass detection and deploy additional payloads. If confirmed malicious, this modification could allow attackers to redirect update services, potentially leading to the execution of malicious code, further system compromise, and persistent evasion of security defenses. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13372,7 +13174,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will use "The WUServer value unless this key is set". +explanation = The following analytic detects a suspicious modification to the Windows Update configuration registry key "UseWUServer." It leverages data from the Endpoint.Registry data model to identify changes where the registry value is set to "0x00000001." This activity is significant because it is commonly used by adversaries, including malware like RedLine Stealer, to bypass detection mechanisms and potentially exploit zero-day vulnerabilities. If confirmed malicious, this modification could allow attackers to evade defenses, persist on the target host, and deploy additional malicious payloads. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13382,7 +13184,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to identify potentially malicious registry modification characterized by MD5-like registry key names. This technique has been notably observed in NjRAT malware, which employs such registries for fileless storage of keylogs and .DLL plugins. Detecting this tactic serves as an effective means of identifying possible NjRAT malware instances that create or modify registries as part of their malicious activities. +explanation = The following analytic detects potentially malicious registry modifications characterized by MD5-like registry key names. It leverages the Endpoint data model to identify registry entries under the SOFTWARE path with 32-character hexadecimal names, a technique often used by NjRAT malware for fileless storage of keylogs and .DLL plugins. This activity is significant as it can indicate the presence of NjRAT or similar malware, which can lead to unauthorized data access and persistent threats within the environment. If confirmed malicious, attackers could maintain persistence and exfiltrate sensitive information. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13392,7 +13194,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification related to the WSUS server used by Automatic Updates and (by default) API callers. This policy is paired with WUStatusServer; both must be set to the same value in order for them to be valid. +explanation = The following analytic detects suspicious modifications to the Windows Update Server (WUServer) registry settings. It leverages data from the Endpoint.Registry data model to identify changes in the registry path associated with Windows Update configurations. This activity is significant because adversaries, including malware like RedLine Stealer, exploit this technique to bypass detection and deploy additional payloads. If confirmed malicious, this registry modification could allow attackers to evade defenses, potentially leading to further system compromise and persistent unauthorized access. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = Administrators may enable or disable this feature that may cause some false positive. @@ -13402,7 +13204,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification related to the server to which reporting information will be sent for client computers that use the WSUS server configured by the WUServer key. This policy is paired with WUServer; both must be set to the same value in order for them to be valid. +explanation = The following analytic identifies suspicious modifications to the Windows Update configuration registry, specifically targeting the WUStatusServer key. It leverages data from the Endpoint datamodel to detect changes in the registry path associated with Windows Update settings. This activity is significant as it is commonly used by adversaries, including malware like RedLine Stealer, to bypass detection and deploy additional payloads. If confirmed malicious, this modification could allow attackers to evade defenses, potentially leading to further system compromise and persistent unauthorized access. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -13412,7 +13214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious registry modification related to file compression color and information tips. This IOC was seen in hermetic wiper where it has a thread that will create this registry entry to change the color of compressed or encrypted files in NTFS file system as well as the pop up information tips. This is a good indicator that a process tries to modified one of the registry GlobalFolderOptions related to file compression attribution in terms of color in NTFS file system. +explanation = The following analytic detects suspicious modifications to the Windows registry keys related to file compression color and information tips. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "ShowCompColor" and "ShowInfoTip" values under the "Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced" path. This activity is significant as it was observed in the Hermetic Wiper malware, indicating potential malicious intent to alter file attributes and user interface elements. If confirmed malicious, this could signify an attempt to manipulate file visibility and deceive users, potentially aiding in further malicious activities. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13422,7 +13224,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application in public and suspicious windows process file path. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application. +explanation = The following analytic detects suspicious modifications to system firewall rules, specifically allowing execution of applications from notable and potentially malicious file paths. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving firewall rule changes. This activity is significant as it may indicate an adversary attempting to bypass firewall restrictions to execute malicious files. If confirmed malicious, this could allow attackers to execute unauthorized code, potentially leading to further system compromise, data exfiltration, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.CM"]} known_false_positives = A network operator or systems administrator may utilize an automated or manual execution of this firewall rule that may generate false positives. Filter as needed. @@ -13432,7 +13234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following anaytic identifies MOFComp.exe loading a MOF file. The Managed Object Format (MOF) compiler parses a file containing MOF statements and adds the classes and class instances defined in the file to the WMI repository. Typically, MOFComp.exe does not reach out to the public internet or load a MOF file from User Profile paths. A filter and consumer is typically registered in WMI. Review parallel processes and query WMI subscriptions to gather artifacts. The default path of mofcomp.exe is C:\Windows\System32\wbem. +explanation = The following analytic detects the execution of MOFComp.exe loading a MOF file, often triggered by cmd.exe or powershell.exe, or from unusual paths like User Profile directories. It leverages Endpoint Detection and Response (EDR) data, focusing on process names, parent processes, and command-line executions. This activity is significant as it may indicate an attacker using WMI for persistence or lateral movement. If confirmed malicious, it could allow the attacker to execute arbitrary code, maintain persistence, or escalate privileges within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.003"], "nist": ["DE.CM"]} known_false_positives = False positives may be present from automation based applications (SCCM), filtering may be required. In addition, break the query out based on volume of usage. Filter process names or file paths. @@ -13442,7 +13244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of new ASPX files in the MOVEit Transfer application's "wwwroot" directory. This activity is indicative of the recent critical vulnerability found in MOVEit Transfer, where threat actors have been observed exploiting a zero-day vulnerability to install a malicious ASPX file (e.g., "human2.aspx") in the wwwroot directory. The injected file could then be used to exfiltrate sensitive data, including user credentials and file metadata. The vulnerability affects the MOVEit Transfer managed file transfer software developed by Progress, a subsidiary of US-based Progress Software Corporation. This analytic requires endpoint data reflecting process and filesystem activity. The identified process must be responsible for the creation of new ASPX or ASHX files in the specified directory. +explanation = The following analytic detects the creation of new ASPX files in the MOVEit Transfer application's "wwwroot" directory. It leverages endpoint data on process and filesystem activity to identify processes responsible for creating these files. This activity is significant as it may indicate exploitation of a critical zero-day vulnerability in MOVEit Transfer, used by threat actors to install malicious ASPX files. If confirmed malicious, this could lead to exfiltration of sensitive data, including user credentials and file metadata, posing a severe risk to the organization's security. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. @@ -13462,7 +13264,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the usage of mshta.exe Windows binary in registry to execute malicious script. This technique was seen in kovter malware where it create several registry entry which is a encoded javascript and will be executed by another registry containing mshta and javascript activexobject to execute the encoded script using wscript.shell. This TTP is a good indication of kovter malware or other adversaries or threat actors leveraging fileless detection that survive system reboot. +explanation = The following analytic detects the execution of mshta.exe via registry entries to run malicious scripts. It leverages registry activity logs to identify entries containing "mshta," "javascript," "vbscript," or "WScript.Shell." This behavior is significant as it indicates potential fileless malware, such as Kovter, which uses encoded scripts in the registry to persist and execute without files. If confirmed malicious, this activity could allow attackers to maintain persistence, execute arbitrary code, and evade traditional file-based detection methods, posing a significant threat to system integrity and security. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.005"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13472,9 +13274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection identifies instances of the Windows utility `mshta.exe` being used to write files to world-writable directories, a technique commonly leveraged by adversaries to execute malicious scripts or payloads. Starting from 26 February 2024, APT29 has been observed distributing phishing attachments that lead to the download and execution of the ROOTSAW dropper via a compromised website. The ROOTSAW payload, utilizing obfuscated JavaScript, downloads a file named `invite.txt` to the `C:\Windows\Tasks` directory. This file is then decoded and decompressed to execute a malicious payload, often leveraging legitimate Windows binaries for malicious purposes, as seen with `SqlDumper.exe` in this campaign. \ \ -The analytic is designed to detect the initial file write operation by `mshta.exe` to directories that are typically writable by any user, such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. This behavior is indicative of an attempt to establish persistence, execute code, or both, as part of a multi-stage infection process. The detection focuses on the use of `mshta.exe` to write to these locations, which is a deviation from the utility's legitimate use cases and thus serves as a strong indicator of compromise (IoC). \ \ -The ROOTSAW campaign associated with APT29 utilizes a sophisticated obfuscation technique and leverages multiple stages of payloads, ultimately leading to the execution of the WINELOADER malware. This detection aims to catch the early stages of such attacks, enabling defenders to respond before full compromise occurs. +explanation = The following analytic identifies instances of `mshta.exe` writing files to world-writable directories. It leverages Sysmon EventCode 11 logs to detect file write operations by `mshta.exe` to directories like `C:\Windows\Tasks` and `C:\Windows\Temp`. This activity is significant as it often indicates an attempt to establish persistence or execute malicious code, deviating from the utility's legitimate use. If confirmed malicious, this behavior could lead to the execution of multi-stage payloads, potentially resulting in full system compromise and unauthorized access to sensitive information. how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The search focuses on EventCode 11 where the Image is `mshta.exe` and the TargetFilename is within world-writable directories such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. The detection is designed to catch the initial file write operation by `mshta.exe` to these locations, which is indicative of an attempt to establish persistence or execute malicious code. The analytic can be modified to include additional world-writable directories as needed. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.005"], "nist": ["DE.CM"]} known_false_positives = False positives may occur if legitimate processes are writing to world-writable directories. It is recommended to investigate the context of the file write operation to determine if it is malicious or not. Modify the search to include additional known good paths for `mshta.exe` to reduce false positives. @@ -13494,7 +13294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a msiexec.exe process with hidewindow rundll32 process commandline. One such tactic involves utilizing system processes like "msiexec," "hidewindow," and "rundll32" through command-line execution. By leveraging these legitimate processes, QakBot masks its malicious operations, hiding behind seemingly normal system activities. This clandestine approach allows the trojan to carry out unauthorized tasks discreetly, such as downloading additional payloads, executing malicious code, or establishing communication with remote servers. This obfuscation through trusted system processes enables QakBot to operate stealthily, evading detection by security mechanisms and perpetuating its harmful actions without raising suspicion. +explanation = The following analytic detects the execution of the msiexec.exe process with the /HideWindow and rundll32 command-line parameters. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line arguments. This activity is significant because it is a known tactic used by malware like QakBot to mask malicious operations under legitimate system processes. If confirmed malicious, this behavior could allow an attacker to download additional payloads, execute malicious code, or establish communication with remote servers, thereby evading detection and maintaining persistence. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007", "T1218"], "nist": ["DE.CM"]} known_false_positives = Other possible 3rd party msi software installers use this technique as part of its installation process. @@ -13524,7 +13324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the unusual behavior of MSIExec spawning WinDBG. It is designed to detect potential malicious activities. The search specifically looks for instances where the parent process name is 'msiexec.exe' and the process name is 'windbg.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. +explanation = The following analytic identifies the unusual behavior of MSIExec spawning WinDBG. It detects this activity by analyzing endpoint telemetry data, specifically looking for instances where 'msiexec.exe' is the parent process of 'windbg.exe'. This behavior is significant as it may indicate an attempt to debug or tamper with system processes, which is uncommon in typical user activity and could signify malicious intent. If confirmed malicious, this activity could allow an attacker to manipulate or inspect running processes, potentially leading to privilege escalation or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]} known_false_positives = False positives will only be present if the MSIExec process legitimately spawns WinDBG. Filter as needed. @@ -13554,7 +13354,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a dns query to a known TOR proxy website. This technique was seen in several adversaries, threat actors and malware like AgentTesla to To disguise the source of its malicious traffic. adversaries may chain together multiple proxies. This Anomaly detection might be a good pivot for a process trying to download or use TOR proxies in a compromised host machine. +explanation = The following analytic identifies DNS queries to known TOR proxy websites, such as "*.torproject.org" and "www.theonionrouter.com". It leverages Sysmon EventCode 22 to detect these queries by monitoring DNS query events from endpoints. This activity is significant because adversaries often use TOR proxies to disguise the source of their malicious traffic, making it harder to trace their actions. If confirmed malicious, this behavior could indicate an attempt to obfuscate network traffic, potentially allowing attackers to exfiltrate data or communicate with command and control servers undetected. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 22 dns query events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]} known_false_positives = third party application may use this proxies if allowed in production environment. Filter is needed. @@ -13564,7 +13364,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This Splunk detection identifies situations where over five unique Windows account passwords are changed within a 10-minute interval, captured by Event Code 4724 in the Windows Security Event Log. The query utilizes the wineventlog_security dataset, organizing data into 10-minute periods to monitor the count and distinct count of TargetUserName, the accounts with altered passwords. Rapid password changes across multiple accounts are atypical and might indicate unauthorized access or an internal actor compromising account security. Teams should calibrate the detection's threshold and timeframe to fit their specific operational context. +explanation = The following analytic detects instances where more than five unique Windows account passwords are changed within a 10-minute interval. It leverages Event Code 4724 from the Windows Security Event Log, using the wineventlog_security dataset to monitor and count distinct TargetUserName values. This behavior is significant as rapid password changes across multiple accounts are unusual and may indicate unauthorized access or internal compromise. If confirmed malicious, this activity could lead to widespread account compromise, unauthorized access to sensitive information, and potential disruption of services. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]} known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. @@ -13574,7 +13374,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic flags when more than five unique Windows accounts are deleted within a 10-minute period, identified by Event Code 4726 in the Windows Security Event Log. Using the wineventlog_security dataset, it segments data into 10-minute intervals to monitor account deletions, a pattern that could suggest malicious intent like an attacker erasing traces. Teams should adjust the detection's threshold and timeframe to suit their specific environment. +explanation = The following analytic detects the deletion of more than five unique Windows accounts within a 10-minute period, using Event Code 4726 from the Windows Security Event Log. It leverages the `wineventlog_security` dataset, segmenting data into 10-minute intervals to identify suspicious account deletions. This activity is significant as it may indicate an attacker attempting to erase traces of their actions. If confirmed malicious, this could lead to unauthorized access removal, hindering incident response and forensic investigations. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]} known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. @@ -13584,7 +13384,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This Splunk detection focuses on instances where more than five unique Windows accounts are disabled within a 10-minute window, as indicated by Event Code 4725 in the Windows Security Event Log. The query analyzes the wineventlog_security dataset, grouping data into 10-minute segments, and tracks the count and distinct count of TargetUserName, the accounts being disabled. This pattern of disabling multiple accounts rapidly is unusual and could signal internal policy breaches or an external attacker's attempt to disrupt normal operations. Teams are advised to tailor the threshold and timeframe of this detection to their environment's specifics +explanation = The following analytic identifies instances where more than five unique Windows accounts are disabled within a 10-minute window, as indicated by Event Code 4725 in the Windows Security Event Log. It leverages the wineventlog_security dataset, grouping data into 10-minute segments and tracking the count and distinct count of TargetUserName. This behavior is significant as it may indicate internal policy breaches or an external attacker's attempt to disrupt operations. If confirmed malicious, this activity could lead to widespread account lockouts, hindering user access and potentially disrupting business operations. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]} known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed. @@ -13594,9 +13394,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique disabled domain users using the Kerberos protocol within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack against disabled users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code `0x12` stands for `clients credentials have been revoked` (account disabled, expired or locked out). \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic detects a single source endpoint failing to authenticate with 30 unique disabled domain users using the Kerberos protocol within 5 minutes. It leverages Windows Security Event 4768, focusing on failure code `0x12`, indicating revoked credentials. This activity is significant as it may indicate a Password Spraying attack targeting disabled accounts, a tactic used by adversaries to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access or privilege escalation within the Active Directory environment, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple disabled domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems missconfigured systems. @@ -13606,9 +13404,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique invalid domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` (the attempted user is not a valid domain user). \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate with 30 unique invalid domain users using the Kerberos protocol. This detection leverages EventCode 4768, specifically looking for failure code 0x6, indicating the user is not found in the Kerberos database. This activity is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access or privilege escalation within the Active Directory environment, posing a significant security risk. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems and missconfigured systems. @@ -13618,9 +13414,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique invalid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC0000064 stands for `The username you typed does not exist` (the attempted user is a legitimate domain user). \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts. +explanation = The following analytic detects a single source endpoint failing to authenticate with 30 unique invalid users using the NTLM protocol. It leverages EventCode 4776 from Domain Controller logs, focusing on error code 0xC0000064, which indicates non-existent usernames. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information within the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts. @@ -13630,9 +13424,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source user failing to authenticate with 30 unique users using explicit credentials on a host. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4648 is generated when a process attempts an account logon by explicitly specifying that accounts credentials. This event generates on domain controllers, member servers, and workstations. \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source account, attempted user accounts and the endpoint were the behavior was identified. +explanation = The following analytic identifies a source user failing to authenticate with 30 unique users using explicit credentials on a host. It leverages Windows Event 4648, which is generated when a process attempts an account logon by explicitly specifying account credentials. This detection is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges within an Active Directory environment. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A source user failing attempting to authenticate multiple users on a host is not a common behavior for regular systems. Some applications, however, may exhibit this behavior in which case sets of users hosts can be added to an allow list. Possible false positive scenarios include systems where several users connect to like Mail servers, identity providers, remote desktop services, Citrix, etc. @@ -13642,9 +13434,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique valid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted user is a legitimate domain user). \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts. +explanation = The following analytic identifies a single source endpoint failing to authenticate with 30 unique valid users using the NTLM protocol. It leverages EventCode 4776 from Domain Controller logs, focusing on error code 0xC000006A, which indicates a bad password. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access to sensitive information or further compromise of the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts. @@ -13654,9 +13444,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source process name failing to authenticate with 30 uniquer users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4625 generates on domain controllers, member servers, and workstations when an account fails to logon. Logon Type 2 describes an iteractive logon attempt. \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. This could be a domain controller as well as a member server or workstation. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts. +explanation = The following analytic detects a source process failing to authenticate with 30 unique users, indicating a potential Password Spraying attack. It leverages Windows Event 4625 with Logon Type 2, collected from domain controllers, member servers, and workstations. This activity is significant as it may represent an adversary attempting to gain initial access or elevate privileges within an Active Directory environment. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or further compromise of the network, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A process failing to authenticate with multiple users is not a common behavior for legitimate user sessions. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. @@ -13666,9 +13454,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4771 is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted user is a legitimate domain user). \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic identifies a single source endpoint failing to authenticate with 30 unique users using the Kerberos protocol. It leverages EventCode 4771 with Status 0x18, indicating wrong password attempts, and aggregates these events over a 5-minute window. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges in an Active Directory environment. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, missconfigured systems and multi-user systems like Citrix farms. @@ -13678,9 +13464,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source host failing to authenticate against a remote host with 30 unique users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4625 documents each and every failed attempt to logon to the local computer. This event generates on domain controllers, member servers, and workstations. Logon Type 3 describes an remote authentication attempt. \ -This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the host that is the target of the password spraying attack. This could be a domain controller as well as a member server or workstation. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts. +explanation = The following analytic identifies a source host failing to authenticate against a remote host with 30 unique users. It leverages Windows Event 4625 with Logon Type 3, indicating remote authentication attempts. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges in an Active Directory environment. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. This detection is crucial for real-time security monitoring and threat hunting. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]} known_false_positives = A host failing to authenticate with multiple valid users against a remote host is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, missconfigyred systems, etc. @@ -13690,7 +13474,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect the addition of new InProcServer32 registry keys, which could indicate suspicious or malicious activity on a Windows endpoint. The InProcServer32 registry key specifies the path to a COM object that can be loaded into the process space of calling processes. Malware often abuses this mechanism to achieve persistence or execute code by registering a new InProcServer32 key pointing to a malicious DLL. By monitoring for the creation of new InProcServer32 keys, this analytic helps identify potential threats that leverage COM hijacking or similar techniques for execution and persistence. Understanding the normal behavior of legitimate software in your environment will aid in distinguishing between benign and malicious use of InProcServer32 modifications. +explanation = The following analytic detects the addition of new InProcServer32 registry keys on Windows endpoints. It leverages data from the Endpoint.Registry datamodel to identify changes in registry paths associated with InProcServer32. This activity is significant because malware often uses this mechanism to achieve persistence or execute malicious code by registering a new InProcServer32 key pointing to a harmful DLL. If confirmed malicious, this could allow an attacker to persist in the environment or execute arbitrary code, posing a significant threat to system integrity and security. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]} known_false_positives = False positives are expected. Filtering will be needed to properly reduce legitimate applications from the results. @@ -13700,7 +13484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of ngrok.exe being utilized on the Windows operating system. Unfortunately, there is no original file name for Ngrok, so it may be worth an additional hunt to identify any command-line arguments. The sign of someone using Ngrok is not malicious, however, more recently it has become an adversary tool. +explanation = The following analytic detects the execution of ngrok.exe on a Windows operating system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because while ngrok is a legitimate tool for creating secure tunnels, it is increasingly used by adversaries to bypass network defenses and establish reverse proxies. If confirmed malicious, this could allow attackers to exfiltrate data, maintain persistence, or facilitate further attacks by tunneling traffic through the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on organizations that allow the use of Ngrok. Filter or monitor as needed. @@ -13710,7 +13494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of AdvancedRun.exe. AdvancedRun.exe has similar capabilities as other remote programs like psexec. AdvancedRun may also ingest a configuration file with all settings defined and perform its activity. The analytic is written in a way to identify a renamed binary and also the common command-line arguments. +explanation = The following analytic detects the execution of AdvancedRun.exe, a tool with capabilities similar to remote administration programs like PsExec. It identifies the process by its name or original file name and flags common command-line arguments. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. Monitoring this activity is crucial as AdvancedRun can be used for remote code execution and configuration-based automation. If malicious, this could allow attackers to execute arbitrary commands, escalate privileges, or maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1588.002"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as it is specific to AdvancedRun. Filter as needed based on legitimate usage. @@ -13730,7 +13514,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious registry modification associated with NjRat, a telltale sign of its fileless technique. NjRat employs this method to manage its keylogs and execute downloaded DLL module plugins discreetly on the compromised host. This approach is particularly effective at evading conventional file-based detection systems, as it stores indicators of compromise (IOCs) in the registry. Leveraging this TTP (Tactics, Techniques, and Procedures) detection can significantly enhance the identification of NjRAT infections. +explanation = The following analytic detects suspicious registry modifications indicative of NjRat's fileless storage technique. It leverages the Endpoint.Registry data model to identify specific registry paths and values commonly used by NjRat for keylogging and executing DLL plugins. This activity is significant as it helps evade traditional file-based detection systems, making it crucial for SOC analysts to monitor. If confirmed malicious, this behavior could allow attackers to persist on the host, execute arbitrary code, and capture sensitive keystrokes, leading to potential data breaches and further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.011", "T1027"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13740,7 +13524,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects suspicious file access within the Discord LevelDB database. This database contains critical data such as user profiles, messages, guilds, channels, settings, and cached information. Access to this data poses a risk of Discord credential theft or unauthorized access to sensitive information on the compromised system. Detecting such anomalies can serve as an effective pivot to identify non-Discord applications accessing this database, potentially indicating the presence of malware or trojan stealers aimed at data theft. +explanation = The following analytic detects non-Discord applications accessing the Discord LevelDB database. It leverages Windows Security Event logs, specifically event code 4663, to identify file access attempts to the LevelDB directory by processes other than Discord. This activity is significant as it may indicate attempts to steal Discord credentials or access sensitive user data. If confirmed malicious, this could lead to unauthorized access to user profiles, messages, and other critical information, potentially compromising the security and privacy of the affected users. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -13750,7 +13534,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies non SYSTEM accounts requesting access to lsass.exe. This behavior may be related to credential dumping or applications requiring access to credentials. Triaging this event will require understanding the GrantedAccess from the SourceImage. In addition, whether the account is privileged or not. Review the process requesting permissions and review parallel processes. +explanation = The following analytic identifies non-SYSTEM accounts requesting access to lsass.exe. This detection leverages Sysmon EventCode 10 logs to monitor access attempts to the Local Security Authority Subsystem Service (lsass.exe) by non-SYSTEM users. This activity is significant as it may indicate credential dumping attempts or unauthorized access to sensitive credentials. If confirmed malicious, an attacker could potentially extract credentials from memory, leading to privilege escalation or lateral movement within the network. Immediate investigation is required to determine the legitimacy of the access request and to mitigate any potential threats. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = False positives will occur based on legitimate application requests, filter based on source image as needed. @@ -13770,7 +13554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies odbcconf.exe, Windows Open Database Connectivity utility, utilizing the action function of regsvr to load a DLL. An example will look like - odbcconf.exe /A { REGSVR T1218-2.dll }. During triage, review parent process, parallel procesess and file modifications. +explanation = The following analytic detects the execution of odbcconf.exe with the regsvr action to load a DLL. This is identified by monitoring command-line arguments in process creation logs from Endpoint Detection and Response (EDR) agents. This activity is significant as it may indicate an attempt to execute arbitrary code via DLL loading, a common technique used in various attack vectors. If confirmed malicious, this could allow an attacker to execute code with the privileges of the odbcconf.exe process, potentially leading to system compromise or further lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.008"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering may need to occur based on legitimate application usage. Filter as needed. @@ -13780,7 +13564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the odbcconf.exe, Windows Open Database Connectivity utility, loading up a resource file. The file extension is arbitrary and may be named anything. The resource file itself may have different commands supported by Odbcconf to load up a DLL (REGSVR) on disk or additional commands. During triage, review file modifications and parallel processes. +explanation = The following analytic detects the execution of odbcconf.exe with a response file, which may contain commands to load a DLL (REGSVR) or other instructions. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it may indicate an attempt to execute arbitrary code or load malicious DLLs, potentially leading to unauthorized actions. If confirmed malicious, this could allow an attacker to gain code execution, escalate privileges, or establish persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.008"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and filtering may need to occur based on legitimate application usage. Filter as needed. @@ -13790,7 +13574,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a Microsoft Office product spawning the Windows msdt.exe process. MSDT is a Diagnostics Troubleshooting Wizard native to Windows. This behavior is related to a recently identified sample utilizing protocol handlers to evade preventative controls, including if macros are disabled in the document. During triage, review file modifications for html. In addition, parallel processes including PowerShell and CertUtil. +explanation = The following analytic detects a Microsoft Office product spawning the Windows msdt.exe process. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where Office applications are the parent process. This activity is significant as it may indicate an attempt to exploit protocol handlers to bypass security controls, even if macros are disabled. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however filter as needed. @@ -13800,7 +13584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect instances where the PaperCut NG application (pc-app.exe) spawns a Windows shell, specifically cmd.exe or PowerShell. This behavior may indicate potential malicious activity, such as an attacker attempting to gain unauthorized access or execute harmful commands on the affected system. +explanation = The following analytic detects instances where the PaperCut NG application (pc-app.exe) spawns a Windows shell, such as cmd.exe or PowerShell. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is pc-app.exe. This activity is significant as it may indicate an attacker attempting to gain unauthorized access or execute malicious commands on the system. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, or further compromise of the affected environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1059", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, but most likely not. Filter as needed. @@ -13810,7 +13594,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious explorer.exe process that has "/root" process commandline. The presence of this parameter is considered a significant indicator as it could indicate attempts at spoofing the parent process by a specific program or malware. By spoofing the parent process, the malicious entity aims to circumvent detection mechanisms and operate undetected within the system. This technique of manipulating the command-line parameter (/root) of explorer.exe is a form of masquerading utilized by certain malware or suspicious processes. The objective is to obscure the true nature of the activity by imitating a legitimate system process. By doing so, it attempts to evade scrutiny and evade detection by security measures. +explanation = The following analytic identifies a suspicious `explorer.exe` process with the `/root` command-line parameter. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process and command-line data. The presence of `/root` in `explorer.exe` is significant as it may indicate parent process spoofing, a technique used by malware to evade detection. If confirmed malicious, this activity could allow an attacker to operate undetected, potentially leading to unauthorized access, privilege escalation, or persistent threats within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.004", "T1134"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13820,7 +13604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line that retrieves information related to password manager software. This technique was seen in several post exploitation tools like winpeas that are being used by Ransomware Prestige to gather this type of information. Password Managers applications are designed to store user credentials, normally in an encrypted database. Credentials are typically accessible after a user provides a master password that unlocks the database. After the database is unlocked, these credentials may be copied to memory. These databases can be stored as files on disk. Due to this password manager software designed adversaries may find or look for keywords related to the Password Manager databases that can be stolen or extracted for further attacks. +explanation = The following analytic identifies command-line activity that searches for files related to password manager software, such as "*.kdbx*" and "*credential*". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant because attackers often target password manager databases to extract stored credentials, which can be used for further exploitation. If confirmed malicious, this behavior could lead to unauthorized access to sensitive information, enabling attackers to escalate privileges, move laterally, or exfiltrate critical data. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555.005"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -13830,7 +13614,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious outlook.exe process dropped a dll file. This technique was seen in CVE-2024-21378, involves the loading of a custom MAPI form to execute a potentially malicious DLL. Detecting such TTPs serves as a crucial pivot point to identify potential adversaries, malware, or red team activity attempting to leverage this method within phishing campaigns. +explanation = The following analytic detects the creation of a DLL file by an outlook.exe process in the AppData\Local\Microsoft\FORMS directory. This detection leverages data from the Endpoint.Processes and Endpoint.Filesystem datamodels, focusing on process and file creation events. This activity is significant as it may indicate an attempt to exploit CVE-2024-21378, where a custom MAPI form loads a potentially malicious DLL. If confirmed malicious, this could allow an attacker to execute arbitrary code, leading to further system compromise or data exfiltration. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -13840,7 +13624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious pdf viewer processes that have a browser application child processes. This event was seen in a pdf spear phishing attachment containing a malicious URL link to download the actual payload. When a user clicks the malicious link the pdf viewer application will execute a process of the host default browser to connect to the malicious site. This anomaly detection can be a good indicator that a possible pdf file has a link executed by a user. The pdf viewer and browser list in this detection is still in progress, add the common browser and pdf viewer you use in opening pdf in your network. +explanation = The following analytic detects suspicious PDF viewer processes spawning browser application child processes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process names. This activity is significant as it may indicate a PDF spear-phishing attempt where a malicious URL link is executed, leading to potential payload download. If confirmed malicious, this could allow attackers to execute code, escalate privileges, or persist in the environment by exploiting the user's browser to connect to a malicious site. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = False positives in PDF file opened PDF Viewer having legitimate URL link, however filter as needed. @@ -13850,7 +13634,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies registry artifacts when an ISO container is opened, clicked or mounted on the Windows operating system. As Microsoft makes changes to macro based document execution, adversaries have begun to utilize container based initial access based phishing campaigns to evade preventative controls. Once the ISO is clicked or mounted it will create a registry artifact related to this event as a recent application executed or opened. +explanation = The following analytic detects the creation of registry artifacts when an ISO container is opened, clicked, or mounted on a Windows operating system. It leverages data from the Endpoint.Registry data model, specifically monitoring registry keys related to recent ISO or IMG file executions. This activity is significant as adversaries increasingly use container-based phishing campaigns to bypass macro-based document execution controls. If confirmed malicious, this behavior could indicate an initial access attempt, potentially leading to further exploitation, persistence, or data exfiltration within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = False positives may be high depending on the environment and consistent use of ISOs. Restrict to servers, or filter out based on commonly used ISO names. Filter as needed. @@ -13860,12 +13644,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is an enhanced version of two previous analytics that identifies common GrantedAccess permission requests and CallTrace DLLs in order to detect credential dumping. \ -GrantedAccess is the requested permissions by the SourceImage into the TargetImage. \ - \ -CallTrace Stack trace of where open process is called. Included is the DLL and the relative virtual address of the functions in the call stack right before the open process call. \ -dbgcore.dll or dbghelp.dll are two core Windows debug DLLs that have minidump functions which provide a way for applications to produce crashdump files that contain a useful subset of the entire process context. \ -The idea behind using ntdll.dll is to blend in by using native api of ntdll.dll. For example in sekurlsa module there are many ntdll exported api, like RtlCopyMemory, used to execute this module which is related to lsass dumping. +explanation = The following analytic detects potential credential dumping by identifying specific GrantedAccess permission requests and CallTrace DLLs targeting the LSASS process. It leverages Sysmon EventCode 10 logs, focusing on access requests to lsass.exe and call traces involving debug and native API DLLs like dbgcore.dll, dbghelp.dll, and ntdll.dll. This activity is significant as credential dumping can lead to unauthorized access to sensitive credentials. If confirmed malicious, attackers could gain elevated privileges and persist within the environment, posing a severe security risk. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} known_false_positives = False positives will occur based on GrantedAccess 0x1010 and 0x1400, filter based on source image as needed or remove them. Concern is Cobalt Strike usage of Mimikatz will generate 0x1010 initially, but later be caught. @@ -13875,7 +13654,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following correlation identifies a four or more number of distinct analytics associated with the Windows Post-Exploitation analytic story, which enables the identification of potentially suspicious behavior. Windows Post-Exploitation refers to the phase that occurs after an attacker successfully compromises a Windows system. During this stage, attackers strive to maintain persistence, gather sensitive information, escalate privileges, and exploit the compromised environment further. Timely detection of post-exploitation activities is crucial for prompt response and effective mitigation. Common post-exploitation detections encompass identifying suspicious processes or services running on the system, detecting unusual network connections or traffic patterns, identifying modifications to system files or registry entries, monitoring abnormal user account activities, and flagging unauthorized privilege escalations. Ensuring the detection of post-exploitation activities is essential to proactively prevent further compromise, minimize damage, and restore the security of the Windows environment. +explanation = The following analytic identifies four or more distinct post-exploitation behaviors on a Windows system. It leverages data from the Risk data model in Splunk Enterprise Security, focusing on multiple risk events and their associated MITRE ATT&CK tactics and techniques. This activity is significant as it indicates potential malicious actions following an initial compromise, such as persistence, privilege escalation, or data exfiltration. If confirmed malicious, this behavior could allow attackers to maintain control, escalate privileges, and further exploit the compromised environment, leading to significant security breaches and data loss. how_to_implement = 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. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012", "T1049", "T1069", "T1016", "T1003", "T1082", "T1115", "T1552"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers. @@ -13885,7 +13664,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following PowerShell Script Block analytic identifies the native ability to add a DLL to the Windows Global Assembly Cache. Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer. By adding a DLL to the GAC, this allows an adversary to call it via any other means across the operating systems. This is native and built into Windows. Per the Microsoft blog, the more high fidelity method may be to look for W3WP.exe spawning PowerShell that includes the same CommandLine as identified in this analytic. +explanation = The following analytic detects the addition of a DLL to the Windows Global Assembly Cache (GAC) using PowerShell. It leverages PowerShell Script Block Logging to identify commands containing "system.enterpriseservices.internal.publish". This activity is significant because adding a DLL to the GAC allows it to be shared across multiple applications, potentially enabling an adversary to execute malicious code system-wide. If confirmed malicious, this could lead to widespread code execution, privilege escalation, and persistent access across the operating system, posing a severe security risk. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on developers or third party utilities adding items to the GAC. @@ -13895,7 +13674,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is processing cryptography namespace library. This technique was seen in several powershell malware, loader, downloader and stager that will decrypt or decode the next malicious stager or the actual payload. This Anomaly detection can be a good indicator that a powershell process to decrypt code. We recommend to further check the parent_process_name, the file or data it tries to decrypt, network connection and user who execute the script. +explanation = The following analytic detects suspicious PowerShell script execution involving the cryptography namespace via EventCode 4104. It leverages PowerShell Script Block Logging to identify scripts using cryptographic functions, excluding common hashes like SHA and MD5. This activity is significant as it is often associated with malware that decrypts or decodes additional malicious payloads. If confirmed malicious, this could allow an attacker to execute further code, escalate privileges, or establish persistence within the environment. Analysts should investigate the parent process, decrypted data, network connections, and the user executing the script. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited. Filter as needed. @@ -13935,7 +13714,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the use of Get-CimInstance cmdlet with the -ComputerName parameter, which indicates that the cmdlet is being used to retrieve information from a remote computer. This can be useful for detecting instances of remote access, such as when an attacker uses PowerShell to connect to a remote system and gather information. By monitoring for this cmdlet with the -ComputerName parameter, security analysts can identify potential malicious activity on remote systems and take appropriate action to mitigate any threats. +explanation = The following analytic detects the use of the Get-CimInstance cmdlet with the -ComputerName parameter, indicating an attempt to retrieve information from a remote computer. It leverages PowerShell Script Block Logging to identify this specific command execution. This activity is significant as it may indicate unauthorized remote access or information gathering by an attacker. If confirmed malicious, this could allow the attacker to collect sensitive data from remote systems, potentially leading to further exploitation or lateral movement within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001"], "nist": ["DE.AE"]} known_false_positives = This is meant to be a low risk RBA anomaly analytic or to be used for hunting. Enable this with a low risk score and let it generate risk in the risk index. @@ -13945,7 +13724,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the usage of PowerShell Cmdlets - New-WebGlobalModule, Enable-WebGlobalModule and Set-WebGlobalModule being utilized to create (new), enable (start) or modify a current IIS Module. These commands are equivalent to AppCmd.exe parameters. Adversaries may utilize these cmdlets as they are lesser known and perform the same activity as AppCmd. +explanation = The following analytic detects the usage of PowerShell Cmdlets - New-WebGlobalModule, Enable-WebGlobalModule, and Set-WebGlobalModule, which are used to create, enable, or modify IIS Modules. This detection leverages PowerShell Script Block Logging, specifically monitoring EventCode 4104 for these cmdlets. This activity is significant as adversaries may use these lesser-known cmdlets to manipulate IIS configurations, similar to AppCmd.exe, potentially bypassing traditional defenses. If confirmed malicious, this could allow attackers to persist in the environment, manipulate web server behavior, or escalate privileges. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]} known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required. @@ -13955,7 +13734,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify the imports of Windows PowerShell Applocker commandlets. This technique was seen in Azorult malware where it drops an xml Applocker policy that will deny several AV product and then loaded using PowerShell Applocker commandlet. +explanation = The following analytic detects the import of Windows PowerShell Applocker cmdlets, specifically identifying the use of "Import-Module Applocker" and "Set-AppLockerPolicy" with an XML policy. It leverages PowerShell Script Block Logging (EventCode 4104) to capture and analyze script block text. This activity is significant as it may indicate an attempt to enforce restrictive Applocker policies, potentially used by malware like Azorult to disable antivirus products. If confirmed malicious, this could allow an attacker to bypass security controls, leading to further system compromise and persistence. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059.001", "T1059", "T1562.001", "T1562"], "nist": ["DE.CM"]} known_false_positives = administrators may execute this command that may cause some false positive. @@ -13965,7 +13744,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the use of "remotesigned" execution policy for a file. This security setting determines whether PowerShell scripts can be executed on a computer. When the execution policy is set to "remotesigned," it allows locally created scripts to run without any restrictions, but scripts downloaded from the internet must have a digital signature from a trusted publisher. +explanation = The following analytic identifies the use of the "remotesigned" execution policy for PowerShell scripts. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing "remotesigned" and "-File". This activity is significant because the "remotesigned" policy allows locally created scripts to run without restrictions, posing a potential security risk. If confirmed malicious, an attacker could execute unauthorized scripts, leading to code execution, privilege escalation, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]} known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required. @@ -13975,7 +13754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects potential malicious activities related to PowerShell's task scheduling cmdlets. It looks for anomalies in PowerShell logs, specifically EventCode 4104, associated with script block logging. The analytic flags unusual or suspicious use patterns of key task-related cmdlets such as 'New-ScheduledTask', 'Set-ScheduledTask', and others, which are often used by attackers for persistence and remote execution of malicious code. If a true positive is found, it suggests an possible attacker is attempting to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, PowerShell Script Block Logging needs to be enabled on some or all endpoints. Analysts should be aware of benign administrative tasks that can trigger alerts and tune the analytic accordingly to reduce false positives. Upon triage, review the PowerShell logs for any unusual or unexpected cmdlet usage, IP addresses, user accounts, or timestamps. If these factors align with known malicious behavior patterns, immediate mitigation steps, such as isolation of the affected systems, user account changes, and relevant threat hunting activities, should be initiated. This proactive analysis significantly enhances an organization's capacity to swiftly respond to, and potentially prevent, the execution of advanced persistent threats in their network. +explanation = The following analytic detects potential malicious activities involving PowerShell's task scheduling cmdlets. It leverages PowerShell Script Block Logging (EventCode 4104) to identify unusual or suspicious use of cmdlets like 'New-ScheduledTask' and 'Set-ScheduledTask'. This activity is significant as attackers often use these cmdlets for persistence and remote execution of malicious code. If confirmed malicious, this could allow attackers to maintain access, deliver additional payloads, or execute ransomware, leading to data theft or other severe impacts. Immediate investigation and mitigation are crucial to prevent further compromise. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1059.001", "T1059"], "nist": ["DE.AE"]} known_false_positives = Benign administrative tasks can also trigger alerts, necessitating a firm understanding of the typical system behavior and precise tuning of the analytic to reduce false positives. @@ -13985,7 +13764,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the use of the PowerShell script block logging mechanism to detect the use of the Win32_ScheduledJob WMI class. This class allows the creation and management of scheduled tasks on Windows systems. However, due to security concerns, the class has been disabled by default in Windows systems, and its use must be explicitly enabled by modifying the registry. As a result, the detection of the use of this class may indicate malicious activity, especially if the class was enabled on the system by the attacker. Therefore, it is recommended to monitor the use of Win32_ScheduledJob through PowerShell script block logging and to investigate any suspicious activity. +explanation = The following analytic detects the use of the Win32_ScheduledJob WMI class via PowerShell script block logging. This class, which manages scheduled tasks, is disabled by default due to security concerns and must be explicitly enabled through registry modifications. The detection leverages PowerShell event code 4104 and script block text analysis. Monitoring this activity is crucial as it may indicate malicious intent, especially if the class was enabled by an attacker. If confirmed malicious, this could allow attackers to persist in the environment by creating scheduled tasks. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on legacy applications or utilities. Win32_ScheduledJob uses the Remote Procedure Call (RPC) protocol to create scheduled tasks on remote computers. It uses the DCOM (Distributed Component Object Model) infrastructure to establish a connection with the remote computer and invoke the necessary methods. The RPC service needs to be running on both the local and remote computers for the communication to take place. @@ -13995,7 +13774,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of the Get-GPPPassword PowerShell commandlet employed to search for unsecured credentials Group Policy Preferences (GPP). GPP are tools that allow administrators to create domain policies with embedded credentials. These policies allow administrators to set local accounts. These group policies are stored in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL share and decrypt the password (using the AES key that has been made public). While Microsoft released a patch that impedes Administrators to create unsecure credentials, existing Group Policy Preferences files with passwords are not removed from SYSVOL. +explanation = The following analytic detects the execution of the Get-GPPPassword PowerShell cmdlet, which is used to search for unsecured credentials in Group Policy Preferences (GPP). This detection leverages PowerShell Script Block Logging to identify specific script block text associated with this cmdlet. Monitoring this activity is crucial as it can indicate an attempt to retrieve and decrypt stored credentials from SYSVOL, potentially leading to unauthorized access. If confirmed malicious, this activity could allow an attacker to escalate privileges or move laterally within the network by exploiting exposed credentials. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552", "T1552.006"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -14005,7 +13784,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets `Get-ObjectAcl` or `Get-DomainObjectAcl`. This commandlets are used to enumerate Access Control List permissions given to Active Directory objects. In an active directory environment, an object is an entity that represents an available resource within the organizations network, such as domain controllers, users, groups, computers, shares, etc. Maintaining Active Directory permissions is complicated and hard to manage, especially in complex and large environments with multiple domains. Weak permissions may allow adversaries and red teamers to escalate their privileges in Active Directory. PowerView is a common tool leveraged by attackers to identify and exploit configuration weaknesses. +explanation = The following analytic detects the execution of PowerView PowerShell cmdlets `Get-ObjectAcl` or `Get-DomainObjectAcl`, which are used to enumerate Access Control List (ACL) permissions for Active Directory objects. It leverages Event ID 4104 from PowerShell Script Block Logging to identify this activity. This behavior is significant as it may indicate an attempt to discover weak permissions in Active Directory, potentially leading to privilege escalation. If confirmed malicious, attackers could exploit these permissions to gain unauthorized access or escalate their privileges within the network. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.= annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed. @@ -14015,7 +13794,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify commandlets used by the PowerView hacking tool leveraged to discover Windows endpoints with Kerberos Constrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of PowerView commandlets to discover Windows endpoints with Kerberos Constrained Delegation. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific commandlets like `Get-DomainComputer` or `Get-NetComputer` with the `-TrustedToAuth` parameter. This activity is significant as it indicates potential reconnaissance efforts by adversaries or Red Teams to map out privileged delegation settings in Active Directory. If confirmed malicious, this could allow attackers to identify high-value targets for further exploitation, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting. @@ -14025,7 +13804,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainSPNTicket` commandlets with specific parameters. This commandlet is a part of PowerView, a PowerShell tool used to perform enumeration and discovery on Windows Active Directory networks. As the name suggests, this commandlet is used to request the kerberos ticket for a specified service principal name (SPN). Once the ticket is received, it may be cracked using password cracking tools like hashcat to extract the password of the SPN account. Red Teams and adversaries alike may leverage PowerView and these commandlets to identify accounts that can be attacked with the Kerberoasting technique. +explanation = The following analytic detects the execution of the `Get-DomainSPNTicket` commandlet, part of the PowerView tool, by leveraging PowerShell Script Block Logging (EventCode=4104). This commandlet requests Kerberos service tickets for specified service principal names (SPNs). Monitoring this activity is crucial as it can indicate attempts to perform Kerberoasting, a technique used to extract SPN account passwords via cracking tools like hashcat. If confirmed malicious, this activity could allow attackers to gain unauthorized access to sensitive accounts, potentially leading to privilege escalation and further network compromise. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]} known_false_positives = False positive may include Administrators using PowerView for troubleshooting and management. @@ -14035,7 +13814,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` or `Get-NetUSer` commandlets with specific parameters. These commandlets are part of PowerView, a PowerShell tool used to perform enumeration and discovery on Windows Active Directory networks. As the names suggest, these commandlets are used to identify domain users in a network and combining them with the `-SPN` parameter allows adversaries to discover domain accounts associated with a Service Principal Name (SPN). Red Teams and adversaries alike may leverage PowerView and these commandlets to identify accounts that can be attacked with the Kerberoasting technique. +explanation = The following analytic detects the execution of the `Get-DomainUser` or `Get-NetUser` PowerShell cmdlets with the `-SPN` parameter, indicating the use of PowerView for SPN discovery. It leverages PowerShell Script Block Logging (EventCode=4104) to identify these specific commands. This activity is significant as it suggests an attempt to enumerate domain accounts associated with Service Principal Names (SPNs), a common precursor to Kerberoasting attacks. If confirmed malicious, this could allow an attacker to identify and target accounts for credential theft, potentially leading to unauthorized access and privilege escalation within the network. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]} known_false_positives = False positive may include Administrators using PowerView for troubleshooting and management. @@ -14045,7 +13824,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify commandlets used by the PowerView hacking tool leveraged to discover Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of PowerView commandlets to discover Windows endpoints with Kerberos Unconstrained Delegation. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific commands like `Get-DomainComputer` or `Get-NetComputer` with the `-Unconstrained` parameter. This activity is significant as it indicates potential reconnaissance efforts by adversaries or Red Teams to map out privileged delegation settings in Active Directory. If confirmed malicious, this could allow attackers to identify high-value targets for further exploitation, potentially leading to privilege escalation or lateral movement within the network. how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting. @@ -14055,7 +13834,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line that retrieves information related to private keys files. This technique was seen in several post exploitation tools like winpeas that are being used by Ransomware Prestige to search for private key certificates on the compromised host for insecurely stored credentials. This files can be used by adversaries to gain privileges, persistence or remote service authentication to collect more sensitive information. Some private keys required password for operation, so in this case adversaries may need to have that passphrase either via keylogging or brute force attack. +explanation = The following analytic identifies processes that retrieve information related to private key files, often used by post-exploitation tools like winpeas. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions that search for private key certificates. This activity is significant as it indicates potential attempts to locate insecurely stored credentials, which adversaries can exploit for privilege escalation, persistence, or remote service authentication. If confirmed malicious, this behavior could allow attackers to access sensitive information, escalate privileges, or maintain persistence within the compromised environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -14065,7 +13844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when any low->high integrity level process running from a user account spawns an elevated (high/system integrity) process in a suspicious location or with system level process integrity. This behavior may indicate when a threat actor has successfully elevated privileges. +explanation = The following analytic detects when a process running with low or medium integrity from a user account spawns an elevated process with high or system integrity in suspicious locations. This behavior is identified using process execution data from Windows process monitoring or Sysmon Event ID 1. This activity is significant as it may indicate a threat actor successfully elevating privileges, which is a common tactic in advanced attacks. If confirmed malicious, this could allow the attacker to execute code with higher privileges, potentially leading to full system compromise and persistent access. how_to_implement = Target environment must ingest process execution data sources such as Windows process monitoring and/or Sysmon EID 1. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated by administrators installing benign applications using run-as/elevation. @@ -14075,7 +13854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects any system integrity level process that was spawned by a process not running as a system account. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service. +explanation = The following analytic detects any system integrity level process spawned by a non-system account. It leverages Sysmon Event ID 1, focusing on process integrity and parent user data. This behavior is significant as it often indicates successful privilege escalation to SYSTEM from a user-controlled process or service. If confirmed malicious, this activity could allow an attacker to gain full control over the system, execute arbitrary code, and potentially compromise the entire environment. how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity and parent user data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -14085,7 +13864,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when any process low->high integrity level process spawns a system integrity process from a user controlled location. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service. +explanation = The following analytic detects when a process with low, medium, or high integrity spawns a system integrity process from a user-controlled location. This behavior is indicative of privilege escalation attempts where attackers elevate their privileges to SYSTEM level from a user-controlled process or service. The detection leverages Sysmon data, specifically Event ID 15, to identify such transitions. Monitoring this activity is crucial as it can signify an attacker gaining SYSTEM-level access, potentially leading to full control over the affected system, unauthorized access to sensitive data, and further malicious activities. how_to_implement = Target environment must ingest sysmon data, specifically Event ID 15. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]} known_false_positives = Unknown @@ -14095,7 +13874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects Windows Management Instrumentation Command-line (WMIC) command used to retrieve information about running processes and specifically fetches the command lines used to launch those processes. This Hunting detection can be a good indicator for possible suspicious user or process getting list of process with its command line using wmic application which is not a common practice for a non-technical user. +explanation = The following analytic detects the use of Windows Management Instrumentation Command-line (WMIC) to retrieve information about running processes, specifically targeting the command lines used to launch those processes. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on logs containing process details and command-line executions. This activity is significant as it may indicate suspicious behavior, such as a user or process gathering detailed process information, which is uncommon for non-technical users. If confirmed malicious, this could allow an attacker to gain insights into running processes, aiding in further exploitation or lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1057"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. Filter as needed. @@ -14105,7 +13884,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a non-service searchindexer.exe process. QakBot, a notorious banking trojan and information stealer, often deploys a process named "searchindexer.exe" as part of its malicious activities. This legitimate Windows process, "Search Indexer," is manipulated by QakBot to masquerade and evade detection within the system. The malware uses this deceptive tactic to camouflage its presence, remaining inconspicuous while performing unauthorized actions like data exfiltration, keystroke logging, and communication with command and control servers. By adopting the guise of a genuine system process, the malicious "searchindexer.exe" process helps QakBot evade scrutiny and continue its malevolent operations without arousing suspicion. +explanation = The following analytic identifies instances of the searchindexer.exe process that are not spawned by services.exe, indicating potential process injection. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes. This activity is significant because QakBot malware often uses a fake searchindexer.exe to evade detection and perform malicious actions such as data exfiltration and keystroke logging. If confirmed malicious, this activity could allow attackers to maintain persistence, steal sensitive information, and communicate with command and control servers. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14115,7 +13894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes Sysmon to identify process injection into Notepad.exe, based on GrantedAccess requests - 0x40 and 0x1fffff. This particular behavior is attributed to the defaults of the SliverC2 framework by BishopFox. By default, the analytic filters out any SourceImage paths of System32, Syswow64 and program files. Add more as needed, or remove and monitor what is consistently injecting into notepad.exe. This particular behavior will occur from a source image that is the initial payload dropped. +explanation = The following analytic detects process injection into Notepad.exe using Sysmon EventCode 10. It identifies suspicious GrantedAccess requests (0x40 and 0x1fffff) to Notepad.exe, excluding common system paths like System32, Syswow64, and Program Files. This behavior is often associated with the SliverC2 framework by BishopFox. Monitoring this activity is crucial as it may indicate an initial payload attempting to execute malicious code within Notepad.exe. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on SourceImage paths. If removing the paths is important, realize svchost and many native binaries inject into notepad consistently. Restrict or tune as needed. @@ -14125,7 +13904,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies the suspicious Remote Thread execution of wermgr.exe process to "firefox.exe", "chrome.exe" and other known browsers. This technique was seen in Qakbot malware that executes its malicious code by injecting its code in legitimate Windows Operating System processes such as wermgr.exe to steal information in the compromised host. This TTP detection can be a good pivot to detect wermgr.exe process injected with qakbot code that tries to remote thread code execution in known browsers like firefox and edge which is not a common behavior of this wermgr.exe application. +explanation = The following analytic identifies the suspicious remote thread execution of the wermgr.exe process into known browsers such as firefox.exe, chrome.exe, and others. It leverages Sysmon EventCode 8 logs to detect this behavior by monitoring SourceImage and TargetImage fields. This activity is significant because it is indicative of Qakbot malware, which injects malicious code into legitimate processes to steal information. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, and exfiltrate sensitive data from the compromised host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055.001", "T1055"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14135,7 +13914,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious remote thread execution in some process being abused by threat actor and malware like qakbot. Qakbot is one of the malware using this technique to load its malicious dll module or malicious code in the targeted host. This TTP can be a good pivot to verify what is the behavior of the targeted Image process after this detection trigger. look for network connection, child process execution, file access and many more that helps to verify the indication of malware infection. +explanation = The following analytic detects suspicious remote thread execution in processes such as Taskmgr.exe, calc.exe, and notepad.exe, which may indicate process injection by malware like Qakbot. This detection leverages Sysmon EventCode 8 to identify remote thread creation in specific target processes. This activity is significant as it often signifies an attempt by malware to inject malicious code into legitimate processes, potentially leading to unauthorized code execution. If confirmed malicious, this could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence on the compromised host. how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts like remote thread EventCode=8 of sysmon. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14145,7 +13924,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious wermgr.exe parent process having a child process not related to error, fault or windows werfault event. This technique was seen in Qakbot malware where it inject its malicious code in wermgr to evade detections and hide from the analyst to execute its recon and its malicious behavior. This Anomaly detection can be a good pivot to start investigating a possible qakbot infection in the network. The Wermgr.exe process is not known to have other child processes aside from itself or werfault.exe +explanation = The following analytic identifies a suspicious instance of wermgr.exe spawning a child process unrelated to error or fault handling. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process relationships and command-line executions. This activity is significant as it can indicate Qakbot malware, which injects malicious code into wermgr.exe to evade detection and execute malicious actions. If confirmed malicious, this behavior could allow an attacker to conduct reconnaissance, execute arbitrary code, and persist within the network, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -14155,7 +13934,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process in a non-standard file path on Windows attempting to create a remote thread into a process. This Windows API,CreateRemoteThread, is commonly used by adversaries for process injection to evade detections or gain privilege escalation. +explanation = The following analytic detects a process from a non-standard file path on Windows attempting to create a remote thread in another process. This is identified using Sysmon EventCode 8, focusing on processes not originating from typical system directories. This behavior is significant as it often indicates process injection, a technique used by adversaries to evade detection or escalate privileges. If confirmed malicious, this activity could allow an attacker to execute arbitrary code within another process, potentially leading to unauthorized actions and further compromise of the system. how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.AE"]} known_false_positives = Some security products or third party applications may utilize CreateRemoteThread, filter as needed before enabling as a notable. @@ -14165,7 +13944,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for process commandline that contains named pipe. This technique was seen in some adversaries, threat actor and malware like olympic destroyer to communicate to its other child processes after process injection that serve as defense evasion and privilege escalation. On the other hand this analytic may catch some normal process that using this technique for example browser application. In that scenario we include common process path we've seen during testing that cause false positive which is the program files. False positive may still be arise if the normal application is in other folder path. +explanation = The following analytic detects processes with command lines containing named pipes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line executions. This behavior is significant as it is often used by adversaries, such as those behind the Olympic Destroyer malware, for inter-process communication post-injection, aiding in defense evasion and privilege escalation. If confirmed malicious, this activity could allow attackers to maintain persistence, escalate privileges, or evade defenses, potentially leading to further compromise of the system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]} known_false_positives = Normal browser application may use this technique. Please update the filter macros to remove false positives. @@ -14175,7 +13954,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process writing a file, specifically a .txt, to a world writable path. This technique is used by adversaries to deliver payloads to a system. It is not common for living off the land binaries to write to these paths. +explanation = The following analytic identifies a process writing a .txt file to a world writable path. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on file creation events within specific directories. This activity is significant as adversaries often use such techniques to deliver payloads to a system, which is uncommon for legitimate processes. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the file creation event, process name, file path and, file name. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.005"], "nist": ["DE.AE"]} known_false_positives = False positives may occur if legitimate software writes to these paths. Modify the search to include additional file name extensions. To enhance it further, adding a join on Processes.process_name may assist with restricting the analytic to specific process names. Investigate the process and file to determine if it is malicious. @@ -14185,7 +13964,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to look for known processes killed by industroyer2 malware. This technique was seen in the industroyer2 malware attack that tries to kill several processes of windows host machines related to the energy facility network. This anomaly might be a good indicator to check which process kill these processes or why the process was killed. +explanation = The following analytic detects the termination of specific processes by the Industroyer2 malware. It leverages Sysmon EventCode 5 to identify when processes like "PServiceControl.exe" and "PService_PPD.exe" are killed. This activity is significant as it targets processes related to energy facility networks, indicating a potential attack on critical infrastructure. If confirmed malicious, this could lead to disruption of essential services, loss of control over energy systems, and significant operational impact. Immediate investigation is required to determine the cause and mitigate any potential threats. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]} known_false_positives = False positives are possible if legitimate applications are allowed to terminate this process during testing or updates. Filter as needed based on paths that are used legitimately. @@ -14195,7 +13974,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Plink being utilized to proxy egress or laterally in an organization. The analytic is limited to specific Plink options on the command-line, including -R -L and -D which will have the remote and local IP address or port and -l for a username. Modify the options as seen fit for your organization. +explanation = The following analytic detects the use of Plink for protocol tunneling, either for egress or lateral movement within an organization. It identifies specific Plink command-line options (-R, -L, -D, -l) by analyzing process execution logs from Endpoint Detection and Response (EDR) agents. This activity is significant as it may indicate an attempt to bypass network security controls or establish unauthorized connections. If confirmed malicious, this could allow an attacker to exfiltrate data, move laterally across the network, or maintain persistent access, posing a severe threat to the organization's security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1572", "T1021.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if the organization allows for SSH tunneling outbound or internally. Filter as needed. @@ -14205,7 +13984,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for processes launching netsh.exe for connection proxy. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line. +explanation = The following analytic identifies the use of netsh.exe to configure a connection proxy, which can be leveraged for persistence by executing a helper DLL. It detects this activity by analyzing process creation events from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "portproxy" and "v4tov4" parameters. This activity is significant because it indicates potential unauthorized network configuration changes, which could be used to maintain persistence or redirect network traffic. If confirmed malicious, this could allow an attacker to maintain covert access or manipulate network communications, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090.001", "T1090"], "nist": ["DE.AE"]} known_false_positives = Some VPN applications are known to launch netsh.exe. Outside of these instances, it is unusual for an executable to launch netsh.exe and run commands. @@ -14215,7 +13994,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for processes launching netsh.exe for connection proxy. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line. +explanation = The following analytic detects the modification of registry keys related to the Windows Proxy settings via netsh.exe. It leverages data from the Endpoint.Registry data model, focusing on changes to the registry path "*\\System\\CurrentControlSet\\Services\\PortProxy\\v4tov4\\tcp*". This activity is significant because netsh.exe can be used to establish a persistent proxy, potentially allowing an attacker to execute a helper DLL whenever netsh.exe runs. If confirmed malicious, this could enable the attacker to maintain persistence, manipulate network configurations, and potentially exfiltrate data or further compromise the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090.001", "T1090"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -14225,7 +14004,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious process accessing default internet browsers registry entry. This registry is used by Windows to store information about default internet browsers installed on a system. Malware, adversaries or red-teamers can abuse this registry key to collect data about the installed internet browsers and their associated settings. This information can be used to steal sensitive data such as login credentials, browsing history, and saved passwords. We observed noise that needs to be filter out so we add several known path of Windows Application to make this detection more stable. +explanation = The following analytic detects a suspicious process accessing the registry entries for default internet browsers. It leverages Windows Security Event logs, specifically event code 4663, to identify access attempts to these registry paths. This activity is significant because adversaries can exploit this registry key to gather information about installed browsers and their settings, potentially leading to the theft of sensitive data such as login credentials and browsing history. If confirmed malicious, this behavior could enable attackers to exfiltrate sensitive information and compromise user accounts. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = uninstall application may access this registry to remove the entry of the target application. filter is needed. @@ -14235,7 +14014,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of reg.exe with "save" parameter. This reg.exe parameter is commonly being abused by threat actors, adversaries and red-teamers to dump credentials or to check the registry modification capabilities of certain users or administrators in targeted hosts. This approach was seen in post-exploitation tool like winpeas where it uses "reg save" and "reg restore" to check registry modification restriction in targeted host after gaining access to it. +explanation = The following analytic detects the execution of the reg.exe process with the "save" parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because threat actors often use the "reg save" command to dump credentials or test registry modification capabilities on compromised hosts. If confirmed malicious, this behavior could allow attackers to escalate privileges, persist in the environment, or access sensitive information stored in the registry. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = network administrator can use this command tool to backup registry before updates or modifying critical registries. @@ -14245,7 +14024,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious query on uninstall application list in Windows OS registry. This registry is commonly used by legitimate software to store information about installed applications on a Windows system, such as their name, version, publisher, and installation path. However, malware, adversaries or even red-teamers can abuse this registry key to retrieve information stored in the "Uninstall" key to gather data about installed applications in the target host. This Anomaly detection can be a good pivot to detect a possible suspicious process accessing this registry which is not commonly accessed by a normal user. +explanation = The following analytic detects a suspicious query on the uninstall application list in the Windows OS registry. It leverages Windows Security Event logs, specifically event code 4663, to identify access to the "Uninstall" registry key. This activity is significant because adversaries or malware can exploit this key to gather information about installed applications, aiding in further attacks. If confirmed malicious, this behavior could allow attackers to map out installed software, potentially identifying vulnerabilities or software to exploit, leading to further system compromise. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]} known_false_positives = Uninstall application may access this registry to remove the entry of the target application. Filter is needed. @@ -14255,7 +14034,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Raccine Rules Updater scheduled task being deleted. Adversaries may attempt to remove this task in order to prevent the update of Raccine. Raccine is a "ransomware vaccine" created by security researcher Florian Roth, designed to intercept and prevent precursors and active ransomware behavior. +explanation = The following analytic identifies the deletion of the Raccine Rules Updater scheduled task using the `schtasks.exe` command. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because adversaries may delete this task to disable Raccine, a tool designed to prevent ransomware attacks. If confirmed malicious, this action could allow ransomware to execute without interference, leading to potential data encryption and loss. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, however filter as needed. @@ -14265,7 +14044,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4624 to identify a source computer authenticating to a large number of remote endpoints within an Active Directory network. Specifically, the logic will trigger when a source endpoint authenticates to 30 or more target computers within a 5 minute timespan. This behavior could represent an adversary who is moving laterally across the environment or enumerating network shares in the search for sensitive files. As environments differ across organizations, security teams should customize the thresholds of this detection as needed. +explanation = The following analytic detects a source computer authenticating to 30 or more remote endpoints within a 5-minute timespan using Event ID 4624. This behavior is identified by analyzing Windows Event Logs for LogonType 3 events and counting unique target computers. Such activity is significant as it may indicate lateral movement or network share enumeration by an adversary. If confirmed malicious, this could lead to unauthorized access to multiple systems, potentially compromising sensitive data and escalating privileges within the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed. @@ -14275,7 +14054,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows Windows Remote Auto Dialer, rasautou.exe executing an arbitrary DLL. This technique is used to execute arbitrary shellcode or DLLs via the rasautou.exe LOLBin capability. During triage, review parent and child process behavior including file and image loads. +explanation = The following analytic detects the execution of an arbitrary DLL by the Windows Remote Auto Dialer (rasautou.exe). This behavior is identified by analyzing process creation events where rasautou.exe is executed with specific command-line arguments. This activity is significant because it leverages a Living Off The Land Binary (LOLBin) to execute potentially malicious code, bypassing traditional security controls. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise, privilege escalation, or persistent access within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055.001", "T1218", "T1055"], "nist": ["DE.CM"]} known_false_positives = False positives will be limited to applications that require Rasautou.exe to load a DLL from disk. Filter as needed. @@ -14285,7 +14064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious raw access read to device disk partition of the host machine. This technique was seen in several attacks by adversaries or threat actor to wipe, encrypt or overwrite the boot sector of each partition as part of their impact payload for example the "hermeticwiper" malware. This detection is a good indicator that there is a process try to read or write on boot sector. +explanation = The following analytic detects suspicious raw access reads to the device disk partition of a host machine. It leverages Sysmon EventCode 9 logs to identify processes attempting to read or write to the boot sector, excluding legitimate system processes. This activity is significant as it is commonly associated with destructive actions by adversaries, such as wiping, encrypting, or overwriting the boot sector, as seen in attacks involving malware like HermeticWiper. If confirmed malicious, this behavior could lead to severe impacts, including system inoperability, data loss, or compromised boot integrity. how_to_implement = To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1561.002", "T1561"], "nist": ["DE.AE"]} known_false_positives = This event is really notable but we found minimal number of normal application from system32 folder like svchost.exe accessing it too. In this case we used 'system32' and 'syswow64' path as a filter for this detection. @@ -14295,7 +14074,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for suspicious raw access read to drive where the master boot record is placed. This technique was seen in several attacks by adversaries or threat actor to wipe, encrypt or overwrite the master boot record code as part of their impact payload. This detection is a good indicator that there is a process try to read or write on MBR sector. +explanation = The following analytic detects suspicious raw access reads to the drive containing the Master Boot Record (MBR). It leverages Sysmon EventCode 9 to identify processes attempting to read or write to the MBR sector, excluding legitimate system processes. This activity is significant because adversaries often target the MBR to wipe, encrypt, or overwrite it as part of their impact payload. If confirmed malicious, this could lead to system instability, data loss, or a complete system compromise, severely impacting the organization's operations. how_to_implement = To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1561.002", "T1561"], "nist": ["DE.CM"]} known_false_positives = This event is really notable but we found minimal number of normal application from system32 folder like svchost.exe accessing it too. In this case we used 'system32' and 'syswow64' path as a filter for this detection. @@ -14305,7 +14084,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies successful remote desktop connections. Utilize this analytic to hunt for successful attempts. In addition, the query may be modified for EventCode=1148 to potentially identify failed attempts. In testing, 1148 would not generate based on a failed logon attempt. Note this analytic requires enabling and a stanza in a inputs.conf. +explanation = The following analytic detects successful Remote Desktop Protocol (RDP) connections by monitoring EventCode 1149 from the Windows TerminalServices RemoteConnectionManager Operational log. This detection is significant as successful RDP connections can indicate remote access to a system, which may be leveraged by attackers to control or exfiltrate data. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further lateral movement within the network. Monitoring successful RDP connections is crucial for identifying potential security breaches and mitigating risks promptly. how_to_implement = The following analyic requires the WIndows TerminalServices RemoteConnectionManager Operational log to be enabled and ingested into Splunk. For the inputs, review https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1563.002"], "nist": ["DE.AE"]} known_false_positives = False positives will be present, filter as needed or restrict to critical assets on the perimeter. @@ -14315,7 +14094,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic monitors the BootExecute registry key for any modifications from its default value, which could indicate potential malicious activity. The BootExecute registry key, located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager, manages the list of applications and services that are executed during system boot. By default, the BootExecute value is set to "autocheck autochk *". Attackers might attempt to modify this value to achieve persistence, load malicious code, or tamper with the system's boot process. +explanation = The following analytic detects modifications to the BootExecute registry key, which manages applications and services executed during system boot. It leverages data from the Endpoint.Registry data model, focusing on changes to the registry path "HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\BootExecute". This activity is significant because unauthorized changes to this key can indicate attempts to achieve persistence, load malicious code, or tamper with the boot process. If confirmed malicious, this could allow an attacker to maintain persistence, execute arbitrary code at boot, or disrupt system operations. how_to_implement = To successfully implement this search you need to be ingesting information on Windows Registry that include the name of the path and key responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542", "T1547.001"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and will need to be filtered. @@ -14325,7 +14104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies installation of a root CA certificate by monitoring the registry. The base paths may be found [here](https://gist.github.com/mattifestation/75d6117707bcf8c26845b3cbb6ad2b6b/raw/ae65ef15c706140ffc2e165615204e20f2903028/RootCAInstallationDetection.xml). In short, there are specific certificate registry paths that will be written to (SetValue) when a new certificate is added. The high-fidelity events to pay attention to are SetValue events where the TargetObject property ends with "\Blob" as this indicates the direct installation or modification of a root certificate binary blob. The other high fidelity reference will be which process is making the registry modifications. There are very few processes that modify these day to day, therefore monitoring for all to start (hunting) provides a great beginning. +explanation = The following analytic detects the installation of a root CA certificate by monitoring specific registry paths for SetValue events. It leverages data from the Endpoint datamodel, focusing on registry paths containing "certificates" and registry values named "Blob." This activity is significant because unauthorized root CA certificates can compromise the integrity of encrypted communications and facilitate man-in-the-middle attacks. If confirmed malicious, this could allow an attacker to intercept, decrypt, or manipulate sensitive data, leading to severe security breaches. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.AE"]} known_false_positives = False positives will be limited to a legitimate business applicating consistently adding new root certificates to the endpoint. Filter by user, process, or thumbprint. @@ -14335,8 +14114,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process attempting to delete a scheduled task SD (Security Descriptor) from within the registry path of that task. This may occur from a non-standard process running and may not come from reg.exe. This particular behavior will remove the actual Task Name from the Task Scheduler GUI and from the command-line query - schtasks.exe /query. In addition, in order to perform this action, the user context will need to be SYSTEM. \ -Identifying the deletion of a scheduled task's Security Descriptor from the registry is significant for a SOC as it may indicate malicious activity attempting to remove evidence of a scheduled task, potentially for defense evasion purposes. If a true positive is detected, it suggests an attacker with privileged access attempting to remove traces of their activities, which can have a significant impact on the security and functionality of affected systems. Immediate investigation and response are required to mitigate further risks and preserve the integrity of the environment. +explanation = The following analytic detects a process attempting to delete a scheduled task's Security Descriptor (SD) from the registry path of that task. It leverages the Endpoint.Registry data model to identify registry actions performed by the SYSTEM user, specifically targeting deletions or modifications of the SD value. This activity is significant as it may indicate an attempt to remove evidence of a scheduled task for defense evasion. If confirmed malicious, it suggests an attacker with privileged access trying to hide their tracks, potentially compromising system integrity and security. Immediate investigation is required. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1562"], "nist": ["DE.AE"]} known_false_positives = False positives should be limited as the activity is not common to delete ONLY the SD from the registry. Filter as needed. Update the analytic Modified or Deleted values based on product that is in the datamodel. @@ -14346,7 +14124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a modification or registry add to the safeboot registry as an autostart mechanism. This technique is utilized by adversaries to persist a driver or service into Safe Mode. Two keys are monitored in this analytic, Minimal and Network. adding values to Minimal will load into Safe Mode and by adding into Network it will provide the service or drive the ability to perform network connections in Safe Mode. +explanation = The following analytic identifies modifications to the SafeBoot registry keys, specifically within the Minimal and Network paths. This detection leverages registry activity logs from endpoint data sources like Sysmon or EDR tools. Monitoring these keys is crucial as adversaries can use them to persist drivers or services in Safe Mode, with Network allowing network connections. If confirmed malicious, this activity could enable attackers to maintain persistence even in Safe Mode, potentially bypassing certain security measures and facilitating further malicious actions. 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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.CM"]} known_false_positives = updated windows application needed in safe boot may used this registry @@ -14356,7 +14134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when suspiciouly long data is written to the registry. This behavior is often associated with certain fileless malware threats or persistence techniques used by threat actors. Data stored in the registy is considered fileless since it does not get written to disk and is traditionally not well defended since normal users can modify thier own registry. +explanation = The following analytic detects suspiciously long data written to the Windows registry, a behavior often linked to fileless malware or persistence techniques. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on registry events with data lengths exceeding 512 characters. This activity is significant as it can indicate an attempt to evade traditional file-based defenses, making it crucial for SOC monitoring. If confirmed malicious, this technique could allow attackers to maintain persistence, execute code, or manipulate system configurations without leaving a conventional file footprint. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027", "T1027.011"], "nist": ["DE.CM"]} known_false_positives = Unknown, possible custom scripting. @@ -14366,7 +14144,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects modifications to the Windows Registry SIP Provider. It identifies this behavior by monitoring Sysmon EventID 7, which logs registry modification events. The analytic specifically looks for changes in registry paths and values associated with Cryptography Providers and OID Encoding Types. This behavior is worth identifying as it may indicate an attempt to subvert trust controls, a technique often used by adversaries to bypass security measures and maintain persistence in an environment. If a true positive is found, it suggests an attacker is trying to manipulate the system's cryptographic functions, potentially leading to unauthorized access, data theft, or other damaging outcomes. Upon triage, review the registry paths and values modified, and look for concurrent processes to identify the attack source. Review the path of the SIP being added. This approach helps analysts detect potential threats earlier and mitigate the risks. +explanation = The following analytic detects modifications to the Windows Registry SIP Provider. It leverages Sysmon Event ID 7 to monitor registry changes in paths and values related to Cryptography Providers and OID Encoding Types. This activity is significant as it may indicate an attempt to subvert trust controls, a common tactic for bypassing security measures and maintaining persistence. If confirmed malicious, an attacker could manipulate the system's cryptographic functions, potentially leading to unauthorized access, data theft, or other damaging outcomes. Review the modified registry paths and concurrent processes to identify the attack source. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.CM"]} known_false_positives = Be aware of potential false positives - legitimate applications may cause benign activities to be flagged. @@ -14376,7 +14154,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies renamed instances of regsv32.exe executing. regsv32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, validate if it is the legitimate regsv32.exe executing and what dll module content it is loading. This query relies on the original filename or internal name from the PE meta data. Expand the query as needed by looking for specific command line arguments outlined in other analytics. +explanation = The following analytic identifies instances where the regsvr32.exe binary has been renamed and executed. This detection leverages Endpoint Detection and Response (EDR) data, specifically focusing on the original filename metadata. Renaming regsvr32.exe is significant as it can be an evasion technique used by attackers to bypass security controls. If confirmed malicious, this activity could allow an attacker to execute arbitrary DLLs, potentially leading to code execution, privilege escalation, or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.010", "T1218"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14386,7 +14164,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following anomaly detection identifies the behavior related to 4 native Windows DLLs being loaded by a non-standard process. Identified by MDSec during their research into Brute Ratel, MDSec identified a high signal analytic by calling out these 4 DLLs being loaded into a process. LogonCLI.dll is the Net Logon Client DLL and is related to users and other domain services to get authenticated. Credui.dll is Credential Manager User Interface. Credential managers receive notifications when authentication information changes. For example, credential managers are notified when a user logs on or an account password changes. Samcli.dll is the Security Accounts Manager Client DLL. Adversaries may attempt to extract credential material from the Security Account Manager (SAM) database either through in-memory techniques or through the Windows Registry where the SAM database is stored. Dbghelp.dll is Windows Image Helper. Windows Image Helper is commonly seen in credential dumping due to native functions. All of these modules are important to monitor and track and combined may lead to credentail access or dumping. +explanation = The following analytic identifies the loading of four specific Windows DLLs (credui.dll, dbghelp.dll, samcli.dll, winhttp.dll) by a non-standard process. This detection leverages Sysmon EventCode 7 to monitor DLL load events and flags when all four DLLs are loaded within a short time frame. This activity is significant as it may indicate the presence of Brute Ratel C4, a sophisticated remote access tool used for credential dumping and other malicious activities. If confirmed malicious, this behavior could lead to unauthorized access, credential theft, and further compromise of the affected system. how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1219", "T1003"], "nist": ["DE.AE"]} known_false_positives = This module can be loaded by a third party application. Filter is needed. @@ -14396,7 +14174,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic is meant to help organizations understand what remote access software is being used in the environment. When reviewing this hunt, confirm the software identified is authorized to be utilized. Based on fidelity, create a new analytic for specific utilities banned within the organization. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic identifies the use of remote access software within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This detection is significant as unauthorized remote access tools can be used by adversaries to maintain persistent access to compromised systems. If confirmed malicious, this activity could allow attackers to remotely control systems, exfiltrate data, or further infiltrate the network. Review the identified software to ensure it is authorized and take action against any unauthorized utilities. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = False positives will be found. Filter as needed and create higher fidelity analytics based off banned remote access software. @@ -14406,7 +14184,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification or creation of Windows registry related to the Remote Manipulator System (RMS) Remote Admin tool. RMS is a legitimate tool developed by russian organization TektonIT and has been observed being abused by adversaries to gain remote access to the targeted host. Azorult malware utilized RMS to gain remote access. +explanation = The following analytic detects the creation or modification of Windows registry entries related to the Remote Manipulator System (RMS) Remote Admin tool. It leverages data from the Endpoint.Registry datamodel, focusing on registry paths containing "SYSTEM\\Remote Manipulator System." This activity is significant because RMS, while legitimate, is often abused by adversaries, such as in the Azorult malware campaigns, to gain unauthorized remote access. If confirmed malicious, this could allow attackers to remotely control the targeted host, leading to potential data exfiltration, system manipulation, or further network compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.CM"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -14416,7 +14194,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the use of Microsoft Remote Assistance, msra.exe, spawning PowerShell.exe or cmd.exe as a child process. Msra.exe by default has no command-line arguments and typically spawns itself. It will generate a network connection to the remote system that is connected. This behavior is indicative of another process injected into msra.exe. Review the parent process or cross process events to identify source. +explanation = The following analytic detects Microsoft Remote Assistance (msra.exe) spawning PowerShell.exe or cmd.exe as a child process. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where msra.exe is the parent process. This activity is significant because msra.exe typically does not spawn command-line interfaces, indicating potential process injection or misuse. If confirmed malicious, an attacker could use this technique to execute arbitrary commands, escalate privileges, or maintain persistence on the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, filter as needed. Add additional shells as needed. @@ -14426,7 +14204,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies an endpoint that remotely connects to another endpoint to create a new service using sc.exe. On the remote endpoint, the new service will be created and this action will trigger the creation of EventCode 7045 along with all the resulting service information. +explanation = The following analytic identifies the creation of a new service on a remote endpoint using sc.exe. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring for EventCode 7045, which indicates a new service creation. This activity is significant as it may indicate lateral movement or remote code execution attempts by an attacker. If confirmed malicious, this could allow the attacker to establish persistence, escalate privileges, or execute arbitrary code on the remote system, potentially leading to further compromise of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.AE"]} known_false_positives = Note that false positives may occur, and filtering may be necessary, especially when it comes to remote service creation by administrators or software management utilities. @@ -14436,7 +14214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies RDPWInst.exe tool, which is a RDP wrapper library tool designed to enable remote desktop host support and concurrent RDP session on reduced functionality system. Unfortunately, this open project was abused by adversaries to enable RDP connection to the targeted host for remote access and potentially be for lateral movement. +explanation = The following analytic detects the execution of the RDPWInst.exe tool, which is an RDP wrapper library used to enable remote desktop host support and concurrent RDP sessions. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, original file names, and specific command-line arguments. This activity is significant because adversaries can abuse this tool to establish unauthorized RDP connections, facilitating remote access and potential lateral movement within the network. If confirmed malicious, this could lead to unauthorized access, data exfiltration, and further compromise of the targeted host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} known_false_positives = This tool was designed for home usage and not commonly seen in production environment. Filter as needed. @@ -14446,7 +14224,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows firewall to enable remote desktop protocol on a targeted machine. This technique was seen in several adversaries, malware or red teamer to remotely access the compromised or targeted host by allowing this protocol in firewall. Even this protocol might be allowed in some production environment, This TTP behavior is a good pivot to check who and why the user want to enable this feature through firewall which is also common traits of attack to start lateral movement. +explanation = The following analytic detects modifications to the Windows firewall to enable Remote Desktop Protocol (RDP) on a targeted machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "netsh.exe" to allow TCP port 3389. This activity is significant as it may indicate an adversary attempting to gain remote access to a compromised host, a common tactic for lateral movement. If confirmed malicious, this could allow attackers to remotely control the system, leading to potential data exfiltration or further network compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -14456,7 +14234,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to enable remote desktop assistance on a targeted machine. This technique was seen in several adversaries, malware or red teamer like azorult to remotely access the compromised or targeted host by enabling this protocol in registry. Even this protocol might be allowed in some production environment, This Anomaly behavior is a good pivot to check who and why the user want to enable this feature through registry which is un-common. And as per stated in microsoft documentation the default value of this registry is false that makes this a good indicator of suspicious behavior. +explanation = The following analytic detects modifications in the Windows registry to enable remote desktop assistance on a targeted machine. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the "Control\\Terminal Server\\fAllowToGetHelp" registry path. This activity is significant because enabling remote assistance via registry is uncommon and often associated with adversaries or malware like Azorult. If confirmed malicious, this could allow an attacker to remotely access and control the compromised host, leading to potential data exfiltration or further system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -14466,7 +14244,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is to identify a modification in the Windows registry to enable remote desktop protocol on a targeted machine. This technique was seen in several adversaries, malware or red teamer to remotely access the compromised or targeted host by enabling this protocol in registry. Even this protocol might be allowed in some production environment, This TTP behavior is a good pivot to check who and why the user want to enable this feature through registry which is un-common. +explanation = The following analytic detects modifications in the Windows registry to enable Remote Desktop Protocol (RDP) on a targeted machine. It leverages data from the Endpoint.Registry datamodel, specifically monitoring changes to the "fDenyTSConnections" registry value. This activity is significant as enabling RDP via registry is uncommon and often associated with adversaries or malware attempting to gain remote access. If confirmed malicious, this could allow attackers to remotely control the compromised host, potentially leading to further exploitation and lateral movement within the network. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} known_false_positives = administrators may enable or disable this feature that may cause some false positive. @@ -14476,7 +14254,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is developed to detect suspicious executable or script files created or dropped in the root drive of a targeted host. This technique is commonly used by threat actors, adversaries or even red teamers to replicate or spread in possible removable drives. Back then, WORM malware was popular for this technique where it would drop a copy of itself in the root drive to be able to spread or to have a lateral movement in other network machines. Nowadays, Ransomware like CHAOS ransomware also use this technique to spread its malicious code in possible removable drives. This TTP detection can be a good indicator that a process might create a persistence technique or lateral movement of a targeted machine. We suggest checking the process name that creates this event, the file created, user type, and the reason why that executable or scripts are dropped in the root drive. +explanation = The following analytic detects the creation or dropping of executable or script files in the root directory of a removable drive. It leverages data from the Endpoint.Filesystem datamodel, focusing on specific file types and their creation paths. This activity is significant as it may indicate an attempt to spread malware, such as ransomware, via removable media. If confirmed malicious, this behavior could lead to unauthorized code execution, lateral movement, or persistence within the network, potentially compromising sensitive data and systems. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1091"], "nist": ["DE.CM"]} known_false_positives = Administrators may allow creation of script or exe in the paths specified. Filter as needed. @@ -14486,7 +14264,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate root domain linked policies for situational awareness and Active Directory Discovery. +explanation = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for root domain linked policies. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. This behavior is significant as it may indicate an attempt by adversaries or Red Teams to gain situational awareness and perform Active Directory Discovery. If confirmed malicious, this activity could allow attackers to map out domain policies, potentially aiding in further exploitation or lateral movement within the network. how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -14496,7 +14274,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious rundll32 commandline to update a user's system parameters related to desktop backgrounds, display settings, and visual themes. Specifically, it triggers the system to refresh and apply changes to the user-specific settings, such as wallpaper modifications or visual theme updates, ensuring that the changes take effect without the need to restart the system or log out and log back in. This technique was seen in Rhysida Ransomware and script as part of its defense evasion. This technique is not a common practice to lock a screen and maybe a good indicator of compromise. This command could also potentially be exploited by malware to disguise its activities or make unauthorized changes to a user's system settings without their knowledge or consent. +explanation = The following analytic detects the execution of a suspicious rundll32 command line that updates user-specific system parameters, such as desktop backgrounds, display settings, and visual themes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "user32.dll,UpdatePerUserSystemParameters." This activity is significant as it is uncommon for legitimate purposes and has been observed in Rhysida Ransomware for defense evasion. If confirmed malicious, this could allow an attacker to disguise activities or make unauthorized system changes, potentially leading to persistent unauthorized access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14516,7 +14294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies rundll32.exe with the commandline arguments loading davclnt.dll function - davsetcookie - to be used to access a remote WebDav instance. The analytic attempts to use join from Processes and All_Traffic to identify the network connection. This particular behavior was recently showcased in CVE-2023-23397. +explanation = The following analytic detects the execution of rundll32.exe with command-line arguments loading davclnt.dll and the davsetcookie function to access a remote WebDav instance. It uses data from Endpoint Detection and Response (EDR) agents, correlating process execution and network traffic data. This activity is significant as it may indicate exploitation of CVE-2023-23397, a known vulnerability. If confirmed malicious, this could allow an attacker to establish unauthorized remote connections, potentially leading to data exfiltration or further network compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]} known_false_positives = False positives will be present based on legitimate software, filtering may need to occur. @@ -14526,8 +14304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of suspicious scheduled tasks in Windows, specifically tasks created using schtasks.exe with the -create flag and an XML parameter in the command-line. This technique is commonly employed by threat actors, adversaries, and red teamers to establish persistence or achieve privilege escalation on targeted hosts. Notably, malware like Trickbot and Winter-Vivern have been observed using XML files to create scheduled tasks. Monitoring and investigating this activity is crucial to mitigate potential security risks. It is important to be aware that scripts or administrators may trigger this analytic, leading to potential false positives. To minimize false positives, adjust the filter based on the parent process or application. \ -When a true positive is detected, it suggests an attacker's attempt to gain persistence or execute additional malicious payloads, potentially resulting in data theft, ransomware, or other damaging outcomes. During triage, review the source of the scheduled task, the command to be executed, and capture any relevant on-disk artifacts. Analyze concurrent processes to identify the source of the attack. This analytic enables analysts to detect and respond to potential threats early, mitigating the associated risks effectively. +explanation = The following analytic detects the creation of scheduled tasks in Windows using schtasks.exe with the -create flag and an XML parameter. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it is a common technique for establishing persistence or achieving privilege escalation, often used by malware like Trickbot and Winter-Vivern. If confirmed malicious, this could allow attackers to maintain access, execute additional payloads, and potentially lead to data theft or ransomware deployment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = It is possible scripts or administrators may trigger this analytic. Filter as needed based on parent process, application. @@ -14537,7 +14314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when the Task Scheduler service "svchost.exe -k netsvcs -p -s Schedule" is the parent process to common command line, scripting, or shell execution binaries. Attackers often abuse the task scheduler service with these binaries as an execution and persistence mechanism in order to blend in with normal Windows operations. This TTP is also commonly seen for legitimate purposes such as business scripts or application updates. +explanation = The following analytic detects when the Task Scheduler service ("svchost.exe -k netsvcs -p -s Schedule") spawns common command line, scripting, or shell execution binaries such as "powershell.exe" or "cmd.exe". This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant as attackers often abuse the Task Scheduler for execution and persistence, blending in with legitimate Windows operations. If confirmed malicious, this could allow attackers to execute arbitrary code, maintain persistence, or escalate privileges within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1059"], "nist": ["DE.CM"]} known_false_positives = Unknown, possible custom scripting. @@ -14547,8 +14324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of a new task with the highest execution privilege via Schtasks.exe. This tactic is often observed in AsyncRAT attacks, where the scheduled task is used for persistence and privilege escalation. AsyncRAT sets up a scheduled task with parameters '/rl' and 'highest', triggering this technique. It's a strong indicator of potential malware or adversaries seeking to establish persistence and escalate privileges through scheduled tasks. This is crucial for a Security Operations Center (SOC) as it can prevent unauthorized system access and potential data breaches. \ -The analytic works by monitoring logs for process name, parent process, and command-line executions. In the presence of the '*/rl ' and ' highest *' commands in a schtasks.exe process, an alert is triggered. +explanation = The following analytic detects the creation of a new scheduled task with the highest execution privileges via Schtasks.exe. It leverages Endpoint Detection and Response (EDR) logs to monitor for specific command-line parameters ('/rl' and 'highest') in schtasks.exe executions. This activity is significant as it is commonly used in AsyncRAT attacks for persistence and privilege escalation. If confirmed malicious, this could allow an attacker to maintain persistent access and execute tasks with elevated privileges, potentially leading to unauthorized system access and data breaches. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]} known_false_positives = False positives may arise from legitimate applications that create tasks to run as SYSTEM. Therefore, it's recommended to adjust filters based on parent process or modify the query to include world writable paths for restriction. @@ -14558,7 +14334,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the creation of a new task to start and run as an elevated user - SYSTEM using Schtasks.exe. This behavior is commonly used by adversaries to spawn a process in an elevated state. If a true positive is found, it suggests an attacker is attempting to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. Upon triage, review the scheduled task's source and the command to be executed. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. +explanation = The following analytic detects the creation of a new scheduled task using Schtasks.exe to run as the SYSTEM user. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as it often indicates an attempt to gain elevated privileges or maintain persistence within the environment. If confirmed malicious, an attacker could execute code with SYSTEM-level privileges, potentially leading to data theft, ransomware deployment, or further system compromise. Immediate investigation and mitigation are crucial to prevent further damage. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = False positives will be limited to legitimate applications creating a task to run as SYSTEM. Filter as needed based on parent process, or modify the query to have world writeable paths to restrict it. @@ -14568,7 +14344,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a potential PowerShell script that captures screen images on compromised or targeted hosts. This technique was observed in the Winter-Vivern malware, which attempts to capture desktop screens using a PowerShell script and send the images to its C2 server as part of its exfiltration strategy. This TTP serves as a useful indicator that a PowerShell process may be gathering desktop screenshots from a host system, potentially signaling malicious activity. +explanation = The following analytic detects the execution of a PowerShell script designed to capture screen images on a host. It leverages PowerShell Script Block Logging to identify specific script block text patterns associated with screen capture activities. This behavior is significant as it may indicate an attempt to exfiltrate sensitive information by capturing desktop screenshots. If confirmed malicious, this activity could allow an attacker to gather visual data from the compromised system, potentially leading to data breaches or further exploitation. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -14588,7 +14364,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line related to the discovery of possible Security Support Providers in the registry. This technique is being abused by adversaries or post exploitation tools like winpeas to gather LSA protection and configuration in the registry in the targeted host. This registry entry can contain several information related to LSA that validates users for local and remote sign-ins and enforces local security policies. Understanding LSA protection may give a good information in accessing LSA content in memory which is commonly attack by adversaries and tool like mimikatz to scrape password hashes or clear plain text passwords. +explanation = The following analytic identifies command-line activity querying the registry for Security Support Providers (SSPs) related to Local Security Authority (LSA) protection and configuration. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on processes accessing specific LSA registry paths. Monitoring this activity is crucial as adversaries and post-exploitation tools like winpeas may use it to gather information on LSA protections, potentially leading to credential theft. If confirmed malicious, attackers could exploit this to scrape password hashes or plaintext passwords from memory, significantly compromising system security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.005", "T1547"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -14598,7 +14374,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the Windows SDK utility - GACUtil.exe, being utilized to add a DLL into the Global Assembly Cache (GAC). Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer. By adding a DLL to the GAC, this allows an adversary to call it via any other means across the operating systems. As outlined by Microsoft in their blog, it is not common to see this spawning from W3WP.exe, however, in a non-development environment it may not be common at all. Note that in order to utilize GACutil.exe, The Windows SDK must be installed, this is not a native binary. +explanation = The following analytic detects the use of GACUtil.exe to add a DLL into the Global Assembly Cache (GAC). It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because adding a DLL to the GAC allows it to be called by any application, potentially enabling widespread code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code across the operating system, leading to privilege escalation or persistent access. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if gacutil.exe is utilized day to day by developers. Filter as needed. @@ -14628,7 +14404,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = When an adversary utilizes SliverC2 to laterally move with the Psexec module, it will create a service with the name and description of "Sliver" and "Sliver Implant". Note that these may be easily changed and are specific to only SliverC2. We have also created the same regex as Microsoft has outlined to attempt to capture the suspicious service path (regex101 reference). +explanation = The following analytic detects the creation of a Windows service named "Sliver" with the description "Sliver Implant," indicative of SliverC2 lateral movement using the PsExec module. It leverages Windows EventCode 7045 from the System Event log to identify this activity. This behavior is significant as it may indicate an adversary's attempt to establish persistence or execute commands remotely. If confirmed malicious, this activity could allow attackers to maintain control over the compromised system, execute arbitrary code, and further infiltrate the network. how_to_implement = To implement this analytic, the Windows EventCode 7045 will need to be logged from the System Event log. The Windows TA for Splunk is also recommended. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if another service out there is named Sliver, filtering may be needed. @@ -14638,7 +14414,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects potential RDP Hijacking attempts by monitoring a series of actions taken by an attacker to gain unauthorized access to a remote system. The attacker first runs the quser command to query the remote host for disconnected user sessions. Upon identifying a disconnected session, they use the sc.exe command to create a new Windows service with a binary path that launches tscon.exe. By specifying the disconnected session ID and a destination ID, the attacker can transfer the disconnected session to a new RDP session, effectively hijacking the user's session. This analytic allows security teams to detect and respond to RDP Hijacking attempts, mitigating potential risks and impacts on targeted systems. +explanation = The following analytic detects potential RDP Hijacking attempts by identifying the creation of a Windows service using sc.exe with a binary path that includes tscon.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line arguments. This activity is significant as it indicates an attacker may be trying to hijack a disconnected RDP session, posing a risk of unauthorized access. If confirmed malicious, the attacker could gain control over an existing user session, leading to potential data theft or further system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1563.002", "T1563", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = False positives may arise in the RDP Hijacking analytic when legitimate administrators access remote sessions for maintenance or troubleshooting purposes. These activities might resemble an attacker''s attempt to hijack a disconnected session, leading to false alarms. To mitigate the risk of false positives and improve the overall security posture, organizations can implement Group Policy to automatically disconnect RDP sessions when they are complete. By enforcing this policy, administrators ensure that disconnected sessions are promptly terminated, reducing the window of opportunity for an attacker to hijack a session. Additionally, organizations can also implement access control mechanisms and monitor the behavior of privileged accounts to further enhance security and reduce the chances of false positives in RDP Hijacking detection. @@ -14648,7 +14424,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytics uses Windows Event Id 7045, `New Service Was Installed`, to identify the creation of a Windows Service where the service binary path path is located in a non-common Service folder in Windows. Red Teams and adversaries alike may create malicious Services for lateral movement or remote code execution as well as persistence and execution. The Clop ransomware has also been seen in the wild abusing Windows services. +explanation = The following analytic detects the creation of a Windows Service with a binary path located in uncommon directories, using Windows Event ID 7045. It leverages logs from the `wineventlog_system` to identify services installed outside typical system directories. This activity is significant as adversaries, including those deploying Clop ransomware, often create malicious services for lateral movement, remote code execution, persistence, and execution. If confirmed malicious, this could allow attackers to maintain persistence, execute arbitrary code, and potentially escalate privileges, posing a severe threat to the environment. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may install services with uncommon services paths. @@ -14658,7 +14434,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytc uses Windows Event Id 7045, `New Service Was Installed`, to identify the creation of a Windows Service where the service binary path is located in public paths. This behavior could represent the installation of a malicious service. Red Teams and adversaries alike may create malicious Services for lateral movement or remote code execution +explanation = The following analytic detects the creation of a Windows Service with its binary path located in public directories using Windows Event ID 7045. This detection leverages logs from the `wineventlog_system` data source, focusing on the `ImagePath` field to identify services installed outside standard system directories. This activity is significant as it may indicate the installation of a malicious service, often used by adversaries for lateral movement or remote code execution. If confirmed malicious, this could allow attackers to execute arbitrary code, maintain persistence, or further compromise the system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may install services with uncommon services paths. @@ -14668,7 +14444,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `sc.exe` with command-line arguments utilized to create a Windows Service on a remote endpoint. Red Teams and adversaries alike may abuse the Service Control Manager for lateral movement and remote code execution. +explanation = The following analytic identifies the creation of a Windows Service on a remote endpoint using `sc.exe`. It detects this activity by analyzing process execution logs from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments that include remote paths and service creation commands. This behavior is significant because adversaries often exploit the Service Control Manager for lateral movement and remote code execution. If confirmed malicious, this activity could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may create Windows Services on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -14678,7 +14454,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when reg.exe modify registry keys that define Windows services and their configurations in Windows to detect potential threats earlier and mitigate the risks. This detection is made by a Splunk query that searches for specific keywords in the process name, parent process name, user, and process ID. This detection is important because it suggests that an attacker has modified the registry keys that define Windows services and their configurations, which can allow them to maintain access to the system and potentially move laterally within the network. It is a common technique used by attackers to gain persistence on a compromised system and its impact can lead to data theft, ransomware, or other damaging outcomes. False positives can occur since legitimate uses of reg.exe to modify registry keys for Windows services can also trigger this alert. Next steps include reviewing the process and user context of the reg.exe activity and identify any other concurrent processes that might be associated with the attack upon triage. +explanation = The following analytic detects the modification of registry keys that define Windows services using reg.exe. This detection leverages Splunk to search for specific keywords in the registry path, value name, and value data fields. This activity is significant because it indicates potential unauthorized changes to service configurations, a common persistence technique used by attackers. If confirmed malicious, this could allow an attacker to maintain access, escalate privileges, or move laterally within the network, leading to data theft, ransomware, or other damaging outcomes. how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.011"], "nist": ["DE.CM"]} known_false_positives = Third party tools may used this technique to create services but not so common. @@ -14698,7 +14474,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `sc.exe` with command-line arguments utilized to start a Windows Service on a remote endpoint. Red Teams and adversaries alike may abuse the Service Control Manager for lateral movement and remote code execution. +explanation = The following analytic detects the execution of `sc.exe` with command-line arguments used to start a Windows Service on a remote endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because adversaries may exploit the Service Control Manager for lateral movement and remote code execution. If confirmed malicious, this could allow attackers to execute arbitrary code on remote systems, potentially leading to further compromise and persistence within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]} known_false_positives = Administrators may start Windows Services on remote systems, but this activity is usually limited to a small set of hosts or users. @@ -14708,7 +14484,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies Windows Service Control, `sc.exe`, attempting to delete a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique to terminate security services or other related services to continue there objective and evade detections. +explanation = The following analytic detects the use of `sc.exe` to delete a Windows service. It leverages Endpoint Detection and Response (EDR) data, focusing on process execution logs that capture command-line arguments. This activity is significant because adversaries often delete services to disable security mechanisms or critical system functions, aiding in evasion and persistence. If confirmed malicious, this action could lead to the termination of essential security services, allowing attackers to operate undetected and potentially escalate their privileges or maintain long-term access to the compromised system. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]} known_false_positives = It is possible administrative scripts may start/stop/delete services. Filter as needed. @@ -14718,7 +14494,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies suspicious attempts to stop services on a system using either `net.exe` or `sc.exe`. This technique is used by adversaries to terminate security services or other related services to continue their objective and evade detections. This technique is also commonly used by ransomware threat actors to successfully encrypt databases or files being processed or used by Windows OS Services. +explanation = The following analytic identifies attempts to stop services on a system using `net.exe` or `sc.exe`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, GUIDs, and command-line executions. This activity is significant as adversaries often terminate security or critical services to evade detection and further their objectives. If confirmed malicious, this behavior could allow attackers to disable security defenses, facilitate ransomware encryption, or disrupt essential services, leading to potential data loss or system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]} known_false_positives = Windows OS or software may stop and restart services due to some critical update. @@ -14728,7 +14504,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a windows update service being disabled in Windows OS. This technique is being abused by adversaries or threat actors to add defense mechanisms to their malware implant in the targeted host. Disabling windows update will put the compromised host vulnerable in some zero day exploit or even some update features against threats. RedLine Stealer kills this service as part of its defense evasion mechanism. +explanation = The following analytic detects the disabling of Windows Update services, such as "Update Orchestrator Service for Windows Update," "WaaSMedicSvc," and "Windows Update." It leverages Windows System Event ID 7040 logs to identify changes in service start modes to 'disabled.' This activity is significant as it can indicate an adversary's attempt to evade defenses by preventing critical updates, leaving the system vulnerable to exploits. If confirmed malicious, this could allow attackers to maintain persistence and exploit unpatched vulnerabilities, compromising the integrity and security of the affected host. how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints (like Windows system.log Event ID 7040) annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]} known_false_positives = Network administrator may disable this services as part of its audit process within the network. Filter is needed. @@ -14738,7 +14514,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following inventory analytic is used with a PowerShell scripted inputs to capture all SIP providers on a Windows system. This analytic is used to identify potential malicious SIP providers that may be used to subvert trust controls. Upon review, look for new and non-standard paths for SIP providers. +explanation = The following analytic identifies all SIP (Subject Interface Package) providers on a Windows system using PowerShell scripted inputs. It detects SIP providers by capturing DLL paths from relevant events. This activity is significant because malicious SIP providers can be used to bypass trust controls, potentially allowing unauthorized code execution. If confirmed malicious, this activity could enable attackers to subvert system integrity, leading to unauthorized access or persistent threats within the environment. Analysts should review for new and non-standard paths to identify potential threats. how_to_implement = To implement this analytic, one must first perform inventory using a scripted inputs. Review the following Gist - https://gist.github.com/MHaggis/75dd5db546c143ea67703d0e86cdbbd1 annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.AE"]} known_false_positives = False positives are limited as this is a hunting query for inventory. @@ -14748,7 +14524,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI 2, to identify failed trust validation. Typically, this event log is meant for diagnosing PKI issues, however is a great source to identify failed trust validation. Note that this event log is noisy as it captures common PKI requests from many different processes. EventID 81 is generated anytime a trust validation fails. The description for EventID 81 is "The digital signature of the object did not verify." STRT tested this analytic using Mimikatz binary. +explanation = The following analytic detects failed trust validation attempts using Windows Event Log - CAPI2 (CryptoAPI 2). It specifically triggers on EventID 81, which indicates that "The digital signature of the object did not verify." This detection leverages the CAPI2 Operational log to identify instances where digital signatures fail to validate. Monitoring this activity is crucial as it can indicate attempts to execute untrusted or potentially malicious binaries. If confirmed malicious, this activity could allow attackers to bypass security controls and execute unauthorized code, leading to potential system compromise. how_to_implement = To implement this analytic, one will need to enable the Microsoft-Windows-CAPI2/Operational log within the Windows Event Log. Note this is a debug log for many purposes, and the analytic only focuses in on EventID 81. Review the following gist for additional enabling information. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.AE"]} known_false_positives = False positives may be present in some instances of legitimate binaries with invalid signatures. Filter as needed. @@ -14768,7 +14544,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the comadmin.dat file written to disk, which is related to Snake Malware. From the report, Snakes installer drops the kernel driver and a custom DLL which is used to load the driver into a single AES encrypted file on disk. Typically, this file is named comadmin.dat and is stored in the %windows%\system32\Com directory. +explanation = The following analytic detects the creation of the comadmin.dat file in the %windows%\system32\Com directory, which is associated with Snake Malware. This detection leverages the Endpoint.Filesystem data model to identify file creation events matching the specified path and filename. This activity is significant because the comadmin.dat file is part of Snake Malware's installation process, which includes dropping a kernel driver and a custom DLL. If confirmed malicious, this activity could allow an attacker to load a malicious driver, potentially leading to privilege escalation and persistent access to the compromised system. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.006"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter as needed. @@ -14778,7 +14554,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The follow analytic identifies the registry being modified at .wav\\OpenWithProgIds\, which is related to the Snake Malware campaign. Upon execution, Snake's WerFault.exe will attempt to decrypt an encrypted blob within the Windows registry that is typically found at HKLM:\SOFTWARE\Classes\.wav\OpenWithProgIds. The encrypted data includes the AES key, IV, and path that is used to find and decrypt the file containing Snake's kernel driver and kernel driver loader. +explanation = The following analytic identifies modifications to the registry path .wav\\OpenWithProgIds, associated with the Snake Malware campaign. It leverages data from the Endpoint.Registry datamodel to detect changes in this specific registry location. This activity is significant because Snake's WerFault.exe uses this registry path to decrypt an encrypted blob containing critical components like the AES key, IV, and paths for its kernel driver and loader. If confirmed malicious, this could allow the attacker to load and execute Snake's kernel driver, leading to potential system compromise and persistent access. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} known_false_positives = False positives may be present and will require tuning based on program Ids in large organizations. @@ -14788,7 +14564,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a new service WerFaultSvc being created with a binary path located in the windows winsxs path. Per the report, the Snake version primarily discussed in this advisory registers a service to maintain persistence on a system. Typically this service is named WerFaultSvc which we assess was used to blend in with the legitimate Windows service WerSvc. On boot, this service will execute Snakes WerFault.exe, which Snake developers chose to hide among the numerous valid Windows WerFault.exe files in the windows WinSxS directory. Executing WerFault.exe will start the process of decrypting Snakes components and loading them into memory. +explanation = The following analytic detects the creation of a new service named WerFaultSvc with a binary path in the Windows WinSxS directory. It leverages Windows System logs, specifically EventCode 7045, to identify this activity. This behavior is significant because it indicates the presence of Snake malware, which uses this service to maintain persistence by blending in with legitimate Windows services. If confirmed malicious, this activity could allow an attacker to execute Snake malware components, leading to potential data exfiltration, system compromise, and long-term persistence within the environment. how_to_implement = To successfully implement this search, you need to be ingesting Windows System logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.006", "T1569.002"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as this is a strict primary indicator used by Snake Malware. @@ -14798,7 +14574,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the common command-line argument used by SOAPHound `soaphound.exe`. Being the script is publicly available, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. It does not cover the entirety of every argument in order to avoid false positives. +explanation = The following analytic detects the execution of the SOAPHound binary (`soaphound.exe`) with specific command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and other process-related metadata. This activity is significant because SOAPHound is a known tool used for credential dumping and other malicious activities. If confirmed malicious, this behavior could allow an attacker to extract sensitive information, escalate privileges, or persist within the environment, posing a severe threat to organizational security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as the command-line arguments are specific to SOAPHound. Filter as needed. @@ -14808,7 +14584,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = this detection was designed to identifies suspicious office documents that connect to a website aside from Microsoft Office Domain. This technique was seen in several malicious documents that abuses .rels xml properties of MS office to connect or download malicious files. This hunting query can be a good pivot or guide to check what URL link it tries to connect, what domain, where the documents came from and how the connection happens. +explanation = The following analytic identifies suspicious Office documents that connect to non-Microsoft Office domains. It leverages Sysmon EventCode 22 to detect processes like winword.exe or excel.exe making DNS queries to domains outside of *.office.com or *.office.net. This activity is significant as it may indicate a spearphishing attempt using malicious documents to download or connect to harmful content. If confirmed malicious, this could lead to unauthorized data access, malware infection, or further network compromise. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} known_false_positives = Windows Office document may contain legitimate url link other than MS office Domain. filter is needed @@ -14818,7 +14594,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, AsyncRat, Redline and DCRAT). This detection identifies onenote Office Product spawning `mshta.exe`. In malicious instances, the command-line of `mshta.exe` will contain the `hta` file locally, or a URL to the remote destination. In addition, Threat Research has released a detections identifying suspicious use of `mshta.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `mshta.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity. +explanation = The following analytic detects OneNote spawning `mshta.exe`, a behavior often associated with spearphishing attacks. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where OneNote is the parent process. This activity is significant as it is commonly used by malware families like TA551, AsyncRat, Redline, and DCRAT to execute malicious scripts. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to data exfiltration, system compromise, or further malware deployment. Immediate investigation and containment are recommended. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.CM"]} known_false_positives = No false positives known. Filter as needed. @@ -14828,7 +14604,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Event ID 4672 to identify a source user authenticating with special privileges across a large number remote endpoints. Specifically, the logic will trigger when a source user obtains special privileges across 30 or more target computers within a 5 minute timespan. Special privileges are assigned to a new logon session when sensitive privileges like SeDebugPrivilege and SeImpersonatePrivilege are assigned. This behavior could represent an adversary who is moving laterally and executing remote code across the network. It can also be triggered by other behavior like an adversary enumerating network shares. As environments differ across organizations, security teams should customize the thresholds of this detection as needed. +explanation = The following analytic detects a user authenticating with special privileges on 30 or more remote endpoints within a 5-minute window. It leverages Event ID 4672 from Windows Security logs to identify this behavior. This activity is significant as it may indicate lateral movement or remote code execution by an adversary. If confirmed malicious, the attacker could gain extensive control over the network, potentially leading to privilege escalation, data exfiltration, or further compromise of the environment. Security teams should adjust detection thresholds based on their specific environment. how_to_implement = To successfully implement this search, you need to be ingesting special logon events. The Advanced Security Audit policy setting `Audit Special Logon` within `Logon/Logoff` need to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1021.002", "T1135"], "nist": ["DE.CM"]} known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed. @@ -14838,7 +14614,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the use of certutil to download software, a behavior exhibited by the threat actor Flax Typhoon. This actor deploys a VPN connection by downloading an executable file for SoftEther VPN from their network infrastructure using one of several LOLBins, including certutil. The actor then uses the Service Control Manager (SCM) to create a Windows service that launches the VPN connection automatically when the system starts. This behavior allows the actor to monitor the availability of the compromised system and establish an RDP connection. This analytic identifies this behavior by monitoring for the use of certutil in conjunction with the downloading of software. This behavior is worth identifying for a SOC as it indicates a potential compromise of the system and the establishment of a persistent threat. If a true positive is found, it suggests an attacker has gained access to the environment and is attempting to maintain that access, potentially leading to further malicious activities such as data theft or ransomware attacks. Be aware of potential false positives - legitimate uses of certutil in your environment may cause benign activities to be flagged. Upon triage, review the command executed and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. +explanation = The following analytic detects the use of certutil to download software, specifically when spawned by SQL-related processes. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions involving certutil with parameters like *urlcache* and *split*. This activity is significant as it may indicate a compromise by threat actors, such as Flax Typhoon, who use certutil to establish persistent VPN connections. If confirmed malicious, this behavior could allow attackers to maintain access, monitor system availability, and potentially escalate to data theft or ransomware deployment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = The occurrence of false positives should be minimal, given that the SQL agent does not typically download software using CertUtil. @@ -14848,7 +14624,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the abuse of SqlWriter and SQLDumper executables to sideload the vcruntime140.dll library. This technique is commonly used by adversaries to load malicious code into a legitimate process. The analytic searches for EventCode 7 from Sysmon logs where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives. +explanation = The following analytic detects the abuse of SqlWriter and SQLDumper executables to sideload the vcruntime140.dll library. It leverages Sysmon EventCode 7 logs, focusing on instances where SQLDumper.exe or SQLWriter.exe load vcruntime140.dll, excluding legitimate loads from the System32 directory. This activity is significant as it indicates potential DLL sideloading, a technique used by adversaries to execute malicious code within trusted processes. If confirmed malicious, this could allow attackers to execute arbitrary code, maintain persistence, and evade detection by blending with legitimate processes. how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives. The analytic can be modified to include additional known good paths for vcruntime140.dll to further reduce false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002"], "nist": ["DE.CM"]} known_false_positives = False positives are possible if legitimate processes are loading vcruntime140.dll from non-standard directories. It is recommended to investigate the context of the process loading vcruntime140.dll to determine if it is malicious or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives. @@ -14858,7 +14634,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when a new certificate is requested and/or granted against the Active Directory Certificate Services (AD CS) using a Subject Alternative Name (SAN). This action by its self is not malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1) +explanation = The following analytic detects when a new certificate is requested or granted against Active Directory Certificate Services (AD CS) using a Subject Alternative Name (SAN). It leverages Windows Security Event Codes 4886 and 4887 to identify these actions. This activity is significant because improperly configured certificate templates can be exploited for privilege escalation and environment compromise. If confirmed malicious, an attacker could gain elevated privileges or persist within the environment, potentially leading to unauthorized access to sensitive information and further exploitation. how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names. Sources or templates used in these processes may need to be tuned out for accurate function. @@ -14868,7 +14644,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when a suspicious certificate is granted using Active Directory Certificate Services (AD CS) with a Subject Alternative Name (SAN) and then immediately used for authentication. This action alone may not be malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1). +explanation = The following analytic detects when a suspicious certificate with a Subject Alternative Name (SAN) is issued using Active Directory Certificate Services (AD CS) and then immediately used for authentication. This detection leverages Windows Security Event Logs, specifically EventCode 4887, to identify the issuance and subsequent use of the certificate. This activity is significant because improperly configured certificate templates can be exploited for privilege escalation and environment compromise. If confirmed malicious, an attacker could gain unauthorized access, escalate privileges, and potentially compromise the entire environment. how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1550"], "nist": ["DE.CM"]} known_false_positives = False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names for authentication. Sources or templates used in these processes may need to be tuned out for accurate function. @@ -14878,7 +14654,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when a new certificate is issued against the Certificate Services - AD CS. By its very nature this is not malicious, but should be tracked and correlated with other events related to certificates being issued. When the CA issues the certificate, it creates EID 4887 'Certificate Services approved a certificate request and issued a certificate". The event supplies the requester user context, the DNS hostname of the machine they requested the certificate from, and the time they requested the certificate. The attributes fields in these event commonly has values for CDC, RMD, and CCM which correspond to Client DC, Request Machine DNS name, and Cert Client Machine, respectively. +explanation = The following analytic identifies the issuance of a new certificate by Certificate Services - AD CS, detected via Event ID 4887. This event logs the requester user context, DNS hostname of the requesting machine, and the request time. Monitoring this activity is crucial as it can indicate potential misuse of authentication certificates. If confirmed malicious, an attacker could use the issued certificate to impersonate users, escalate privileges, or maintain persistence within the environment. This detection helps in identifying and correlating suspicious certificate-related activities for further investigation. how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]} known_false_positives = False positives will be generated based on normal certificates issued. Leave enabled to generate Risk, as this is meant to be an anomaly analytic. @@ -14888,7 +14664,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies when a new certificate is requested against the Certificate Services - AD CS. By its very nature this is not malicious, but should be tracked and correlated with other events related to certificate requests. When an account requests a certificate, the CA generates event ID (EID) 4886 "Certificate Services received a certificate request". +explanation = The following analytic detects when a new certificate is requested from Certificate Services - AD CS. It leverages Event ID 4886, which indicates that a certificate request has been received. This activity is significant because unauthorized certificate requests can be part of credential theft or lateral movement tactics. If confirmed malicious, an attacker could use the certificate to impersonate users, gain unauthorized access to resources, or establish persistent access within the environment. Monitoring and correlating this event with other suspicious activities is crucial for identifying potential security incidents. how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]} known_false_positives = False positives will be generated based on normal certificate requests. Leave enabled to generate Risk, as this is meant to be an anomaly analytic. @@ -14908,7 +14684,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI 2, to identify suspicious certificate extraction. Typically, this event log is meant for diagnosing PKI issues, however is a great source to identify certificate exports. Note that this event log is noisy as it captures common PKI requests from many different processes. EventID 70 is generated anytime a certificate is exported. The description for EventID 70 is "Acquire Certificate Private Key". STRT tested this analytic using Mimikatz binary and the implementation of Mimikatz in Cobalt Strike. +explanation = The following analytic detects the extraction of authentication certificates using Windows Event Log - CAPI2 (CryptoAPI 2). It leverages EventID 70, which is generated when a certificate's private key is acquired. This detection is significant because it can identify potential misuse of certificates, such as those extracted by tools like Mimikatz or Cobalt Strike. If confirmed malicious, this activity could allow attackers to impersonate users, escalate privileges, or access sensitive information, posing a severe risk to the organization's security. how_to_implement = To implement this analytic, one will need to enable the Microsoft-Windows-CAPI2/Operational log within the Windows Event Log. Note this is a debug log for many purposes, and the analytic only focuses in on EventID 70. Review the following gist for additional enabling information. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]} known_false_positives = False positives may be present in some instances of legitimate applications requiring to export certificates. Filter as needed. @@ -14948,7 +14724,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS klist.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to display or gather list of currently cached kerberos ticket. This cahced data can be used for lateral movement or even privilege escalation on the targeted host. This hunting query can be a good pivot in possible kerberos attack or pass the hash technique. +explanation = The following analytic identifies the execution of the Windows OS tool klist.exe, often used by post-exploitation tools like winpeas. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process details. Monitoring klist.exe is significant as it can indicate attempts to list or gather cached Kerberos tickets, which are crucial for lateral movement or privilege escalation. If confirmed malicious, this activity could enable attackers to move laterally within the network or escalate privileges, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -14958,7 +14734,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies executables running from public or temporary locations that are communicating over windows domain authentication ports/protocol. The ports/protocols include LDAP(389), LDAPS(636), and Kerberos(88). Authentications from applications running from user controlled locations may not be malicious, however actors often attempt to access domain resources after initial compromise from executables in these locations. Most attacker toolkits offer some degree of interaction with AD/LDAP. +explanation = The following analytic detects executables running from public or temporary locations that are communicating over Windows domain authentication ports/protocols such as LDAP (389), LDAPS (636), and Kerberos (88). It leverages network traffic data to identify processes originating from user-controlled directories. This activity is significant because legitimate applications rarely run from these locations and attempt domain authentication, making it a potential indicator of compromise. If confirmed malicious, attackers could leverage this to access domain resources, potentially leading to further exploitation and lateral movement within the network. how_to_implement = To implement this analytic, Sysmon should be installed in the environment and generating network events for userland and/or known public writable locations. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.002", "T1204", "T1204.002"], "nist": ["DE.AE"]} known_false_positives = Known applications running from these locations for legitimate purposes. Targeting only kerberos (port 88) may significantly reduce noise. @@ -14968,7 +14744,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the decompile parameter with the HTML Help application, HH.exe. This is a uncommon command to see ran and behavior. Most recently this was seen in a APT41 campaign where a CHM file was delivered and a script inside used a technique for running an arbitrary command in a CHM file via an ActiveX object. This unpacks an HTML help file to a specified path for launching the next stage. +explanation = The following analytic detects the use of the decompile parameter with the HTML Help application (HH.exe). This behavior is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions involving the decompile parameter. This activity is significant because it is an uncommon command and has been associated with APT41 campaigns, where it was used to unpack HTML help files for further malicious actions. If confirmed malicious, this technique could allow attackers to execute arbitrary commands, potentially leading to further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.001", "T1218"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, filter as needed. @@ -14978,7 +14754,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the execution of nslookup.exe tool to get domain information. Nslookup.exe is a command-line tool that can display information to diagnose domain name systems. This Nslookup feature is being abused by Qakbot malware to gather domain information such as SRV service location records, server name and many more. +explanation = The following analytic detects the execution of nslookup.exe to query domain information using LDAP. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as nslookup.exe can be abused by malware like Qakbot to gather critical domain details, such as SRV records and server names. If confirmed malicious, this behavior could allow attackers to map the network, identify key servers, and plan further attacks, potentially leading to data exfiltration or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = dministrator may execute this commandline tool for auditing purposes. Filter as needed. @@ -14988,7 +14764,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the execution of qwinsta.exe executable in Windows Operating System. This Windows executable file can display information about sessions on a remote desktop session host server. The information includes servername, sessionname, username and many more. This tool is being abused of Qakbot malware to gather information to the targeted or compromised host that will be send back to its Command And Control server. +explanation = The following analytic detects the execution of "qwinsta.exe" on a Windows operating system. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. The "qwinsta.exe" tool is significant because it can display detailed session information on a remote desktop session host server. This behavior is noteworthy as it is commonly abused by Qakbot malware to gather system information and send it back to its Command and Control (C2) server. If confirmed malicious, this activity could lead to unauthorized data exfiltration and further compromise of the host. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrator may execute this commandline tool for auditing purposes. Filter as needed. @@ -14998,7 +14774,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic will assist with identifying new .sys files introduced in the environment. This query is meant to identify sys file creates on disk. There will be noise, but reducing common process names or applications should help to limit any volume. The idea is to identify new sys files written to disk and identify them before they're added as a new kernel mode driver. +explanation = The following analytic detects the creation of new .sys files on disk. It leverages the Endpoint.Filesystem data model to identify and log instances where .sys files are written to the filesystem. This activity is significant because .sys files are often used as kernel mode drivers, and their unauthorized creation can indicate malicious activity such as rootkit installation. If confirmed malicious, this could allow an attacker to gain kernel-level access, leading to full system compromise, persistent control, and the ability to bypass security mechanisms. how_to_implement = To successfully implement this search you need to be ingesting information on files from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. In addition, filtering may occur by adding NOT (Filesystem.file_path IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", "system32\*")). This will level out the noise generated to potentally lead to generating notables. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.AE"]} known_false_positives = False positives will be present. Filter as needed. @@ -15008,7 +14784,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies Windows commandline to logoff a windows host machine. This technique was seen in several APT, RAT like dcrat and other commodity malware to shutdown the machine to add more impact, interrupt access, aid destruction of the system like wiping disk or inhibit system recovery. This TTP is a good pivot to check why application trigger this commandline which is not so common way to logoff a machine. +explanation = The following analytic detects the execution of the Windows command line to log off a host machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on processes involving `shutdown.exe` with specific parameters. This activity is significant as it is often associated with Advanced Persistent Threats (APTs) and Remote Access Trojans (RATs) like dcrat, which use this technique to disrupt operations, aid in system destruction, or inhibit recovery. If confirmed malicious, this could lead to system downtime, data loss, or hindered incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]} known_false_positives = Administrator may execute this commandline to trigger shutdown, logoff or restart the host machine. @@ -15018,7 +14794,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process command line that retrieves dns reply information using Windows OS built-in tool IPConfig. This technique is being abused by threat actors, adversaries and post exploitation tools like WINPEAS to retrieve DNS information for the targeted host. This IPConfig parameter (/displaydns) can show dns server resource record, record name, record type, time to live data length and dns reply. This hunting detection can be a good pivot to check which process is executing this command line in specific host system that may lead to malware or adversaries gathering network information. +explanation = The following analytic identifies the execution of the "ipconfig /displaydns" command, which retrieves DNS reply information using the built-in Windows tool IPConfig. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line executions. Monitoring this activity is significant as threat actors and post-exploitation tools like WINPEAS often abuse this command to gather network information. If confirmed malicious, this activity could allow attackers to map the network, identify DNS servers, and potentially facilitate further network-based attacks or lateral movement. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -15028,7 +14804,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS built-in tool netsh.exe to show state, configuration and profile of host firewall. This tool is being used or abused by several adversaries or even post exploitation tool to bypass firewall rules or to discover firewall settings. This hunting detection can help to detect a possible suspicious usage of netsh.exe to retrieve firewall settings or even firewall wlan profile. We recommend checking which parent process and process name execute this command. Also check the process file path for verification that may lead to further TTP's threat behavior. +explanation = The following analytic detects the execution of the Windows built-in tool netsh.exe to display the state, configuration, and profile of the host firewall. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. Monitoring this activity is crucial as netsh.exe can be used by adversaries to bypass firewall rules or discover firewall settings. If confirmed malicious, this activity could allow attackers to manipulate firewall configurations, potentially leading to unauthorized network access or data exfiltration. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]} known_false_positives = network administrator can use this tool for auditing process. @@ -15038,7 +14814,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies Windows commandline to reboot a windows host machine. This technique was seen in several APT, RAT like dcrat and other commodity malware to shutdown the machine to add more impact, interrupt access, aid destruction of the system like wiping disk or inhibit system recovery. This TTP is a good pivot to check why application trigger this commandline which is not so common way to reboot a machine. Compare to shutdown and logoff shutdown.exe feature, reboot seen in some automation script like ansible to reboot the machine. +explanation = The following analytic identifies the execution of the Windows command line to reboot a host machine using "shutdown.exe" with specific parameters. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it is often associated with advanced persistent threats (APTs) and remote access trojans (RATs) like dcrat, which may use system reboots to disrupt operations, aid in system destruction, or inhibit recovery. If confirmed malicious, this could lead to system downtime, data loss, or hindered incident response efforts. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]} known_false_positives = Administrator may execute this commandline to trigger shutdown or restart the host machine. @@ -15058,7 +14834,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This detection rule is designed to identify the execution of the Windows shutdown command via command line interface. The shutdown command can be utilized by system administrators to properly halt, power off, or reboot a computer. However, in a security context, attackers who have gained unauthorized access to a system may also use this command in an effort to erase tracks, or to cause disruption and denial of service. In some instances, they might execute the shutdown command after installing a backdoor, to force the system to restart, ensuring that changes take effect or evading detection by security tools. Monitoring for the use of the Windows shutdown command, especially in conjunction with other unusual or unauthorized activities, can be an important part of identifying malicious behavior within a network. It is advised that security professionals analyze the context in which the shutdown command is being executed to differentiate between legitimate administrative functions and potentially malicious activity. +explanation = The following analytic identifies the execution of the Windows shutdown command via the command line interface. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because attackers may use the shutdown command to erase tracks, cause disruption, or ensure changes take effect after installing backdoors. If confirmed malicious, this activity could lead to system downtime, denial of service, or evasion of security tools, impacting the overall security posture of the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]} known_false_positives = Administrator may execute this commandline to trigger shutdown or restart the host machine. @@ -15068,7 +14844,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies DCRat delay time tactics using w32tm. This technique was seen in DCRAT malware where it uses stripchart function of w32tm.exe application to delay the execution of its payload like c2 communication , beaconing and execution. This anomaly detection may help the analyst to check other possible event like the process who execute this command that may lead to DCRat attack. +explanation = The following analytic identifies the use of the w32tm.exe utility with the /stripchart function, which is indicative of DCRat malware delaying its payload execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line arguments used by w32tm.exe. This activity is significant as it may indicate an attempt to evade detection by delaying malicious actions such as C2 communication and beaconing. If confirmed malicious, this behavior could allow an attacker to maintain persistence and execute further malicious activities undetected. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1124"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -15078,7 +14854,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a process execution of Windows OS quser.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to display or gather information about user sessions on a Remote Desktop Session Host server. This command can find out if a specific user is logged on to a specific Remote Desktop Session Host server. This tool can retrieve some RDP information that can be use by attacker for further attack like Name of the user , Name of the session on the Remote Desktop Session Host server, Session ID, State of the session (active or disconnected), Idle time (the number of minutes since the last keystroke or mouse movement at the session) and Date and time the user logged on. +explanation = The following analytic detects the execution of the Windows OS tool quser.exe, commonly used to gather information about user sessions on a Remote Desktop Session Host server. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. Monitoring this activity is crucial as quser.exe is often abused by post-exploitation tools like winpeas, used in ransomware attacks to enumerate user sessions. If confirmed malicious, attackers could leverage this information to further compromise the system, maintain persistence, or escalate privileges. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = network administrator can use this command tool to audit RDP access of user in specific network or host. @@ -15088,7 +14864,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the execution of `whoami.exe` with /priv parameter. This whoami command is used to display or shows the privileges assigned to the current user account. This hunting query can be a good pivot start to look for suspicious usage of whoami application that might related to a malware or adversaries. +explanation = The following analytic detects the execution of `whoami.exe` with the `/priv` parameter, which displays the privileges assigned to the current user account. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an adversary attempting to enumerate user privileges, a common step in the reconnaissance phase of an attack. If confirmed malicious, this could lead to privilege escalation or further exploitation within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. Filter as needed. @@ -15098,7 +14874,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to detect a suspicious process terminating Lsass process. Lsass process is known to be a critical process that is responsible for enforcing security policy system. This process was commonly targetted by threat actor or red teamer to gain privilege escalation or persistence in the targeted machine because it handles credentials of the logon users. In this analytic we tried to detect a suspicious process having a granted access PROCESS_TERMINATE to lsass process to modify or delete protected registrys. This technique was seen in doublezero malware that tries to wipe files and registry in compromised hosts. This anomaly detection can be a good pivot of incident response for possible credential dumping or evading security policy in a host or network environment. +explanation = The following analytic detects a suspicious process attempting to terminate the Lsass.exe process. It leverages Sysmon EventCode 10 logs to identify processes granted PROCESS_TERMINATE access to Lsass.exe. This activity is significant because Lsass.exe is a critical process responsible for enforcing security policies and handling user credentials. If confirmed malicious, this behavior could indicate an attempt to perform credential dumping, privilege escalation, or evasion of security policies, potentially leading to unauthorized access and persistence within the environment. how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = unknown @@ -15108,7 +14884,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect potentially malicious processes that initiate a ping delay using an invalid IP address. This evasion technique was observed in NJRAT, where the malware employed ping commands as a means to introduce a time delay before self-deletion on the compromised host. Identifying this (TTP) behavior can serve as a valuable indicator for detecting NJRAT infections or other malware that employ time delays as evasion tactics. +explanation = The following analytic detects potentially malicious processes that initiate a ping delay using an invalid IP address. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "ping 0 -n". This behavior is significant as it is commonly used by malware like NJRAT to introduce time delays for evasion tactics, such as delaying self-deletion. If confirmed malicious, this activity could indicate an active infection attempting to evade detection, potentially leading to further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497", "T1497.003"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15118,7 +14894,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is designed to detect potentially suspicious batch files that leverage choice.exe as a delay tactic. This technique, observed in the SnakeKeylogger malware, is utilized for time delays or 'Sleep' commands in its code execution or before the deletion of its copies on compromised hosts. Detecting this anomaly serves as a valuable pivot to uncover suspicious processes attempting to evade detection through time-based evasion techniques. +explanation = The following analytic detects the use of choice.exe in batch files as a delay tactic, a technique observed in SnakeKeylogger malware. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential time-based evasion techniques used by malware to avoid detection. If confirmed malicious, this behavior could allow attackers to execute code stealthily, delete malicious files, and persist on compromised hosts, making it crucial for SOC analysts to investigate promptly. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497.003", "T1497"], "nist": ["DE.AE"]} known_false_positives = administrator may use choice.exe to allow user to choose from and indexes of choices from a batch script. @@ -15128,7 +14904,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when an executable known for User Account Control bypass exploitation, spawns a child process in user controlled location or a command shell executable (cmd, powershell, etc). This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges. +explanation = The following analytic detects when an executable known for User Account Control (UAC) bypass exploitation spawns a child process in a user-controlled location or a command shell executable (e.g., cmd.exe, powershell.exe). This detection leverages Sysmon Event ID 1 data, focusing on high or system integrity level processes with specific parent-child process relationships. This activity is significant as it may indicate an attacker has successfully used a UAC bypass exploit to escalate privileges. If confirmed malicious, this could allow the attacker to execute arbitrary commands with elevated privileges, potentially compromising the entire system. how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548", "T1548.002"], "nist": ["DE.CM"]} known_false_positives = Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques. @@ -15138,7 +14914,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when a process spawns an executable known for User Account Control bypass exploitation, and then monitors for any subsequent child processes that are above the integrity level of the original spawning process. This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges. +explanation = The following analytic detects when a process spawns an executable known for User Account Control (UAC) bypass exploitation and subsequently monitors for any child processes with a higher integrity level than the original process. This detection leverages Sysmon Event ID 1 data, focusing on process integrity levels and known UAC bypass executables. This activity is significant as it may indicate an attacker has successfully used a UAC bypass exploit to escalate privileges. If confirmed malicious, the attacker could gain elevated privileges, potentially leading to further system compromise and persistent access. how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548", "T1548.002"], "nist": ["DE.CM"]} known_false_positives = Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques. @@ -15148,7 +14924,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a suspicious query on outlook credentials registry in Windows OS registry. typically refers to user profiles associated with Microsoft Outlook. Within this key, Outlook stores configuration settings, including account information such as email addresses, server details, and authentication credentials. Accessing or modifying this registry key can potentially compromise users' email security, making it a target for attackers seeking to steal sensitive information or execute unauthorized actions within Outlook. This anomaly detection is a good pivot to catch possible Trojan Stealer or RAT that tries to steal sensitive information to its targeted host. +explanation = The following analytic detects unauthorized access to Outlook credentials stored in the Windows registry. It leverages Windows Security Event logs, specifically EventCode 4663, to identify access attempts to registry paths associated with Outlook profiles. This activity is significant as it may indicate attempts to steal sensitive email credentials, which could lead to unauthorized access to email accounts. If confirmed malicious, this could allow attackers to exfiltrate sensitive information, impersonate users, or execute further unauthorized actions within Outlook, posing a significant security risk. how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552"], "nist": ["DE.AE"]} known_false_positives = third party software may access this outlook registry. @@ -15158,17 +14934,27 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic focuses on detecting potentially malicious unsigned DLLs created in either the c:\windows\system32 or c:\windows\syswow64 folders. This particular technique was observed in the context of the Warzone (Ave Maria) RAT, where it employed a method known as DLL hijacking (dll-side-loading) by dropping the "dismcore.dll" to achieve privilege escalation. DLL hijacking is a stealthy attack technique used by cybercriminals to exploit the way Windows searches and loads DLLs. By placing a malicious DLL with the same name as one that a legitimate application is expected to load, the attacker can gain unauthorized access and execute malicious code. In the case of Warzone RAT (Ave Maria), the dropped "dismcore.dll" was intended to deceive the system into loading the rogue DLL instead of the legitimate version, thereby granting the malware elevated privileges and enabling further compromise of the target system. Detecting such suspicious DLLs is crucial in preventing privilege escalation attacks and other potential security breaches. Regular security assessments, thorough monitoring, and implementing security best practices are essential in safeguarding systems from such threats. +explanation = The following analytic detects the creation of potentially malicious unsigned DLLs in the c:\windows\system32 or c:\windows\syswow64 folders. It leverages Sysmon EventCode 7 logs to identify unsigned DLLs with unavailable signatures loaded in these critical directories. This activity is significant as it may indicate a DLL hijacking attempt, a technique used by attackers to gain unauthorized access and execute malicious code. If confirmed malicious, this could lead to privilege escalation, allowing the attacker to gain elevated privileges and further compromise the target system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002"], "nist": ["DE.AE"]} known_false_positives = It is possible some Administrative utilities will load dismcore.dll outside of normal system paths, filter as needed. providing_technologies = ["Microsoft Sysmon"] +[savedsearch://ESCU - Windows Unsigned DLL Side-Loading In Same Process Path - Rule] +type = detection +asset_type = Endpoint +confidence = medium +explanation = This detection identifies unsigned DLLs loaded through DLL side-loading with same file path with the process loaded the DLL, a technique observed in DarkGate malware. This detection monitors DLL loading, verifies signatures, and flags unsigned DLLs. Suspicious file paths and known executable associations are checked. Detecting such suspicious DLLs is crucial in preventing privilege escalation attacks and other potential security breaches. Regular security assessments, thorough monitoring, and implementing security best practices are essential in safeguarding systems from such threats. +how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. +annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]} +known_false_positives = unknown +providing_technologies = ["Microsoft Sysmon"] + [savedsearch://ESCU - Windows Unsigned MS DLL Side-Loading - Rule] type = detection asset_type = Endpoint confidence = medium -explanation = The following analysis identifies potential DLL side-loading instances involving unsigned DLLs with a company detail signature mimicking Microsoft. This technique is frequently exploited by adversaries to execute malicious code automatically by running a legitimate process. The analytics involves searching Sysmon logs for Event Code 7, where both the `Image` and `ImageLoaded` paths do not match system directories (`system32`, `syswow64`, and `programfiles`). Additionally, it verifies whether the loaded DLL is signed and checks if the folder paths of the `Image` and `ImageLoaded` are identical. This anomaly detection mechanism serves as a valuable indicator for identifying suspicious processes that load unsigned DLLs. Add other paths based on org hunting. +explanation = The following analytic identifies potential DLL side-loading instances involving unsigned DLLs mimicking Microsoft signatures. It detects this activity by analyzing Sysmon logs for Event Code 7, where both the `Image` and `ImageLoaded` paths do not match system directories like `system32`, `syswow64`, and `programfiles`. This behavior is significant as adversaries often exploit DLL side-loading to execute malicious code via legitimate processes. If confirmed malicious, this activity could allow attackers to execute arbitrary code, potentially leading to privilege escalation, persistence, and unauthorized access to sensitive information. how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives. The analytic can be modified to include additional known good paths for vcruntime140.dll to further reduce false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1547"], "nist": ["DE.AE"]} known_false_positives = False positives are possible if legitimate processes are loading vcruntime140.dll from non-standard directories. It is recommended to investigate the context of the process loading vcruntime140.dll to determine if it is malicious or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives. @@ -15178,10 +14964,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with multiple disabled domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack against disabled users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code `0x12` stands for `clients credentials have been revoked` (account disabled, expired or locked out). \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate with multiple disabled domain users using the Kerberos protocol. It leverages EventCode 4768, which is generated when the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT) and detects failure code `0x12` (credentials revoked). This behavior is significant as it may indicate a Password Spraying attack targeting disabled accounts, potentially leading to initial access or privilege escalation. If confirmed malicious, attackers could gain unauthorized access or elevate privileges within the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple disabled domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems missconfigured systems. @@ -15191,10 +14974,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with multiple invalid domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` (the attempted user is not a valid domain user). \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate with multiple invalid domain users using the Kerberos protocol. It leverages Event ID 4768, which is generated when the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT) and detects failure code 0x6, indicating the user is not found in the Kerberos database. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access and potential privilege escalation within the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems and missconfigured systems. @@ -15204,10 +14984,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with multiple invalid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC0000064 stands for `The username you typed does not exist` (the attempted user is a legitimate domain user). \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate with multiple invalid users using the NTLM protocol. It leverages EventCode 4776 and calculates the standard deviation for each host, using the 3-sigma rule to detect anomalies. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access or privilege escalation, posing a significant threat to the Active Directory environment. This detection is focused on domain controllers. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts. @@ -15217,10 +14994,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source user failing to authenticate with multiple users using explicit credentials on a host. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4648 is generated when a process attempts an account logon by explicitly specifying that accounts credentials. This event generates on domain controllers, member servers, and workstations. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source account, attempted user accounts and the endpoint were the behavior was identified. +explanation = The following analytic identifies a source user failing to authenticate with multiple users using explicit credentials on a host. It leverages Windows Event Code 4648 and calculates the standard deviation for each host, using the 3-sigma rule to detect anomalies. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access, privilege escalation, or further compromise of the Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A source user failing attempting to authenticate multiple users on a host is not a common behavior for regular systems. Some applications, however, may exhibit this behavior in which case sets of users hosts can be added to an allow list. Possible false positive scenarios include systems where several users connect to like Mail servers, identity providers, remote desktop services, Citrix, etc. @@ -15230,10 +15004,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with multiple valid users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Event 4771 is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted user is a legitimate domain user). \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate multiple valid users using the Kerberos protocol, potentially indicating a Password Spraying attack. It leverages Event 4771, which is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT) due to a wrong password (failure code 0x18). This detection uses statistical analysis, specifically the 3-sigma rule, to identify unusual authentication failures. If confirmed malicious, this activity could allow an attacker to gain initial access or elevate privileges within an Active Directory environment. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, missconfigured systems and multi-user systems like Citrix farms. @@ -15243,10 +15014,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source process name failing to authenticate with multiple users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4625 generates on domain controllers, member servers, and workstations when an account fails to logon. Logon Type 2 describes an iteractive logon attempt. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. This could be a domain controller as well as a member server or workstation. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts. +explanation = The following analytic identifies a source process failing to authenticate multiple users, potentially indicating a Password Spraying attack. It leverages Windows Event 4625, which logs failed logon attempts, and uses statistical analysis to detect anomalies. This activity is significant as it may represent an adversary attempting to gain initial access or elevate privileges within an Active Directory environment. If confirmed malicious, the attacker could compromise multiple accounts, leading to unauthorized access, data exfiltration, or further lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A process failing to authenticate with multiple users is not a common behavior for legitimate user sessions. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. @@ -15256,10 +15024,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies one source endpoint failing to authenticate with multiple valid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted user is a legitimate domain user). \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on domain controllers, not on member servers or workstations. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts. +explanation = The following analytic identifies a source endpoint failing to authenticate multiple valid users using the NTLM protocol, potentially indicating a Password Spraying attack. It leverages Event 4776 from Domain Controllers, calculating the standard deviation for each host and applying the 3-sigma rule to detect anomalies. This activity is significant as it may represent an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, the attacker could compromise multiple accounts, leading to unauthorized access and potential lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts. @@ -15269,10 +15034,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a source host failing to authenticate against a remote host with multiple users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4625 documents each and every failed attempt to logon to the local computer. This event generates on domain controllers, member servers, and workstations. Logon Type 3 describes an remote authentication attempt. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will trigger on the host that is the target of the password spraying attack. This could be a domain controller as well as a member server or workstation. \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts. +explanation = The following analytic identifies a source host failing to authenticate against a remote host with multiple users, potentially indicating a Password Spraying attack. It leverages Windows Event 4625 (failed logon attempts) and Logon Type 3 (remote authentication) to detect this behavior. This activity is significant as it may represent an adversary attempting to gain initial access or elevate privileges within an Active Directory environment. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and further compromise of the network. how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]} known_false_positives = A host failing to authenticate with multiple valid users against a remote host is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, missconfigyred systems, etc. @@ -15282,7 +15044,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = This analytic will identify suspicious creation of URL shortcut link files. This technique was seen in CHAOS ransomware where it will drop this .url link file in %startup% folder that contains the path of its malicious dropped file to execute upon the reboot of the targeted host. The creation of this file can be created by a normal application or software but it is a good practice to verify this type of file specially the resource it tries to execute which is commonly a website. +explanation = The following analytic detects the creation of suspicious URL shortcut link files, often used by malware like CHAOS ransomware. It leverages the Endpoint.Filesystem datamodel to identify .url files created outside standard directories, such as Program Files. This activity is significant as it may indicate an attempt to execute malicious code upon system reboot. If confirmed malicious, this could allow an attacker to achieve persistence and execute harmful payloads, potentially leading to further system compromise and data loss. how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.002", "T1204"], "nist": ["DE.CM"]} known_false_positives = Administrators may allow creation of script or exe in this path. @@ -15292,7 +15054,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies net.exe updating user account policies for password requirement with non-expiring password. This technique was seen in several adversaries and malware like Azorult to maintain the foothold (persistence), gaining privilege escalation, defense evasion and possible for lateral movement for specific users or created user account on the targeted host. This TTP detections is a good pivot to see further what other events that users executes on the machines. +explanation = The following analytic detects the use of net.exe to update user account policies to set passwords as non-expiring. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "/maxpwage:unlimited". This activity is significant as it can indicate an attempt to maintain persistence, escalate privileges, evade defenses, or facilitate lateral movement. If confirmed malicious, this behavior could allow an attacker to maintain long-term access to compromised accounts, potentially leading to further exploitation and unauthorized access to sensitive information. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]} known_false_positives = This behavior is not commonly seen in production environment and not advisable, filter as needed. @@ -15302,7 +15064,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic leverages Sysmon, a powerful system monitoring and logging tool, to pinpoint instances of the 3CXDesktopApp.exe with a FileVersion of 18.12.x.Recently, 3CX has discovered a vulnerability specifically in versions 18.12.407 and 18.12.416 of the desktop app. +explanation = The following analytic detects instances of the 3CXDesktopApp.exe with a FileVersion of 18.12.x, leveraging Sysmon logs. This detection focuses on identifying vulnerable versions 18.12.407 and 18.12.416 of the 3CX desktop app. Monitoring this activity is crucial as these specific versions have known vulnerabilities that could be exploited by attackers. If confirmed malicious, exploitation of this vulnerability could lead to unauthorized access, code execution, or further compromise of the affected system, posing significant security risks. how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on file version, modify the analytic to only look for version between 18.12.407 and 18.12.416 as needed. @@ -15312,7 +15074,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes a known list of vulnerable Windows drivers to help defenders find potential persistence or privelege escalation via a vulnerable driver. This analytic uses Sysmon EventCode 6, driver loading. A known gap with this lookup is that it does not use the hash or known signer of the vulnerable driver therefore it is up to the defender to identify version and signing info and confirm it is a vulnerable driver. +explanation = The following analytic detects the loading of known vulnerable Windows drivers, which may indicate potential persistence or privilege escalation attempts. It leverages Sysmon EventCode 6 to identify driver loading events and cross-references them with a list of vulnerable drivers. This activity is significant as attackers often exploit vulnerable drivers to gain elevated privileges or maintain persistence on a system. If confirmed malicious, this could allow attackers to execute arbitrary code with high privileges, leading to further system compromise and potential data exfiltration. how_to_implement = Sysmon collects driver loads via EventID 6, however you may modify the query to utilize this lookup to identify potentially persistent drivers that are known to be vulnerable. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543.003"], "nist": ["DE.AE"]} known_false_positives = False positives will be present. Drill down into the driver further by version number and cross reference by signer. Review the reference material in the lookup. In addition, modify the query to look within specific paths, which will remove a lot of "normal" drivers. @@ -15322,7 +15084,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies instances of the WinDBG process spawning AutoIt3. This behavior may indicate malicious activity as AutoIt3 is often used by threat actors for scripting malicious automation. The search specifically looks for instances where the parent process name is 'windbg.exe' and the process name is 'autoit3.exe' or 'autoit*.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event. +explanation = The following analytic identifies instances of the WinDBG process spawning AutoIt3. This behavior is detected by monitoring endpoint telemetry for processes where 'windbg.exe' is the parent process and 'autoit3.exe' or similar is the child process. This activity is significant because AutoIt3 is frequently used by threat actors for scripting malicious automation, potentially indicating an ongoing attack. If confirmed malicious, this could allow attackers to automate tasks, execute arbitrary code, and further compromise the system, leading to data exfiltration or additional malware deployment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} known_false_positives = False positives will only be present if the WinDBG process legitimately spawns AutoIt3. Filter as needed. @@ -15332,9 +15094,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic is designed to detect anomalous behavior associated with the BlackLotus Campaign, a sophisticated bootkit attack reported by ESET and further investigated in a blog by Microsoft, which provided hunting queries for security analysts. The primary focus of this analytic is to identify instances of Winlogon.exe, a critical Windows process, connecting to public IP space, which is indicative of potential malicious activity.\ The BlackLotus Campaign is a bootkit-based attack that compromises system integrity by infecting the Master Boot Record (MBR) and Volume Boot Record (VBR). This malware variant can bypass traditional security measures, load before the operating system, and maintain persistence on the target system. \ -Winlogon.exe is a critical Windows process responsible for managing user logon and logoff processes. Under normal circumstances, Winlogon.exe should not be connecting to public IP addresses. However, if it does, it may indicate that the process has been compromised as part of the BlackLotus Campaign or another malicious operation. \ -This analytic monitors network connections made by Winlogon.exe and triggers an alert if it detects connections to public IP space. By identifying such anomalous behavior, security analysts can investigate further and respond swiftly to potential threats. +explanation = The following analytic detects instances of Winlogon.exe, a critical Windows process, connecting to public IP addresses. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on network connections made by Winlogon.exe. Under normal circumstances, Winlogon.exe should not connect to public IPs, and such activity may indicate a compromise, such as the BlackLotus bootkit attack. This detection is significant as it highlights potential system integrity breaches. If confirmed malicious, attackers could maintain persistence, bypass security measures, and compromise the system at a fundamental level. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.003"], "nist": ["DE.AE"]} known_false_positives = False positives will be present and filtering will be required. Legitimate IPs will be present and need to be filtered. @@ -15344,7 +15104,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies a possible wmi token impersonation activities in a process or command. This technique was seen in Qakbot malware where it will execute a vbscript code contains wmi impersonation object to gain privilege escalation or as defense evasion. This Anomaly detection looks for wmiprvse.exe SourceImage having a duplicate handle or full granted access in a target process. +explanation = The following analytic detects potential WMI token impersonation activities in a process or command. It leverages Sysmon EventCode 10 to identify instances where `wmiprvse.exe` has a duplicate handle or full granted access in a target process. This behavior is significant as it is commonly used by malware like Qakbot for privilege escalation or defense evasion. If confirmed malicious, this activity could allow an attacker to gain elevated privileges, evade defenses, and maintain persistence within the environment. how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]} known_false_positives = administrator may execute impersonate wmi object script for auditing. Filter is needed. @@ -15354,7 +15114,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious process command line, where WMI is performing an event query looking for running processes or running services. This technique is commonly found where the adversary will identify services and system information on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic identifies suspicious WMI command lines querying for running processes or services. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific process and command-line events. This activity is significant as adversaries often use WMI to gather system information and identify services on compromised machines. If confirmed malicious, this behavior could allow attackers to map out the system, identify critical services, and plan further attacks, potentially leading to privilege escalation or persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]} known_false_positives = netowrk administrator or IT may execute this command for auditing processes and services. @@ -15364,7 +15124,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic is to look for wmi commandlines to execute or create process. This technique was used by adversaries or threat actor to execute their malicious payload in local or remote host. This hunting query is a good pivot to start to look further which process trigger the wmi or what process it execute locally or remotely. +explanation = The following analytic detects the execution of WMI command lines used to create or execute processes. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line events that include specific keywords like "process," "call," and "create." This activity is significant because adversaries often use WMI to execute malicious payloads on local or remote hosts, potentially bypassing traditional security controls. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to organizational security. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]} known_false_positives = Administrators may execute this command for testing or auditing. @@ -15374,10 +15134,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following query utilizes Windows Security EventCode 4698, indicating 'a scheduled task was created', to identify potentially suspicious tasks. These tasks may be registered on Windows through either schtasks.exe or TaskService, and are set up to execute a command with a native Windows shell such as PowerShell, Cmd, Wscript, or Cscript. \ -The search will return the initial and final times the task was registered, along with details like the 'Command' set to be executed, 'Task Name', 'Author', whether it's 'Enabled', and if it is 'Hidden'. \ -Schtasks.exe is typically found in C:\Windows\system32 and C:\Windows\syswow64. The DLL 'taskschd.dll' is loaded when either schtasks.exe or TaskService is launched. If this DLL is found loaded by another process, it's possible that a scheduled task is being registered within the context of that process in memory. \ -During triage, it's essential to identify the source of the scheduled task. Was it registered via schtasks.exe or TaskService? Review the job that was created and the command set to be executed. It's also recommended to capture and review any artifacts on disk, and identify any parallel processes within the same timeframe to locate the source. +explanation = The following analytic detects the creation of scheduled tasks designed to execute commands using native Windows shells like PowerShell, Cmd, Wscript, or Cscript. It leverages Windows Security EventCode 4698 to identify when such tasks are registered. This activity is significant as it may indicate an attempt to establish persistence or execute malicious commands on a system. If confirmed malicious, this could allow an attacker to maintain access, execute arbitrary code, or escalate privileges, posing a severe threat to the environment. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = False positives are possible if legitimate applications are allowed to register tasks that call a shell to be spawned. Filter as needed based on command-line or processes that are used legitimately. @@ -15387,10 +15144,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic utilizes Windows Security EventCode 4698, which indicates the creation of a scheduled task on a Windows system. The purpose of this query is to identify suspicious tasks that have been registered using either schtasks.exe or TaskService and involve executing a command from a user-writable file path. \ -When this analytic is triggered, it provides information such as the first and last registration time of the task, the command to be executed, the task name, author, and whether it is set as hidden or not. It is worth noting that schtasks.exe is commonly located in C:\Windows\system32 and C:\Windows\syswow64, and it loads the taskschd.dll DLL when launched. If this DLL is loaded by another process, it suggests that a scheduled task may be registered within that process's context in memory. \ -During the triage process, it is essential to identify the source of the scheduled task creation, whether it was initiated through schtasks.exe or TaskService. The analyst should review the task that was created, including the command to be executed. Additionally, any artifacts on disk related to the task should be captured and analyzed. It is also recommended to identify any parallel processes that occurred within the same timeframe to determine the source of the task creation. \ -By conducting this triage process, security analysts can gain insights into potentiallymalicious or suspicious scheduled tasks, helping them identify the source and assess the impact of the task. This analytic is valuable for a Security Operations Center (SOC) as it can detect unauthorized or suspicious activity that could indicate an attacker's attempt to establish persistence or execute unauthorized commands on the system. +explanation = The following analytic detects the creation of scheduled tasks within user-writable paths using Windows Security EventCode 4698. It identifies tasks registered via schtasks.exe or TaskService that execute commands from directories like Public, ProgramData, Temp, and AppData. This behavior is significant as it may indicate an attempt to establish persistence or execute unauthorized commands. If confirmed malicious, an attacker could maintain long-term access, escalate privileges, or execute arbitrary code, posing a severe threat to system integrity and security. how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]} known_false_positives = False positives are possible if legitimate applications are allowed to register tasks in public paths. Filter as needed based on paths that are used legitimately. @@ -15400,11 +15154,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic aims to identify suspicious tasks that have been registered and executed in Windows using EventID 200 (action run) and 201 (action completed) from the Windows Task Scheduler logs. This analytic helps detect evasive techniques used to register tasks on Windows systems. It is recommended to filter the results based on the ActionName field by specifying specific paths that are not commonly used in your environment. \ -After implementing this analytic, it is important to review parallel events related to the scheduled tasks. EventID 106 will be generated when a new task is created, but it does not necessarily mean that the task has been executed. Analysts should capture any files on disk associated with the task and perform further analysis. \ -To implement this analytic, Task Scheduler logs must be collected. This can be done by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] in the inputs.conf file and setting renderXml=false. It is worth noting that not translating the logs into XML may require specific extraction of items from the Message field. \ -False positives are expected with this analytic, so it is important to filter the results based on the paths or specific keywords of interest in the ActionName field to reduce noise. \ -Identifying and analyzing scheduled tasks that have been executed is crucial for a Security Operations Center (SOC) as it helps detect potentially malicious or unauthorized activities on Windows systems. By capturing and investigating the associated events, analysts can uncover signs of persistence mechanisms, unauthorized code execution, or suspicious behaviors. The impact of a true positive could range from unauthorized access to data exfiltration or the execution of malicious payloads. +explanation = The following analytic detects the execution of tasks registered in Windows Task Scheduler by monitoring EventID 200 (action run) and 201 (action completed) from the Task Scheduler logs. This detection leverages Task Scheduler logs to identify potentially suspicious or unauthorized task executions. Monitoring these events is significant for a SOC as it helps uncover evasive techniques used for persistence, unauthorized code execution, or other malicious activities. If confirmed malicious, this activity could lead to unauthorized access, data exfiltration, or the execution of harmful payloads, posing a significant threat to the environment. how_to_implement = Task Scheduler logs are required to be collected. Enable logging with inputs.conf by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] and renderXml=false. Note, not translating it in XML may require a proper extraction of specific items in the Message. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.005"], "nist": ["DE.AE"]} known_false_positives = False positives will be present. Filter based on ActionName paths or specify keywords of interest. @@ -15414,7 +15164,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies winhlp32.exe, found natively in `c:\windows\`, spawning a child process that loads a file out of appdata, programdata, or temp. Winhlp32.exe has a rocky past in that multiple vulnerabilities were found and added to MetaSploit. WinHlp32.exe is required to display 32-bit Help files that have the ".hlp" file name extension. This particular instance is related to a Remcos sample where dynwrapx.dll is added to the registry under inprocserver32, and later module loaded by winhlp32.exe to spawn wscript.exe and load a vbs or file from disk. During triage, review parallel processes to identify further suspicious behavior. Review module loads for unsuspecting unsigned modules. Capture any file modifications and analyze. +explanation = The following analytic detects winhlp32.exe spawning a child process that loads a file from appdata, programdata, or temp directories. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events. This activity is significant because winhlp32.exe has known vulnerabilities and can be exploited to execute malicious code. If confirmed malicious, an attacker could use this technique to execute arbitrary scripts, escalate privileges, or maintain persistence within the environment. Analysts should review parallel processes, module loads, and file modifications for further suspicious behavior. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as winhlp32.exe is typically not used with the latest flavors of Windows OS. However, filter as needed. @@ -15424,7 +15174,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the execution of Windows shell processes initiated by WinRAR, specifically looking for instances where WinRAR spawns processes like "cmd.exe", "powershell.exe", "certutil.exe", "mshta.exe", or "bitsadmin.exe". This behavior is worth identifying for a Security Operations Center (SOC) because it is indicative of a spoofing attack exploit, such as the one associated with WinRAR CVE-2023-38831. Cybercriminals exploited this vulnerability to craft ZIP archives with spoofed extensions, hiding the launch of malicious scripts within an archive. When a victim opened the specially crafted archive, it executed the malware, leading to unauthorized access to their broker accounts and enabling the cybercriminals to perform illicit financial transactions and withdraw funds. If a true positive is found, it suggests that an attacker has successfully exploited the vulnerability to execute malicious scripts, leading to unauthorized access, financial loss, and potentially the delivery of additional malicious payloads. The impact of the attack could be severe, involving financial loss, unauthorized access to sensitive accounts, and the potential for further malicious activity such as data theft or ransomware attacks. +explanation = The following analytic detects the execution of Windows shell processes initiated by WinRAR, such as "cmd.exe", "powershell.exe", "certutil.exe", "mshta.exe", or "bitsadmin.exe". This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and parent process relationships. This activity is significant because it may indicate exploitation of the WinRAR CVE-2023-38831 vulnerability, where malicious scripts are executed from spoofed ZIP archives. If confirmed malicious, this could lead to unauthorized access, financial loss, and further malicious activities like data theft or ransomware attacks. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} known_false_positives = Be aware of potential false positives - legitimate uses of WinRAR and the listed processes in your environment may cause benign activities to be flagged. Upon triage, review the destination, user, parent process, and process name involved in the flagged activity. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. @@ -15434,7 +15184,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious processes spawning from WinRM (wsmprovhost.exe). This analytic is related to potential exploitation of CVE-2021-31166. which is a kernel-mode device driver http.sys vulnerability. Current proof of concept code will blue-screen the operating system. However, http.sys used by many different Windows processes, including WinRM. In this case, identifying suspicious process create (child processes) from `wsmprovhost.exe` is what this analytic is identifying. +explanation = The following analytic detects suspicious processes spawned by WinRM (wsmprovhost.exe). It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific child processes like cmd.exe, powershell.exe, and others. This activity is significant as it may indicate exploitation attempts of vulnerabilities like CVE-2021-31166, which could lead to system instability or compromise. If confirmed malicious, attackers could execute arbitrary commands, escalate privileges, or maintain persistence, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = Unknown. Add new processes or filter as needed. It is possible system management software may spawn processes from `wsmprovhost.exe`. @@ -15444,7 +15194,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies Microsoft Word spawning `cmd.exe`. Typically, this is not common behavior and not default with winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). Cmd.exe spawning from winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line will indicate what is being executed. During triage, review parallel processes and identify any files that may have been written. It is possible that COM is utilized to trampoline the child process to `explorer.exe` or `wmiprvse.exe`. +explanation = The following analytic identifies instances where Microsoft Word (winword.exe) spawns the command prompt (cmd.exe). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is winword.exe. This activity is significant because it is uncommon and often associated with spearphishing attacks, where malicious attachments execute commands via cmd.exe. If confirmed malicious, this could allow an attacker to execute arbitrary commands, potentially leading to further system compromise, data exfiltration, or lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if any are present, filter as needed. @@ -15454,7 +15204,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies Microsoft Word spawning PowerShell. Typically, this is not common behavior and not default with winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written. +explanation = The following analytic identifies instances where Microsoft Word (winword.exe) spawns a PowerShell process. This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is winword.exe. This activity is significant because it is uncommon and often associated with spearphishing attacks, where malicious documents execute encoded PowerShell commands. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to data exfiltration, system compromise, or further lateral movement within the network. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited, but if any are present, filter as needed. @@ -15464,7 +15214,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following detection identifies Microsoft Winword.exe spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64\`. `cscript.exe` or `wscript.exe` spawning from Winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly. +explanation = The following analytic identifies instances where Microsoft Winword.exe spawns Windows Script Host processes (cscript.exe or wscript.exe). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is Winword.exe. This activity is significant because it is uncommon and often associated with spearphishing attacks, where malicious scripts are executed via document macros. If confirmed malicious, this could lead to code execution, allowing attackers to gain initial access, execute further payloads, or establish persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]} known_false_positives = There will be limited false positives and it will be different for every environment. Tune by child process or command-line as needed. @@ -15474,7 +15224,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of permanent event subscriptions using Windows Management Instrumentation (WMI), which is used by attackers to achieve persistence in a compromised system. By creating a permanent event subscription, an attacker can run malicious scripts or binaries in response to specific system events that enables them to maintain access to the system undetected. The detection is made by using Sysmon EventID 5 data to detect instances where the consumers of these events are not the expected "NTEventLogEventConsumer." The detection is important because it identifies unusual or unexpected subscription creation, which suggests that an attacker is attempting to achieve persistence within the environment and might be executing malicious scripts or binaries in response to specific system events. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other damaging outcomes. False positives might occur since False positives might occur since WMI event subscriptions can be used for legitimate purposes by system administrators. You must have a thorough understanding of WMI activity within the context of the monitored environment to effectively differentiate between legitimate and malicious activity.Next steps include investigating the associated scripts or binaries and identifying the source of the attack. +explanation = The following analytic detects the creation of permanent event subscriptions using Windows Management Instrumentation (WMI). It leverages Sysmon Event ID 5 data to identify instances where the event consumers are not the expected "NTEventLogEventConsumer." This activity is significant because it suggests an attacker is attempting to achieve persistence by running malicious scripts or binaries in response to specific system events. If confirmed malicious, this could lead to severe impacts such as data theft, ransomware deployment, or other damaging outcomes. Investigate the associated scripts or binaries to identify the source of the attack. how_to_implement = To successfully implement this search, you must be ingesting the Windows WMI activity logs. This can be done by adding a stanza to inputs.conf on the system generating logs with a title of [WinEventLog://Microsoft-Windows-WMI-Activity/Operational]. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, administrators may use event subscriptions for legitimate purposes. @@ -15484,12 +15234,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This analytic looks for the creation of WMI permanent event subscriptions. The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. \ -All event subscriptions have three components \ -1. Filter - WQL Query for the events we want. EventID = 19 \ -1. Consumer - An action to take upon triggering the filter. EventID = 20 \ -1. Binding - Registers a filter to a consumer. EventID = 21 \ -Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. +explanation = The following analytic identifies the creation of WMI permanent event subscriptions, which can be used to establish persistence or perform privilege escalation. It leverages Sysmon data, specifically EventCodes 19, 20, and 21, to detect the creation of WMI EventFilters, EventConsumers, and FilterToConsumerBindings. This activity is significant as it may indicate an attacker setting up mechanisms to execute code with elevated SYSTEM privileges when specific events occur. If confirmed malicious, this could allow the attacker to maintain persistence, escalate privileges, and execute arbitrary code, posing a severe threat to the environment. how_to_implement = To successfully implement this search, you must be collecting Sysmon data using Sysmon version 6.1 or greater and have Sysmon configured to generate alerts for WMI activity (eventID= 19, 20, 21). In addition, you must have at least version 6.0.4 of the Sysmon TA installed to properly parse the fields. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"]} known_false_positives = Although unlikely, administrators may use event subscriptions for legitimate purposes. @@ -15499,7 +15244,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found in malware and APT events where the adversary will map all running security applications or services on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104, where WMI performs an event query to list running processes or services. This detection leverages PowerShell Script Block Logging to capture and analyze script block text for specific WMI queries. This activity is significant as it is commonly used by malware and APT actors to map security applications or services on a compromised machine. If confirmed malicious, this could allow attackers to identify and potentially disable security defenses, facilitating further compromise and persistence within the environment. how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.AE"]} known_false_positives = Network administrator may used this command for checking purposes @@ -15509,7 +15254,7 @@ providing_technologies = ["Microsoft Windows"] type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the creation of WMI temporary event subscriptions. WMI (Windows Management Instrumentation) is a management technology that allows administrators to perform various tasks on Windows-based systems. Temporary event subscriptions are created to monitor specific events or changes on a system that help to detect potential threats early and take proactive measures to protect the organization's systems and data. The detection is made by using the Splunk query `wmi` EventCode=5860 Temporary to search for events with EventCode 5860, which indicates the creation of a temporary WMI event subscription. To further refine the search results, the query uses regular expressions (rex) to extract the query used in the event subscription. Then, it filters known benign queries related to system processes such as 'wsmprovhost.exe' and 'AntiVirusProduct', 'FirewallProduct', 'AntiSpywareProduct', which helps to focus on potentially malicious or suspicious queries. The detection is important because it indicates malicious activity since attackers use WMI to run commands, gather information, or maintain persistence within a compromised system. False positives might occur since legitimate uses of WMI event subscriptions in the environment might trigger benign activities to be flagged. Therefore, an extensive triage is necessary to review the specific query and assess its intent. Additionally, capturing and inspecting relevant on-disk artifacts and analyzing concurrent processes can help to identify the source of the attack. Detecting the creation of these event subscriptions to identify potential threats early and take appropriate actions to mitigate the risks. +explanation = The following analytic detects the creation of WMI temporary event subscriptions. It leverages Windows Event Logs, specifically EventCode 5860, to identify these activities. This detection is significant because attackers often use WMI to execute commands, gather information, or maintain persistence within a compromised system. If confirmed malicious, this activity could allow an attacker to execute arbitrary code, escalate privileges, or persist in the environment. Analysts should review the specific WMI queries and assess their intent, considering potential false positives from legitimate administrative tasks. how_to_implement = To successfully implement this search, you must be ingesting the Windows WMI activity logs. This can be done by adding a stanza to inputs.conf on the system generating logs with a title of [WinEventLog://Microsoft-Windows-WMI-Activity/Operational]. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Some software may create WMI temporary event subscriptions for various purposes. The included search contains an exception for two of these that occur by default on Windows 10 systems. You may need to modify the search to create exceptions for other legitimate events. @@ -15519,9 +15264,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following hunting analytic identifies the use of `wmic.exe` enumerating local groups on the endpoint. \ -Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \ -During triage, review parallel processes and identify any further suspicious behavior. +explanation = The following analytic identifies the use of `wmic.exe` to enumerate local groups on an endpoint. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs, including command-line details. Monitoring this activity is significant as it can indicate reconnaissance efforts by an attacker to understand group memberships, which could be a precursor to privilege escalation or lateral movement. If confirmed malicious, this activity could allow an attacker to map out privileged groups, aiding in further exploitation and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]} known_false_positives = Administrators or power users may use this command for troubleshooting. @@ -15531,7 +15274,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic indentifies WMIC command-line attempting to uninstall application non-interactively. This technique was seen in IcedID to uninstall AV products on the compromised host to evade detection. This Hunting query maybe a good indicator that some process tries to uninstall application using wmic which is not a common behavior. This approach may seen in some script or third part appication to uninstall their application but it is a good thing to check what it uninstall and why. +explanation = The following analytic identifies the use of the WMIC command-line tool attempting to uninstall applications non-interactively. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns associated with WMIC. This activity is significant because it is uncommon and may indicate an attempt to evade detection by uninstalling security software, as seen in IcedID malware campaigns. If confirmed malicious, this behavior could allow an attacker to disable security defenses, facilitating further compromise and persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} known_false_positives = Third party application may use this approach to uninstall applications. @@ -15541,7 +15284,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `wmic.exe` loading a remote XSL (eXtensible Stylesheet Language) script. This originally was identified by Casey Smith, dubbed Squiblytwo, as an application control bypass. Many adversaries will utilize this technique to invoke JScript or VBScript within an XSL file. This technique can also execute local/remote scripts and, similar to its Regsvr32 "Squiblydoo" counterpart, leverages a trusted, built-in Windows tool. Adversaries may abuse any alias in Windows Management Instrumentation provided they utilize the /FORMAT switch. Upon identifying a suspicious execution, review for confirmed network connnection and script download. +explanation = The following analytic detects `wmic.exe` loading a remote XSL script via a URL. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions that include HTTP/HTTPS URLs and the /FORMAT switch. This activity is significant as it indicates a potential application control bypass, allowing adversaries to execute JScript or VBScript within an XSL file. If confirmed malicious, this technique can enable attackers to execute arbitrary code, escalate privileges, or maintain persistence using a trusted Windows tool, posing a severe threat to the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1220"], "nist": ["DE.CM"]} known_false_positives = False positives are limited as legitimate applications typically do not download files or xsl using WMIC. Filter as needed. @@ -15551,7 +15294,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `wmiprsve.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing Windows Management Instrumentation (WMI), the executed command is spawned as a child process of `wmiprvse.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of wmiprvse.exe that are part of the LOLBAS project can help defenders identify lateral movement activity. +explanation = The following analytic detects `wmiprvse.exe` spawning a LOLBAS execution process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where `wmiprvse.exe` is the parent process and the child process is a known LOLBAS binary. This activity is significant as it may indicate lateral movement or remote code execution by an adversary abusing Windows Management Instrumentation (WMI). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may trigger this behavior, filter as needed. @@ -15561,7 +15304,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This analytic identifies a suspicious spawned process by WScript or CScript process. This technique was a common technique used by adversaries and malware to execute different LOLBIN, other scripts like PowerShell or spawn a suspended process to inject its code as a defense evasion. This TTP may detect some normal script that using several application tool that are in the list of the child process it detects but a good pivot and indicator that a script is may execute suspicious code. +explanation = The following analytic identifies suspicious child processes spawned by WScript or CScript. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific parent and child process names. This activity is significant as adversaries often use WScript or CScript to execute Living Off The Land Binaries (LOLBINs) or other scripts like PowerShell for defense evasion. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a significant security risk. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1055", "T1543", "T1134.004", "T1134"], "nist": ["DE.CM"]} known_false_positives = Administrators may create vbs or js script that use several tool as part of its execution. Filter as needed. @@ -15571,7 +15314,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies `Wsmprovhost.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the Windows Remote Management (WinRm) protocol, the executed command is spawned as a child processs of `Wsmprovhost.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of Wsmprovhost.exe that are part of the LOLBAS project can help defenders identify lateral movement activity. +explanation = The following analytic identifies `Wsmprovhost.exe` spawning a LOLBAS execution process. It leverages Endpoint Detection and Response (EDR) data to detect when `Wsmprovhost.exe` spawns child processes that are known LOLBAS (Living Off the Land Binaries and Scripts) executables. This activity is significant because it may indicate an adversary using Windows Remote Management (WinRM) to execute code on remote endpoints, a common technique for lateral movement. If confirmed malicious, this could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]} known_false_positives = Legitimate applications may trigger this behavior, filter as needed. @@ -15581,7 +15324,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Micros type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious modification of registry related to UAC bypass. This technique is to modify the registry in this detection, create a registry value with the path of the payload and run WSreset.exe to bypass User account Control. +explanation = The following analytic detects a suspicious modification of the registry aimed at bypassing User Account Control (UAC) by leveraging WSReset.exe. It identifies the creation or modification of specific registry values under the path "*\\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\\Shell\\open\\command*". This detection uses data from Endpoint Detection and Response (EDR) agents, focusing on process and registry events. This activity is significant because UAC bypass techniques can allow attackers to execute high-privilege actions without user consent. If confirmed malicious, this could lead to unauthorized code execution and potential system compromise. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15601,7 +15344,7 @@ providing_technologies = ["Microsoft Sysmon"] type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect a suspicious wmic.exe process or renamed wmic process to execute malicious xsl file. This technique was seen in FIN7 to execute its malicous jscript using the .xsl as the loader with the help of wmic.exe process. This TTP is really a good indicator for you to hunt further for FIN7 or other attacker that known to used this technique. +explanation = The following analytic detects the execution of an XSL script using the WMIC process, which is often indicative of malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving WMIC and XSL files. This behavior is significant as it has been associated with the FIN7 group, known for using this technique to execute malicious scripts. If confirmed malicious, this activity could allow attackers to execute arbitrary code, potentially leading to system compromise and further malicious actions within the environment. how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1220"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15621,7 +15364,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses a pre trained deep learning model to detect Domain Generation Algorithm (DGA) generated domains. The model is trained independently and is then made available for download. One of the prominent indicators of a domain being DGA generated is if the domain name consists of unusual character sequences or concatenated dictionary words. Adversaries often use clever techniques to obfuscate machine generated domain names as human generated. Predicting DGA generated domain names requires analysis and building a model based on carefully chosen features. The deep learning model we have developed uses the domain name to analyze patterns of character sequences along with carefully chosen custom features to predict if a domain is DGA generated. The model takes a domain name consisting of second-level and top-level domain names as input and outputs a dga_score. Higher the dga_score, the more likely the input domain is a DGA domain. The threshold for flagging a domain as DGA is set at 0.5. +explanation = The following analytic identifies Domain Generation Algorithm (DGA) generated domains using a pre-trained deep learning model. It leverages the Network Resolution data model to analyze domain names and detect unusual character sequences indicative of DGA activity. This behavior is significant as adversaries often use DGAs to generate numerous domain names for command-and-control servers, making it harder to block malicious traffic. If confirmed malicious, this activity could enable attackers to maintain persistent communication with compromised systems, evade detection, and execute further malicious actions. how_to_implement = Steps to deploy DGA detection model into Splunk App DSDL.\ This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - https://splunkbase.splunk.com/app/4607/ and the Network Resolution datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU. * Download the artifacts .tar.gz file from the link `https://seal.splunkresearch.com/pretrained_dga_model_dsdl.tar.gz` \ * Download the pretrained_dga_model_dsdl.ipynb Jupyter notebook from `https://github.com/splunk/security_content/notebooks` \ * Login to the Jupyter Lab for pretrained_dga_model_dsdl container. This container should be listed on Containers page for DSDL app. \ @@ -15639,13 +15382,13 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses a pre trained deep learning model to detect DNS data exfiltration. The model is trained on the data we collected and is inferred on live data. This detection detects low throughput DNS Tunneling (data exfiltration) using features computed from past events between the same src and domain. The search uses macros from URL ToolBox app to generate features used by the model. The model is a deep learning model that accepts DNS request as input along with a few custom features to generate a pred_is_exfiltration_proba score. The higher the pred_is_exfiltration_proba, the more likely the DNS request is data exfiltration. The threshold for flagging a request as DNS exfiltration is set at 0.5. +explanation = The following analytic identifies potential DNS data exfiltration using a pre-trained deep learning model. It leverages DNS request data from the Network Resolution datamodel and computes features from past events between the same source and domain. The model generates a probability score (pred_is_exfiltration_proba) indicating the likelihood of data exfiltration. This activity is significant as DNS tunneling can be used by attackers to covertly exfiltrate sensitive data. If confirmed malicious, this could lead to unauthorized data access and potential data breaches, compromising the organization's security posture. how_to_implement = Steps to deploy detect DNS data exfiltration model into Splunk App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - https://splunkbase.splunk.com/app/4607/ and the Network Resolution datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`. \ -* Download the `artifacts .tar.gz` file from the link - https://seal.splunkresearch.com/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz Download the `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from https://github.com/splunk/security_content/notebooks \ + * Download the `artifacts .tar.gz` file from the link - https://seal.splunkresearch.com/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz Download the `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from https://github.com/splunk/security_content/notebooks \ * Login to the Jupyter Lab assigned for detect_dns_data_exfiltration_using_pretrained_model_in_dsdl container. This container should be listed on Containers page for DSDL app. \ * Below steps need to be followed inside Jupyter lab \ * Upload the detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz file into `app/model/data` path using the upload option in the jupyter notebook. \ -* Untar the artifact detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz -C app/model/data` \ + * Untar the artifact detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz -C app/model/data` \ * Upload detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.pynb into Jupyter lab notebooks folder using the upload option in Jupyter lab \ * Save the notebook using the save option in jupyter notebook. \ * Upload `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.json` into `notebooks/data` folder. @@ -15657,7 +15400,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Malicious actors often abuse legitimate Dynamic DNS services to host malicious payloads or interactive Command And Control nodes. Attackers will automate domain resolution changes by routing dynamic domains to countless IP addresses to circumvent firewall blocks, block lists as well as frustrate a network defenders analytic and investigative processes. This search will look for DNS queries made from within your infrastructure to suspicious dynamic domains. +explanation = The following analytic identifies DNS queries from internal hosts to dynamic domain providers. It leverages DNS query logs from the `Network_Resolution` data model and cross-references them with a lookup file containing known dynamic DNS providers. This activity is significant because attackers often use dynamic DNS services to host malicious payloads or command-and-control servers, making it crucial for security teams to monitor. If confirmed malicious, this activity could allow attackers to bypass firewall blocks, evade detection, and maintain persistent access to the network. how_to_implement = First, you'll need to ingest data from your DNS operations. This can be done by ingesting logs from your server or data, collected passively by Splunk Stream or a similar solution. Specifically, data that contains the domain that is being queried and the IP of the host originating the request must be populating the `Network_Resolution` data model. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`. \ This search produces fields (query, answer, isDynDNS) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable event. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry): \ * **Label:** DNS Query, **Field:** query \ @@ -15682,7 +15425,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for outbound ICMP packets with a packet size larger than 1,000 bytes. Various threat actors have been known to use ICMP as a command and control channel for their attack infrastructure. Large ICMP packets from an endpoint to a remote host may be indicative of this activity. +explanation = The following analytic identifies outbound ICMP packets with a size larger than 1,000 bytes. It leverages the Network_Traffic data model to detect unusually large ICMP packets that are not blocked and are destined for external IP addresses. This activity is significant because threat actors often use ICMP for command and control communication, and large ICMP packets can indicate data exfiltration or other malicious activities. If confirmed malicious, this could allow attackers to maintain covert communication channels, exfiltrate sensitive data, or further compromise the network. how_to_implement = In order to run this search effectively, we highly recommend that you leverage the Assets and Identity framework. It is important that you have a good understanding of how your network segments are designed and that you are able to distinguish internal from external address space. Add a category named `internal` to the CIDRs that host the company's assets in the `assets_by_cidr.csv` lookup file, which is located in `$SPLUNK_HOME/etc/apps/SA-IdentityManagement/lookups/`. More information on updating this lookup can be found here: https://docs.splunk.com/Documentation/ES/5.0.0/Admin/Addassetandidentitydata. This search also requires you to be ingesting your network traffic and populating the Network_Traffic data model annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1095"], "nist": ["DE.CM"]} known_false_positives = ICMP packets are used in a variety of ways to help troubleshoot networking issues and ensure the proper flow of traffic. As such, it is possible that a large ICMP packet could be perfectly legitimate. If large ICMP packets are associated with Command And Control traffic, there will typically be a large number of these packets observed over time. If the search is providing a large number of false positives, you can modify the macro `detect_large_outbound_icmp_packets_filter` to adjust the byte threshold or add specific IP addresses to an allow list. @@ -15692,7 +15435,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Malicious actors often abuse misconfigured LDAP servers or applications that use the LDAP servers in organizations. Outbound LDAP traffic should not be allowed outbound through your perimeter firewall. This search will help determine if you have any LDAP connections to IP addresses outside of private (RFC1918) address space. +explanation = The following analytic identifies outbound LDAP traffic to external IP addresses. It leverages the Network_Traffic data model to detect connections on ports 389 or 636 that are not directed to private IP ranges (RFC1918). This activity is significant because outbound LDAP traffic can indicate potential data exfiltration or unauthorized access attempts. If confirmed malicious, attackers could exploit this to access sensitive directory information, leading to data breaches or further network compromise. how_to_implement = In order to properly run this search, Splunk needs to ingest data from Next Generation Firewalls like Palo Alto Networks Firewalls or other network control devices that mediate the traffic allowed into an environment. The search requires the Network_Traffic data model to be populated. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1059"], "nist": ["DE.AE"]} known_false_positives = Unknown at this moment. Outbound LDAP traffic should not be allowed outbound through your perimeter firewall. Please check those servers to verify if the activity is legitimate. @@ -15702,7 +15445,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects outbound SMB (Server Message Block) connections from internal hosts to external servers, a method commonly exploited for Windows file-sharing activities. It identifies this behavior by monitoring network traffic for SMB requests directed towards the Internet, which are not typical for standard operations. This detection is crucial for a Security Operations Center (SOC) as it can indicate an attackers attempt to retrieve credential hashes through compromised servers, a key step in lateral movement and privilege escalation. The impact of such an attack includes unauthorized access to sensitive data and potential full system compromise. +explanation = The following analytic detects outbound SMB (Server Message Block) connections from internal hosts to external servers. It identifies this activity by monitoring network traffic for SMB requests directed towards the Internet, which are unusual for standard operations. This detection is significant for a SOC as it can indicate an attacker's attempt to retrieve credential hashes through compromised servers, a key step in lateral movement and privilege escalation. If confirmed malicious, this activity could lead to unauthorized access to sensitive data and potential full system compromise. how_to_implement = This search also requires you to be ingesting your network traffic and populating the Network_Traffic data model annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.002", "T1071"], "nist": ["DE.CM"]} known_false_positives = It is likely that the outbound Server Message Block (SMB) traffic is legitimate, if the company's internal networks are not well-defined in the Assets and Identity Framework. Categorize the internal CIDR blocks as `internal` in the lookup file to avoid creating notable events for traffic destined to those CIDR blocks. Any other network connection that is going out to the Internet should be investigated and blocked. Best practices suggest preventing external communications of all SMB versions and related protocols at the network boundary. @@ -15712,7 +15455,7 @@ providing_technologies = null type = detection asset_type = Infrastructure confidence = medium -explanation = By enabling Port Security on a Cisco switch you can restrict input to an interface by limiting and identifying MAC addresses of the workstations that are allowed to access the port. When you assign secure MAC addresses to a secure port, the port does not forward packets with source addresses outside the group of defined addresses. If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the workstation attached to that port is assured the full bandwidth of the port. If a port is configured as a secure port and the maximum number of secure MAC addresses is reached, when the MAC address of a workstation attempting to access the port is different from any of the identified secure MAC addresses, a security violation occurs. +explanation = The following analytic detects port security violations on Cisco switches. It leverages logs from Cisco network devices, specifically looking for events with mnemonics indicating port security violations. This activity is significant because it indicates an unauthorized device attempting to connect to a secured port, potentially bypassing network access controls. If confirmed malicious, this could allow an attacker to gain unauthorized access to the network, leading to data exfiltration, network disruption, or further lateral movement within the environment. how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with Port Security and Error Disable for this to work (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/port_sec.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives", "Delivery", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557", "T1557.002"], "nist": ["DE.CM"]} known_false_positives = This search might be prone to high false positives if you have malfunctioning devices connected to your ethernet ports or if end users periodically connect physical devices to the network. @@ -15722,7 +15465,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects when a known remote access software domains are contacted from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects DNS queries to known remote access software domains from within the environment. It leverages DNS query logs mapped to the Network_Resolution data model and cross-references them with a lookup table of remote access software domains, such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use remote access tools to maintain persistent access to compromised systems. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or further infiltrate the network, posing a severe security risk. how_to_implement = To implement this search, you must ingest logs that contain the DNS query and the source of the query. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the DNS logs. The logs must also be mapped to the `Network_Resolution` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. @@ -15732,7 +15475,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects when a known remote access software application traffic is detected from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects network traffic associated with known remote access software applications, such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. It leverages Palo Alto traffic logs mapped to the Network_Traffic data model in Splunk. This activity is significant because adversaries often use remote access tools to maintain unauthorized access to compromised environments. If confirmed malicious, this activity could allow attackers to control systems remotely, exfiltrate data, or deploy additional malware, posing a severe threat to the organization's security. how_to_implement = The following analytic was developed with Palo Alto traffic logs. Ensure that the logs are being ingested into Splunk and mapped to the Network_Traffic data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. @@ -15742,7 +15485,7 @@ providing_technologies = null type = detection asset_type = Infrastructure confidence = medium -explanation = By enabling DHCP Snooping as a Layer 2 Security measure on the organization's network devices, we will be able to detect unauthorized DHCP servers handing out DHCP leases to devices on the network (Man in the Middle attack). +explanation = The following analytic identifies the presence of unauthorized DHCP servers on the network. It leverages logs from Cisco network devices with DHCP Snooping enabled, specifically looking for events where DHCP leases are issued from untrusted ports. This activity is significant because rogue DHCP servers can facilitate Man-in-the-Middle attacks, leading to potential data interception and network disruption. If confirmed malicious, this could allow attackers to redirect network traffic, capture sensitive information, and compromise the integrity of the network. how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with DHCP Snooping enabled (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/security/configuration_guide/b_sec_152ex_2960-x_cg/b_sec_152ex_2960-x_cg_chapter_01101.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives", "Delivery", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557"], "nist": ["DE.CM"]} known_false_positives = This search might be prone to high false positives if DHCP Snooping has been incorrectly configured or in the unlikely event that the DHCP server has been moved to another network interface. @@ -15762,7 +15505,7 @@ providing_technologies = ["Zeek"] type = detection asset_type = Infrastructure confidence = medium -explanation = Adversaries may abuse netbooting to load an unauthorized network device operating system from a Trivial File Transfer Protocol (TFTP) server. TFTP boot (netbooting) is commonly used by network administrators to load configuration-controlled network device images from a centralized management server. Netbooting is one option in the boot sequence and can be used to centralize, manage, and control device images. +explanation = The following analytic identifies unauthorized software downloads to network devices via TFTP, FTP, or SSH/SCP. It detects this activity by analyzing network traffic events on specific ports (69, 21, 22) from devices categorized as network, router, or switch. This activity is significant because adversaries may exploit netbooting to load unauthorized operating systems, potentially compromising network integrity. If confirmed malicious, this could lead to unauthorized control over network devices, enabling further attacks, data exfiltration, or persistent access within the network. how_to_implement = This search looks for Network Traffic events to TFTP, FTP or SSH/SCP ports from network devices. Make sure to tag any network devices as network, router or switch in order for this detection to work. If the TFTP traffic doesn't traverse a firewall nor packet inspection, these events will not be logged. This is typically an issue if the TFTP server is on the same subnet as the network device. There is also a chance of the network device loading software using a DHCP assigned IP address (netboot) which is not in the Asset inventory. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.005", "T1542"], "nist": ["DE.CM"]} known_false_positives = This search will also report any legitimate attempts of software downloads to network devices as well as outbound SSH sessions from network devices. @@ -15772,7 +15515,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic uses a pre trained deep learning model to detect suspicious DNS TXT records. The model is trained independently and is then made available for download. The DNS TXT records are categorized into commonly identified types like email, verification, http using regular expressions https://www.tide-project.nl/blog/wtmc2020/. The TXT records that do not match regular expressions for well known types are labeled as 1 for "unknown/suspicious" and otherwise 0 for "not suspicious". The deep learning model we have developed uses DNS TXT responses to analyze patterns of character sequences to predict if a DNS TXT is suspicious or not. The higher the pred_is_unknown_proba, the more likely the DNS TXT record is suspicious. The threshold for flagging a domain as suspicious is set at 0.5. +explanation = The following analytic identifies suspicious DNS TXT records using a pre-trained deep learning model. It leverages DNS response data from the Network Resolution data model, categorizing TXT records into known types via regular expressions. Records that do not match known patterns are flagged as suspicious. This activity is significant as DNS TXT records can be used for data exfiltration or command-and-control communication. If confirmed malicious, attackers could use these records to covertly transfer data or receive instructions, posing a severe threat to network security. how_to_implement = Steps to deploy detect suspicious DNS TXT records model into Splunk App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - `https://splunkbase.splunk.com/app/4607/` and the Network Resolution datamodel which can be found here - `https://splunkbase.splunk.com/app/1621/`. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`. \ * Download the `artifacts .tar.gz` file from the link - `https://seal.splunkresearch.com/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz`. \ * Download the `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from `https://github.com/splunk/security_content/notebooks`. \ @@ -15791,7 +15534,7 @@ providing_technologies = null type = detection asset_type = Infrastructure confidence = medium -explanation = Adversaries may leverage traffic mirroring in order to automate data exfiltration over compromised network infrastructure. Traffic mirroring is a native feature for some network devices and used for network analysis and may be configured to duplicate traffic and forward to one or more destinations for analysis by a network analyzer or other monitoring device. +explanation = The following analytic detects the initiation of traffic mirroring sessions on Cisco network devices. It leverages logs with specific mnemonics and facilities related to traffic mirroring, such as "ETH_SPAN_SESSION_UP" and "PKTCAP_START." This activity is significant because adversaries may use traffic mirroring to exfiltrate data by duplicating and forwarding network traffic to an external destination. If confirmed malicious, this could allow attackers to capture sensitive information, monitor network communications, and potentially compromise the integrity and confidentiality of the network. how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices and that the devices have been configured according to the documentation of the Cisco Networks Add-on. Also note that an attacker may disable logging from the device prior to enabling traffic mirroring. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives", "Delivery"], "mitre_attack": ["T1200", "T1020", "T1498", "T1020.001"], "nist": ["DE.CM"]} known_false_positives = This search will return false positives for any legitimate traffic captures by network administrators. @@ -15801,7 +15544,7 @@ providing_technologies = null type = detection asset_type = Infrastructure confidence = medium -explanation = By populating the organization's assets within the assets_by_str.csv, we will be able to detect unauthorized devices that are trying to connect with the organization's network by inspecting DHCP request packets, which are issued by devices when they attempt to obtain an IP address from the DHCP server. The MAC address associated with the source of the DHCP request is checked against the list of known devices, and reports on those that are not found. +explanation = The following analytic identifies unauthorized devices attempting to connect to the organization's network by inspecting DHCP request packets. It detects this activity by comparing the MAC addresses in DHCP requests against a list of known authorized devices stored in the assets_by_str.csv file. This activity is significant for a SOC because unauthorized devices can pose security risks, including potential data breaches or network disruptions. If confirmed malicious, this activity could allow an attacker to gain unauthorized network access, potentially leading to further exploitation or data exfiltration. how_to_implement = This search uses the Network_Sessions data model shipped with Enterprise Security. It leverages the Assets and Identity framework to populate the assets_by_str.csv file located in SA-IdentityManagement, which will contain a list of known authorized organizational assets including their MAC addresses. Ensure that all inventoried systems have their MAC address populated. annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]} known_false_positives = This search might be prone to high false positives. Please consider this when conducting analysis or investigations. Authorized devices may be detected as unauthorized. If this is the case, verify the MAC address of the system responsible for the false positive and add it to the Assets and Identity framework with the proper information. @@ -15811,7 +15554,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = Ensure that the following prerequisites are met: (i) Both Splunk Stream DNS and TCP data are ingested. (ii) The macros 'stream:dns' and 'stream:tcp' are replaced with the appropriate configurations that are specific to your Splunk environment. The following analytic detects SIGRed exploitation attempts. SIGRed is a critical wormable vulnerability found in Windows DNS servers, known as CVE-2020-1350, which allows remote code execution. The detection is made by using an experimental search that focuses on identifying specific indicators that might suggest the presence of the SIGRed exploit such as DNS SIG records, KEY records, and TCP payloads greater than 65KB. This detection is important because it detects and responds to potential SIGRed exploitation attempts and minimizes the risk of a successful attack and its impact on the organization's infrastructure and data. False positives might occur due to the experimental nature of this analytic. Next steps include reviewing and investigating each case thoroughly given the potential for unauthorized Windows DNS server access, data breaches, and service disruptions. Additionally, you must stay updated with Microsoft's guidance on the SIGRed vulnerability. +explanation = The following analytic detects attempts to exploit the SIGRed vulnerability (CVE-2020-1350) in Windows DNS servers. It leverages Splunk Stream DNS and TCP data to identify DNS SIG and KEY records, as well as TCP payloads exceeding 65KB. This activity is significant because SIGRed is a critical wormable vulnerability that allows remote code execution. If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary code, and potentially disrupt services, leading to severe data breaches and infrastructure compromise. Immediate investigation and remediation are crucial to mitigate these risks. how_to_implement = You must be ingesting Splunk Stream DNS and Splunk Stream TCP. We are detecting SIG and KEY records via stream:dns and TCP payload over 65KB in size via stream:tcp. Replace the macro definitions ('stream:dns' and 'stream:tcp') with configurations for your Splunk environment. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1203"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15821,7 +15564,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects the presence of SIGRed, a critical DNS vulnerability, using Zeek DNS and Zeek Conn data. SIGRed vulnerability allows attackers to run remote code on Windows DNS servers. By detecting SIGRed early, you can prevent further damage and protect the organization's network infrastructure. The detection is made by identifying specific DNS query types (SIG and KEY) in the Zeek DNS data and checks for high data transfer in the Zeek Conn data. If multiple instances of these indicators are found within a flow, it suggests the presence of SIGRed. The detection is important because it indicates a potential compromise of Windows DNS servers that suggests that an attacker might have gained unauthorized access to the DNS server and can run arbitrary code. The impact of this attack can be severe, leading to data exfiltration, unauthorized access, or disruption of critical services. Next steps include investigating the affected flow and taking immediate action to mitigate the vulnerability. This can involve patching the affected DNS server, isolating the server from the network, or conducting a forensic analysis to determine the extent of the compromise. +explanation = The following analytic detects the presence of SIGRed, a critical DNS vulnerability, using Zeek DNS and Zeek Conn data. It identifies specific DNS query types (SIG and KEY) and checks for high data transfer within a flow. This detection is significant because SIGRed allows attackers to execute remote code on Windows DNS servers, potentially leading to unauthorized access and control. If confirmed malicious, this activity could result in data exfiltration, service disruption, or further network compromise. Immediate investigation and mitigation, such as patching or isolating the affected server, are crucial. how_to_implement = You must be ingesting Zeek DNS and Zeek Conn data into Splunk. Zeek data should also be getting ingested in JSON format. We are detecting SIG and KEY records via bro:dns:json and TCP payload over 65KB in size via bro:conn:json. The Network Resolution and Network Traffic datamodels are in use for this search. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1203"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15831,7 +15574,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects attempts to exploit the Zerologon CVE-2020-1472 vulnerability through Zeek RPC. By detecting attempts to exploit the Zerologon vulnerability through Zeek RPC, SOC analysts can identify potential threats earlier and take appropriate action to mitigate the risks. This detection is made by a Splunk query that looks for specific Zeek RPC operations, including NetrServerPasswordSet2, NetrServerReqChallenge, and NetrServerAuthenticate3, which are aggregated by source and destination IP address and time. This detection is important because it suggests that an attacker is attempting to exploit the Zerologon vulnerability to gain unauthorized access to the domain controller. Zerologon vulnerability is a critical vulnerability that allows attackers to take over domain controllers without authentication, leading to a complete takeover of an organization's IT infrastructure. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other devastating outcomes. False positives might occur since legitimate Zeek RPC activity can trigger the analytic. Next steps include reviewing the identified source and destination IP addresses and the specific RPC operations used. Capture and inspect any relevant on-disk artifacts, and review concurrent processes to identify the attack source upon triage . +explanation = The following analytic detects attempts to exploit the Zerologon CVE-2020-1472 vulnerability via Zeek RPC. It leverages Zeek DCE-RPC data to identify specific operations: NetrServerPasswordSet2, NetrServerReqChallenge, and NetrServerAuthenticate3. This activity is significant because it indicates an attempt to gain unauthorized access to a domain controller, potentially leading to a complete takeover of an organization's IT infrastructure. If confirmed malicious, the impact could be severe, including data theft, ransomware deployment, or other devastating outcomes. Immediate investigation of the identified IP addresses and RPC operations is crucial. how_to_implement = You must be ingesting Zeek DCE-RPC data into Splunk. Zeek data should also be getting ingested in JSON format. We are detecting when all three RPC operations (NetrServerReqChallenge, NetrServerAuthenticate3, NetrServerPasswordSet2) are splunk_security_essentials_app via bro:rpc:json. These three operations are then correlated on the Zeek UID field. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15856,7 +15599,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search allows you to identify DNS requests and compute the standard deviation on the length of the names being resolved, then filter on two times the standard deviation to show you those queries that are unusually large for your environment. +explanation = The following analytic identifies DNS queries with unusually large lengths by computing the standard deviation of query lengths and filtering those exceeding twice the standard deviation. It leverages DNS query data from the Network_Resolution data model, focusing on the length of the domain names being resolved. This activity is significant as unusually long DNS queries can indicate data exfiltration or command-and-control communication attempts. If confirmed malicious, this activity could allow attackers to stealthily transfer data or maintain persistent communication channels within the network. how_to_implement = To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]} known_false_positives = It's possible there can be long domain names that are legitimate. @@ -15876,7 +15619,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies a recent unauthenticated remote code execution vulnerablity against the F5 BIG-IP iControl REST API. The analytic identifies the URI path found in the POCs and the HTTP Method of POST. In addition, the request header will have the commands that may be executed in fields utilcmdargs and the auth field of X-F5-Auth-Token, which may have a random base64 encoded value. +explanation = The following analytic detects attempts to exploit the F5 BIG-IP iControl REST API vulnerability (CVE-2022-1388) for unauthenticated remote code execution. It identifies suspicious URI paths and POST HTTP methods, along with specific request headers containing potential commands in the `utilcmdargs` field and a random base64 encoded value in the `X-F5-Auth-Token` field. This activity is significant as it targets a critical vulnerability that can allow attackers to execute arbitrary commands on the affected system. If confirmed malicious, this could lead to full system compromise and unauthorized access to sensitive data. how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may be present if the activity is blocked or was not successful. Filter known vulnerablity scanners. Filter as needed. @@ -15886,7 +15629,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects high volume of bytes out (greater than 1GB) to a URL within 2 mins of time window. This may be indicative of an attacker attempting to exfiltrate data. The search applies a fundamental threshold for detecting significant web uploads. This approach aims to identify potential data exfiltration activities by malware or malevolent insiders. View the alert for $dest$ to investigate further. +explanation = The following analytic detects a high volume of outbound web traffic, specifically over 1GB of data sent to a URL within a 2-minute window. It leverages the Web data model to identify significant uploads by analyzing the sum of bytes out. This activity is significant as it may indicate potential data exfiltration by malware or malicious insiders. If confirmed as malicious, this behavior could lead to unauthorized data transfer, resulting in data breaches and loss of sensitive information. Immediate investigation is required to determine the legitimacy of the transfer and mitigate any potential threats. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. Please adjust the threshold for the sum of bytes out as per your environment and user behavior. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"]} known_false_positives = This search may trigger false positives if there is a legitimate reason for a high volume of bytes out to a URL. We recommend to investigate these findings. Consider updating the filter macro to exclude the applications that are relevant to your environment. @@ -15916,7 +15659,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search is designed to detect high frequency of archive files data exfiltration through HTTP POST method protocol. This are one of the common techniques used by APT or trojan spy after doing the data collection like screenshot, recording, sensitive data to the infected machines. The attacker may execute archiving command to the collected data, save it a temp folder with a hidden attribute then send it to its C2 through HTTP POST. Sometimes adversaries will rename the archive files or encode/encrypt to cover their tracks. This detection can detect a renamed archive files transfer to HTTP POST since it checks the request body header. Unfortunately this detection cannot support archive that was encrypted or encoded before doing the exfiltration. +explanation = The following analytic detects the high-frequency exfiltration of archive files via HTTP POST requests. It leverages HTTP stream logs to identify specific archive file headers within the request body. This activity is significant as it often indicates data exfiltration by APTs or trojan spyware after data collection. If confirmed malicious, this behavior could lead to the unauthorized transfer of sensitive data to an attacker’s command and control server, potentially resulting in severe data breaches and loss of confidential information. how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled in stream http configuration. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.CM"]} known_false_positives = Normal archive transfer via HTTP protocol may trip this detection. @@ -15926,7 +15669,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies the 4 most common Ngrok used domains based on DNS queries under the Network Resolution datamodel. It's possible these domains may be ran against the Web datamodel or ran with a direct query across network/proxy traffic. The sign of someone using Ngrok is not malicious, however, more recenctly it has become an adversary tool. +explanation = The following analytic detects DNS queries to common Ngrok domains, indicating potential use of the Ngrok reverse proxy tool. It leverages the Network Resolution datamodel to identify queries to domains such as "*.ngrok.com" and "*.ngrok.io". While Ngrok usage is not inherently malicious, it has been increasingly adopted by adversaries for covert communication and data exfiltration. If confirmed malicious, this activity could allow attackers to bypass network defenses, establish persistent connections, and exfiltrate sensitive data, posing a significant threat to the network's security. how_to_implement = The Network Resolution Datamodel will need to have data mapped to it regarding DNS queries. Modify query as needed to use another source. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]} known_false_positives = False positives will be present based on organizations that allow the use of Ngrok. Filter or monitor as needed. @@ -15936,7 +15679,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search is to detect potential plain HTTP POST method data exfiltration. This network traffic is commonly used by trickbot, trojanspy, keylogger or APT adversary where arguments or commands are sent in plain text to the remote C2 server using HTTP POST method as part of data exfiltration. +explanation = The following analytic detects potential data exfiltration using plain HTTP POST requests. It leverages network traffic logs, specifically monitoring the `stream_http` data source for POST methods containing suspicious form data such as "wermgr.exe" or "svchost.exe". This activity is significant because it is commonly associated with malware like Trickbot, trojans, keyloggers, or APT adversaries, which use plain text HTTP POST requests to communicate with remote C2 servers. If confirmed malicious, this activity could lead to unauthorized data exfiltration, compromising sensitive information and potentially leading to further network infiltration. how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.CM"]} known_false_positives = unknown @@ -15946,7 +15689,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects instances where network traffic, specifically identified by port and transport layer protocol as prohibited in the "lookup_interesting_ports" table, is allowed according to the Network_Traffic data model. It operates by cross-referencing traffic data against predefined security policies to identify discrepancies indicative of potential misconfigurations or policy violations. This detection is crucial for a Security Operations Center (SOC) as it highlights potential security breaches or misconfigured network devices that could allow unauthorized access or data exfiltration, directly impacting the organization's security posture. +explanation = The following analytic detects instances where network traffic, identified by port and transport layer protocol as prohibited in the "lookup_interesting_ports" table, is allowed. It uses the Network_Traffic data model to cross-reference traffic data against predefined security policies. This activity is significant for a SOC as it highlights potential misconfigurations or policy violations that could lead to unauthorized access or data exfiltration. If confirmed malicious, this could allow attackers to bypass network defenses, leading to potential data breaches and compromising the organization's security posture. how_to_implement = In order to properly run this search, Splunk needs to ingest data from firewalls or other network control devices that mediate the traffic allowed into an environment. This is necessary so that the search can identify an 'action' taken on the traffic of interest. The search requires the Network_Traffic data model be populated. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"]} known_false_positives = None identified @@ -15956,7 +15699,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for network traffic on common ports where a higher layer protocol does not match the port that is being used. For example, this search should identify cases where protocols other than HTTP are running on TCP port 80. This can be used by attackers to circumvent firewall restrictions, or as an attempt to hide malicious communications over ports and protocols that are typically allowed and not well inspected. +explanation = The following analytic identifies network traffic where the higher layer protocol does not match the expected port, such as non-HTTP traffic on TCP port 80. It leverages data from network traffic inspection technologies like Bro or Palo Alto Networks firewalls. This activity is significant because it may indicate attempts to bypass firewall restrictions or conceal malicious communications. If confirmed malicious, this behavior could allow attackers to evade detection, maintain persistence, or exfiltrate data through commonly allowed ports, posing a significant threat to network security. how_to_implement = Running this search properly requires a technology that can inspect network traffic and identify common protocols. Technologies such as Bro and Palo Alto Networks firewalls are two examples that will identify protocols via inspection, and not just assume a specific protocol based on the transport protocol and ports. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]} known_false_positives = None identified @@ -15966,7 +15709,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic identifies cleartext protocols at risk of leaking sensitive information. Currently, this consists of legacy protocols such as telnet (port 23), POP3 (port 110), IMAP (port 143), and non-anonymous FTP (port 21) sessions. While some of these protocols may be used over SSL, they typically are found on different assigned ports in those instances. +explanation = The following analytic identifies the use of cleartext protocols that risk leaking sensitive information. It detects network traffic on legacy protocols such as Telnet (port 23), POP3 (port 110), IMAP (port 143), and non-anonymous FTP (port 21). The detection leverages the Network_Traffic data model to identify TCP traffic on these ports. Monitoring this activity is crucial as it can expose credentials and other sensitive data to interception. If confirmed malicious, attackers could capture authentication details, leading to unauthorized access and potential data breaches. how_to_implement = This search requires you to be ingesting your network traffic, and populating the Network_Traffic data model. For more accurate result it's better to limit destination to organization private and public IP range, like All_Traffic.dest IN(192.168.0.0/16,172.16.0.0/12,10.0.0.0/8, x.x.x.x/22) annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]} known_false_positives = Some networks may use kerberized FTP or telnet servers, however, this is rare. @@ -15986,7 +15729,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects unusual Remote Desktop Protocol (RDP) traffic on TCP/3389, the default RDP port. It identifies this activity by filtering out traffic from known RDP sources and destinations, focusing on atypical RDP connections within the network. This detection is crucial for a Security Operations Center (SOC) as unauthorized RDP access can indicate an attacker's attempt to gain control over networked systems, potentially leading to data theft, ransomware deployment, or further network compromise. The impact of such unauthorized access can be significant, ranging from data breaches to complete system and network control loss. +explanation = The following analytic detects unusual Remote Desktop Protocol (RDP) traffic on TCP/3389 by filtering out known RDP sources and destinations, focusing on atypical connections within the network. This detection leverages network traffic data to identify potentially unauthorized RDP access. Monitoring this activity is crucial for a SOC as unauthorized RDP access can indicate an attacker's attempt to control networked systems, leading to data theft, ransomware deployment, or further network compromise. If confirmed malicious, this activity could result in significant data breaches or complete system and network control loss. how_to_implement = To successfully implement this search you need to identify systems that commonly originate remote desktop traffic and that commonly receive remote desktop traffic. You can use the included support search "Identify Systems Creating Remote Desktop Traffic" to identify systems that originate the traffic and the search "Identify Systems Receiving Remote Desktop Traffic" to identify systems that receive a lot of remote desktop traffic. After identifying these systems, you will need to add the "common_rdp_source" or "common_rdp_destination" category to that system depending on the usage, using the Enterprise Security Assets and Identities framework. This can be done by adding an entry in the assets.csv file located in SA-IdentityManagement/lookups. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]} known_false_positives = Remote Desktop may be used legitimately by users on the network. @@ -15996,7 +15739,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic detects spikes in the number of Server Message Block (SMB) traffic connections. SMB is a network protocol used for sharing files, printers, and other resources between computers. This detection is made by a Splunk query that looks for SMB traffic connections on ports 139 and 445, as well as connections using the SMB application. The query calculates the average and standard deviation of the number of SMB connections over the past 70 minutes, and identifies any sources that exceed two standard deviations from the average. This helps to filter out false positives caused by normal fluctuations in SMB traffic. This detection is important because it identifies potential SMB-based attacks, such as ransomware or data theft, which often involve a large number of SMB connections. This suggests that an attacker is attempting to exfiltrate data or spread malware within the network. Next steps include investigating the source of the traffic and determining if it is malicious. This can involve reviewing network logs, capturing and analyzing any relevant network packets, and correlating with other security events to identify the attack source and mitigate the risk. +explanation = The following analytic detects spikes in Server Message Block (SMB) traffic connections, which are used for sharing files and resources between computers. It leverages network traffic logs to monitor connections on ports 139 and 445, and SMB application usage. By calculating the average and standard deviation of SMB connections over the past 70 minutes, it identifies sources exceeding two standard deviations from the average. This activity is significant as it may indicate potential SMB-based attacks, such as ransomware or data theft. If confirmed malicious, attackers could exfiltrate data or spread malware within the network. how_to_implement = This search requires you to be ingesting your network traffic logs and populating the `Network_Traffic` data model. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.002", "T1021"], "nist": ["DE.AE"]} known_false_positives = A file server may experience high-demand loads that could cause this analytic to trigger. @@ -16019,7 +15762,7 @@ providing_technologies = null type = detection asset_type = Proxy confidence = medium -explanation = The following analytic uses tags of SSL, TLS and certificate to identify the usage of the Splunk default certificates being utilized in the environment. Recommended guidance is to utilize valid TLS certificates which documentation may be found in Splunk Docs - https://docs.splunk.com/Documentation/Splunk/8.2.6/Security/AboutsecuringyourSplunkconfigurationwithSSL. +explanation = The following analytic identifies the usage of Splunk default SSL/TLS certificates within the environment. It leverages tags such as SSL, TLS, and certificate to detect these default certificates by examining the ssl_issuer_common_name field. This activity is significant because using default certificates can expose the environment to potential security risks, as they are not unique and can be easily exploited. If confirmed malicious, attackers could intercept or manipulate data, leading to unauthorized access or data breaches. It is recommended to replace default certificates with valid, unique TLS certificates to enhance security. how_to_implement = Ingestion of SSL/TLS data is needed and to be tagged properly as ssl, tls or certificate. This data may come from a proxy, zeek, or Splunk Streams. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1040"], "nist": ["DE.AE"]} known_false_positives = False positives will not be present as it is meant to assist with identifying default certificates being utilized. @@ -16029,7 +15772,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic utilizes the Certificates Datamodel to look for punycode domains, starting with xn--, found in the SSL issuer email domain. The presence of punycode here does not equate to evil, therefore we need to decode the punycode to determine what it translates to. Remove the CyberChef recipe as needed and decode manually. Note that this is not the exact location of the malicious punycode to trip CVE-2022-3602, but a method to at least identify fuzzing occurring on these email paths. What does evil look like? it will start with +explanation = The following analytic detects SSL certificates with Punycode domains in the SSL issuer email domain, identified by the prefix "xn--". It leverages the Certificates Datamodel to flag these domains and uses CyberChef for decoding. This activity is significant as Punycode can be used for domain spoofing and phishing attacks. If confirmed malicious, attackers could deceive users and systems, potentially leading to unauthorized access and data breaches. how_to_implement = Ensure data is properly being ingested into the Certificates datamodel. If decoding the of interest, the CyberChef app is needed https://splunkbase.splunk.com/app/5348. If decoding is not needed, remove the cyberchef lines. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1573"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if the organization works with international businesses. Filter as needed. @@ -16039,7 +15782,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = The following analytic looks for allowed network traffic to The Onion Router(TOR), a benign anonymity network which can be abused for a variety of nefarious purposes. Detecting Tor traffic is paramount for upholding network security and mitigating potential threats. Tor's capacity to provide users with anonymity has been exploited by cybercriminals for activities like hacking, data breaches, and illicit content dissemination. Additionally, organizations must monitor Tor usage within their networks to ensure compliance with policies and regulations, as it can bypass conventional monitoring and filtering measures. Lastly, the ability to identify Tor traffic empowers security teams to promptly investigate and address potential security incidents, fortifying the protection of sensitive data and preserving the integrity of the network environment. +explanation = The following analytic identifies allowed network traffic to The Onion Router (TOR), an anonymity network often exploited for malicious activities. It leverages data from Next Generation Firewalls, using the Network_Traffic data model to detect traffic where the application is TOR and the action is allowed. This activity is significant as TOR can be used to bypass conventional monitoring, facilitating hacking, data breaches, and illicit content dissemination. If confirmed malicious, this could lead to unauthorized access, data exfiltration, and severe compliance violations, compromising the integrity and security of the network. how_to_implement = In order to properly run this search, Splunk needs to ingest data from Next Generation Firewalls like Palo Alto Networks Firewalls or other network control devices that mediate the traffic allowed into an environment. This is necessary so that the search can identify an 'action' taken on the traffic of interest. The search requires the Network_Traffic data model to be populated. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090", "T1090.003"], "nist": ["DE.CM"]} known_false_positives = None at this time @@ -16059,7 +15802,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This search looks for evidence of Active Directory replication traffic [MS-DRSR] from unexpected sources. This traffic is often seen exclusively between Domain Controllers for AD database replication. Any detections from non-domain controller source to a domain controller may indicate the usage of DCSync or DCShadow credential dumping techniques. +explanation = The following analytic identifies unexpected Active Directory replication traffic from non-domain controller sources. It leverages data from the Network Traffic datamodel, specifically looking for applications related to AD replication. This activity is significant because AD replication traffic should typically only occur between domain controllers. Detection of such traffic from other sources may indicate malicious activities like DCSync or DCShadow, which are used for credential dumping. If confirmed malicious, this could allow attackers to exfiltrate sensitive credentials, leading to unauthorized access and potential domain-wide compromise. how_to_implement = To successfully implement this search, you need to be ingesting application aware firewall or proxy logs into the Network Datamodel. Categorize all known domain controller Assets servers with an appropriate category for filtering. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003", "T1003.006", "T1207"], "nist": ["DE.CM"]} known_false_positives = New domain controllers or certian scripts run by administrators. @@ -16069,7 +15812,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = This detection is looking at zeek wiredata for specific replication RPC calls being performed from a device which is not a domain controller. If you would like to capture these RPC calls using Splunk Stream, please vote for my idea here https://ideas.splunk.com/ideas/APPSID-I-619 ;) +explanation = The following analytic identifies unauthorized replication RPC calls from non-domain controller devices. It leverages Zeek wire data to detect specific RPC operations like DrsReplicaAdd and DRSGetNCChanges, filtering out legitimate domain controllers. This activity is significant as it may indicate an attempt to introduce a rogue domain controller, which can compromise the integrity of the Active Directory environment. If confirmed malicious, this could allow attackers to manipulate directory data, escalate privileges, and persist within the network, posing a severe security risk. how_to_implement = Run zeek on domain controllers to capture the DCE RPC calls, ensure the domain controller categories are defined in Assets and Identities. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]} known_false_positives = None. @@ -16079,7 +15822,7 @@ providing_technologies = ["Zeek"] type = detection asset_type = Network confidence = medium -explanation = The following analytic utilizes the Zeek x509 log. Modify the zeek_x509 macro with your index and sourcetype as needed. You will need to ensure the full x509 is logged as the potentially malicious punycode is nested under subject alternative names. In this particular analytic, it will identify punycode within the subject alternative name email and other fields. Note, that OtherFields is meant to be BOOL (true,false), therefore we may never see xn-- in that field. Upon identifying punycode, manually copy and paste, or add CyberChef recipe to query, and decode the punycode manually. +explanation = The following analytic detects the presence of punycode within x509 certificates using Zeek x509 logs. It identifies punycode in the subject alternative name email and other fields by searching for the "xn--" prefix. This activity is significant as punycode can be used in phishing attacks or to bypass domain filters, posing a security risk. If confirmed malicious, attackers could use these certificates to impersonate legitimate domains, potentially leading to unauthorized access or data breaches. how_to_implement = The following analytic requires x509 certificate data to be logged entirely. In particular, for CVE-2022-3602, the punycode will be within the leaf certificate. The analytic may be modified to look for all xn--, or utilize a network IDS/monitoring tool like Zeek or Suricata to drill down into cert captured. Note for Suricata, the certificate is base64 encoded and will need to be decoded to capture the punycode (punycode will need to be decoded after). annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1573"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if the organization works with international businesses. Filter as needed. @@ -16089,7 +15832,7 @@ providing_technologies = ["Zeek"] type = detection asset_type = VPN Appliance confidence = medium -explanation = This analytic monitors access to the /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark endpoint, a key indicator for both CVE-2023-46805 and CVE-2024-21887 vulnerabilities. It detects potential vulnerabilities by looking for a 403 Forbidden response with an empty body on this endpoint. This detection method is used in both Nmap script and Project Discovery Nuclei, with the latter focusing on systems where XML mitigation for these vulnerabilities has not been applied. +explanation = The following analytic identifies access to the /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark endpoint, which is associated with CVE-2023-46805 and CVE-2024-21887 vulnerabilities. It detects this activity by monitoring for GET requests that receive a 403 Forbidden response with an empty body. This behavior is significant as it indicates potential exploitation attempts against Ivanti Connect Secure systems. If confirmed malicious, attackers could exploit these vulnerabilities to gain unauthorized access or control over the affected systems, leading to potential data breaches or system compromise. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = This analytic is limited to HTTP Status 403; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16099,7 +15842,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects potential exploitation attempts against Adobe ColdFusion vulnerabilities CVE-2023-29298 and CVE-2023-26360. These vulnerabilities pertain to an access control bypass and an arbitrary file read due to deserialization, respectively. By monitoring for requests to specific ColdFusion Administrator endpoints, especially those with an unexpected additional forward slash, the analytic identifies attempts to bypass access controls. Such behavior is crucial for a Security Operations Center (SOC) to identify, as exploitation can grant unauthorized access to ColdFusion administration endpoints, potentially leading to information leakage, brute force attacks, or further exploitation of other vulnerabilities. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the ColdFusion environment, potentially leading to data theft or other malicious activities. SOCs must be vigilant in monitoring for these patterns, ensuring timely detection and response to such threats, thus safeguarding the integrity and security of their ColdFusion deployments. +explanation = The following analytic detects potential exploitation attempts against Adobe ColdFusion vulnerabilities CVE-2023-29298 and CVE-2023-26360. It monitors requests to specific ColdFusion Administrator endpoints, especially those with an unexpected additional forward slash, using the Web datamodel. This activity is significant for a SOC as it indicates attempts to bypass access controls, which can lead to unauthorized access to ColdFusion administration endpoints. If confirmed malicious, this could result in data theft, brute force attacks, or further exploitation of other vulnerabilities, posing a serious security risk to the environment. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16109,9 +15852,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects potential exploitation of the critical Adobe ColdFusion vulnerability, CVE-2023-26360. This flaw, rooted in the deserialization of untrusted data, enables Unauthenticated Arbitrary File Read. Exploitation often targets specific ColdFusion paths, especially related to CKEditor's file manager. \ -Our analytic pinpoints exploitation by monitoring web requests to the "/cf_scripts/scripts/ajax/ckeditor/*" path. This focus helps differentiate malicious activity from standard ColdFusion traffic. For SOCs, detecting such attempts is vital given the vulnerability's CVSS score of 9.8, signaling its severity. Successful exploitation can lead to unauthorized data access, further attacks, or severe operational disruptions. \ -If a true positive arises, it indicates an active breach attempt, potentially causing data theft, operational disruption, or reputational damage. In essence, this analytic provides a targeted approach to identify attempts exploiting a high-risk ColdFusion vulnerability. While false positives may occur from legitimate accesses, any alerts should be treated as high-priority, warranting immediate investigation to ensure security. +explanation = The following analytic detects potential exploitation of the Adobe ColdFusion vulnerability, CVE-2023-26360, which allows unauthenticated arbitrary file read. It monitors web requests to the "/cf_scripts/scripts/ajax/ckeditor/*" path using the Web datamodel, focusing on specific ColdFusion paths to differentiate malicious activity from normal traffic. This activity is significant due to the vulnerability's high CVSS score of 9.8, indicating severe risk. If confirmed malicious, it could lead to unauthorized data access, further attacks, or severe operational disruptions, necessitating immediate investigation. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = In the wild, we have observed three different types of attempts that could potentially trigger false positives if the HTTP status code is not in the query. Please check this github gist for the specific URIs : https://gist.github.com/patel-bhavin/d10830f3f375a2397233f6a4fe38d5c9 . These could be legitimate requests depending on the context of your organization. Therefore, it is recommended to modify the analytic as needed to suit your specific environment. @@ -16121,7 +15862,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic identifies potential exploitation of a previously unknown vulnerability in the Web User Interface (Web UI) feature of Cisco IOS XE software (CVE-2023-20198). Successful exploitation allows an attacker to create an account on the affected device with privilege level 15 access, granting them full control of the compromised device. The detection is based on the observation of suspicious account creation and subsequent actions, including the deployment of an implant consisting of a configuration file. The implant is saved under the file path //usr//binos//conf//nginx-conf//cisco_service.conf and is not persistent, meaning a device reboot will remove it, but the newly created local user accounts remain active even after system reboots. The new user accounts have level 15 privileges, meaning they have full administrator access to the device. This privileged access to the devices and subsequent creation of new users is tracked as CVE-2023-20198. +explanation = The following analytic identifies the potential exploitation of a vulnerability (CVE-2023-20198) in the Web User Interface of Cisco IOS XE software. It detects suspicious account creation and subsequent actions, including the deployment of a non-persistent implant configuration file. The detection leverages the Web datamodel, focusing on specific URL patterns and HTTP methods. This activity is significant as it indicates unauthorized administrative access, which can lead to full control of the device. If confirmed malicious, attackers could maintain privileged access, compromising the device's integrity and security. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, restrict to Cisco IOS XE devices or perimeter appliances. Modify the analytic as needed based on hunting for successful exploitation of CVE-2023-20198. @@ -16131,10 +15872,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects attempts to exploit the Citrix Bleed vulnerability, which can lead to the leaking of session tokens. The vulnerability, identified as CVE-2023-4966, pertains to sensitive information disclosure in NetScaler ADC and NetScaler Gateway when set up as various server configurations. The analytic specifically searches for HTTP requests with a 200 status code targeting the /oauth/idp/.well-known/openid-configuration URL endpoint. By parsing web traffic and filtering based on the aforementioned criteria along with specific user agent details, HTTP method, source and destination IPs, and the sourcetype, the analytic aims to identify potentially malicious requests that fit the profile of this exploit. \ -This behavior is essential for a Security Operations Center (SOC) to identify because if successfully exploited, attackers can gain unauthorized access, leading to a potential breach or further malicious activities within the organization's network. As the Citrix Bleed vulnerability can disclose session tokens, a successful exploit can allow attackers to impersonate legitimate users, bypassing authentication mechanisms and accessing sensitive data or systems. \ -If a true positive is confirmed, it implies that an attacker is actively exploiting the vulnerability within the organization's environment. This could lead to severe consequences, including unauthorized data access, further propagation within the network, and potential disruptions or exfiltration of critical information. \ -Upon flagging such activity, it's crucial for analysts to swiftly validate the alert, assess the nature and extent of the exposure, and implement necessary measures to mitigate the threat. Reviewing the details such as user agent, source, and destination IP can help in understanding the context and intent of the attack. While it's imperative to patch vulnerable systems to prevent this exploitation, early detection through this analytic provides a valuable layer of defense, enabling timely response to thwart potential breaches. +explanation = The following analytic detects attempts to exploit the Citrix Bleed vulnerability (CVE-2023-4966), which can lead to the leaking of session tokens. It identifies HTTP requests with a 200 status code targeting the /oauth/idp/.well-known/openid-configuration URL endpoint. By parsing web traffic and filtering based on user agent details, HTTP method, source and destination IPs, and sourcetype, it aims to identify potentially malicious requests. This activity is significant for a SOC because successful exploitation can allow attackers to impersonate legitimate users, bypass authentication, and access sensitive data. If confirmed malicious, it could lead to unauthorized data access, network propagation, and critical information exfiltration. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. We recommend hunting in the environment first to understand the scope of the issue and then deploying this detection to monitor for future exploitation attempts. Limit or restrict to Citrix devices only if possible. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be present based on organization use of Citrix ADC and Gateway. Filter, or restrict the analytic to Citrix devices only. @@ -16144,10 +15882,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = This analytic is designed to assist in hunting for potential exploitation attempts against Citrix ADC in relation to CVE-2023-3519. This vulnerability, identified within Citrix ADC and NetScaler Gateway, appears to be linked with SAML processing components, with an overflow issue allowing for possible memory corruption. Preliminary findings indicate that for the exploit to be viable, SAML has to be enabled. The analytic targets POST requests to certain web endpoints which have been associated with the exploitation process. \ -Given the specific nature of the vulnerability, upon deploying this analytic it is recommended to filter and narrow the focus towards your ADC assets to reduce potential noise and improve the signal of the analytic. Please note that the exploitation of this vulnerability has been reported in the wild, therefore monitoring for potential signs of exploitation should be considered high priority. \ -The search query provided examines web data for POST requests made to specific URLs associated with the exploitation of this vulnerability. It aggregates and presents data to highlight potential exploitation attempts, taking into account elements like user agent, HTTP method, URL length, source, and destination. \ -Please be aware that this analytic is based on current understanding of the vulnerability, and adjustments may be required as more information becomes available. +explanation = The following analytic identifies potential exploitation attempts against Citrix ADC related to CVE-2023-3519. It detects POST requests to specific web endpoints associated with this vulnerability by leveraging the Web datamodel. This activity is significant as CVE-2023-3519 involves a SAML processing overflow issue that can lead to memory corruption, posing a high risk. If confirmed malicious, attackers could exploit this to execute arbitrary code, escalate privileges, or disrupt services, making it crucial for SOC analysts to monitor and investigate these alerts promptly. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} known_false_positives = False positives may be present based on organization use of SAML utilities. Filter, or restrict the analytic to Citrix devices only. @@ -16157,10 +15892,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects a potentially malicious file upload attempt to Documentum, an enterprise content management platform, via specific suspicious URLs and the HTTP POST method. This detection occurs through pattern recognition within the datamodel=Web, focusing on URL patterns that follow "/documentum/upload.aspx?parentid=", "/documentum/upload.aspx?filename=", "/documentum/upload.aspx?uploadId=*", combined with the HTTP POST method, indicative of a file upload attempt. \ -This behavior is significant for a Security Operations Center (SOC) to identify, as it can signify a potential attack vector. Malicious actors might use this method to upload a harmful script or other exploitable content to Documentum, thereby establishing a foothold in the environment, spreading malware, or enabling further exploitation. \ -The impact of this behavior, if a true positive, can be quite significant. An attacker could compromise the Documentum application, manipulate or steal sensitive content, and potentially gain unauthorized access to other system resources. An intrusion of this nature could disrupt business operations, result in data breaches, and even damage the organization's reputation. \ -However, it's important to note that false positives may occur. For example, legitimate but uncommon file uploads might match these URL patterns. It's crucial to verify any alerts generated by this analytic to ensure accurate threat detection. This analytic provides critical insights into potential attack attempts and assists in maintaining the integrity and security of enterprise content management systems like Documentum. +explanation = The following analytic detects potentially malicious file upload attempts to Citrix ShareFile via specific suspicious URLs and the HTTP POST method. It leverages the Web datamodel to identify URL patterns such as "/documentum/upload.aspx?parentid=", "/documentum/upload.aspx?filename=", and "/documentum/upload.aspx?uploadId=*", combined with the HTTP POST method. This activity is significant for a SOC as it may indicate an attempt to upload harmful scripts or content, potentially compromising the Documentum application. If confirmed malicious, this could lead to unauthorized access, data breaches, and operational disruptions. how_to_implement = Dependent upon the placement of the ShareFile application, ensure the latest Technology Add-On is eneabled. This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. The ShareFile application is IIS based, therefore ingesting IIS logs and reviewing for the same pattern would identify this activity, successful or not. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} known_false_positives = False positives may be present, filtering may be needed. Also, restricting to known web servers running IIS or ShareFile will change this from Hunting to TTP. @@ -16170,7 +15902,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false* and /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=0& URLs. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise. +explanation = The following analytic identifies potential exploitation attempts of the Confluence CVE-2023-22515 vulnerability. It detects successful accesses (HTTP status 200) to specific vulnerable endpoints by analyzing web logs within the Splunk 'Web' Data Model. This activity is significant for a SOC as it indicates possible privilege escalation attempts in Confluence. If confirmed malicious, attackers could gain unauthorized access or create accounts with escalated privileges, leading to potential data breaches or further exploitation within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. Tested with Suricata and nginx:plus:kv. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to Confluence servers. @@ -16180,7 +15912,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /setup/*.action* URL pattern. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise. +explanation = The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, specifically targeting the /setup/*.action* URL pattern. It leverages web logs within the Splunk 'Web' Data Model, filtering for successful accesses (HTTP status 200) to these endpoints. This activity is significant as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. If confirmed malicious, it could result in unauthorized access or account creation with escalated privileges, leading to potential data breaches or further exploitation within the environment. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to confluence servers. @@ -16190,7 +15922,7 @@ providing_technologies = null type = detection asset_type = Web Application confidence = medium -explanation = This analytic identifies a critical template injection vulnerability (CVE-2023-22527) in outdated versions of Confluence Data Center and Server, which allows an unauthenticated attacker to execute arbitrary code remotely. The vulnerability is exploited by injecting OGNL (Object-Graph Navigation Language) expressions into the application, as evidenced by POST requests to the "/template/aui/text-inline.vm" endpoint with specific content types and payloads. The search looks for POST requests with HTTP status codes 200 or 202, which may indicate successful exploitation attempts. Immediate patching to the latest version of Confluence is strongly recommended, as there are no known workarounds. This detection is crucial for identifying and responding to potential RCE attacks, ensuring that affected Confluence instances are secured against this critical threat. +explanation = The following analytic identifies attempts to exploit a critical template injection vulnerability (CVE-2023-22527) in outdated Confluence Data Center and Server versions. It detects POST requests to the "/template/aui/text-inline.vm" endpoint with HTTP status codes 200 or 202, indicating potential OGNL injection attacks. This activity is significant as it allows unauthenticated attackers to execute arbitrary code remotely. If confirmed malicious, attackers could gain full control over the affected Confluence instance, leading to data breaches, system compromise, and further network infiltration. Immediate patching is essential to mitigate this threat. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to confluence servers. @@ -16200,7 +15932,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic assists with identifying CVE-2022-26134 based exploitation utilizing the Web datamodel to cover network and CIM compliant web logs. The parameters were captured from live scanning and the POC provided by Rapid7. This analytic is written against multiple proof of concept codes released and seen in the wild (scanning). During triage, review any endpoint based logs for further activity including writing a jsp file to disk and commands/processes spawning running as root from the Confluence process. +explanation = The following analytic detects attempts to exploit CVE-2022-26134, an unauthenticated remote code execution vulnerability in Confluence. It leverages the Web datamodel to analyze network and CIM-compliant web logs, identifying suspicious URL patterns and parameters indicative of exploitation attempts. This activity is significant as it allows attackers to execute arbitrary code on the Confluence server without authentication, potentially leading to full system compromise. If confirmed malicious, this could result in unauthorized access, data exfiltration, and further lateral movement within the network. Immediate investigation and remediation are crucial to prevent extensive damage. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx. In addition, network based logs or event data like PAN Threat. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Tune based on assets if possible, or restrict to known Confluence servers. Remove the ${ for a more broad query. To identify more exec, remove everything up to the last parameter (Runtime().exec) for a broad query. @@ -16210,7 +15942,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +explanation = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows attackers to bypass authentication via an alternate path or channel. It leverages web request logs to identify access to the SetupWizard.aspx page, indicating potential exploitation. This activity is significant as it can lead to unauthorized administrative access and remote code execution. If confirmed malicious, attackers could create administrative users and gain full control over the affected system, posing severe security risks. Immediate remediation by updating to version 23.9.8 or above is recommended. how_to_implement = To implement this analytic, ensure proper logging is occurring with IIS, Apache, or a Proxy server and that these logs are being ingested into Splunk. The analytic was written against Suricata. The proper TA will need to be enabled and should be mapped to CIM and the Web datamodel. Ingestion of the data source is required to utilize this detection. In addition, if it is not mapped to the datamodel, modify the query for your application logs to look for requests the same URI and investigate further. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise. @@ -16250,7 +15982,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic detects when a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +explanation = The following analytic detects the execution of known remote access software within the environment. It leverages network logs mapped to the Web data model, identifying specific URLs and user agents associated with remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use these utilities to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or further compromise the network, posing a severe security risk. how_to_implement = The detection is based on data that originates from network logs. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network logs. The logs must also be mapped to the `Web` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. @@ -16260,7 +15992,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies activity related to Text4Shell, or the critical vulnerability CVE-2022-42889 in Apache Commons Text Library. Apache Commons Text versions 1.5 through 1.9 are affected, but it has been patched in version 1.10. The analytic may need to be tuned for your environment before enabling as a TTP, or direct Notable. Apache Commons Text is a Java library described as a library focused on algorithms working on strings. We can see it as a general-purpose text manipulation toolkit. This vulnerability affects the StringSubstitutor interpolator class, which is included in the Commons Text library. A default interpolator allows for string lookups that can lead to Remote Code Execution. This is due to a logic flaw that makes the script, dns, and url lookup keys interpolated by default, as opposed to what it should be, according to the documentation of the StringLookupFactory class. Those keys allow an attacker to execute arbitrary code via lookups. +explanation = The following analytic detects attempts to exploit the CVE-2022-42889 vulnerability in the Apache Commons Text Library, known as Text4Shell. It leverages the Web datamodel to identify suspicious HTTP requests containing specific lookup keys (url, dns, script) that can lead to Remote Code Execution (RCE). This activity is significant as it targets a critical vulnerability that can allow attackers to execute arbitrary code on the server. If confirmed malicious, this could lead to full system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = To implement, one must be collecting network traffic that is normalized in CIM and able to be queried via the Web datamodel. Or, take the chunks out needed and tie to a specific network source type to hunt in. Tune as needed, or remove the other_lookups statement. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = False positives are present when the values are set to 1 for utf and lookup. It's possible to raise this to TTP (direct notable) if removal of other_lookups occur and Score is raised to 2 (down from 4). @@ -16280,7 +16012,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = The following analytic is designed to detect attempts to exploit the CVE-2023-46747 vulnerability, a critical authentication bypass flaw in F5 BIG-IP that can lead to unauthenticated remote code execution (RCE). This vulnerability specifically affects the BIG-IP Configuration utility (TMUI) and has been assigned a high severity CVSSv3 score of 9.8. The analytic identifies this behavior by monitoring for a specific URI path - "*/mgmt/tm/auth/user/*", with the PATCH method and 200 status. Additional URI's will occur around the same time include "*/mgmt/shared/authn/login*" and "*/tmui/login.jsp*", which are associated with the exploitation of this vulnerability. This behavior is significant for a Security Operations Center (SOC) as it indicates an attempt to bypass authentication mechanisms, potentially leading to unauthorized access and control over the system. If a true positive is identified, it suggests that an attacker is attempting to exploit a known vulnerability to gain unauthorized access and execute arbitrary code, which could lead to data theft, system disruption, or further malicious activities within the network. +explanation = The following analytic detects attempts to exploit the CVE-2023-46747 vulnerability, an authentication bypass flaw in F5 BIG-IP's Configuration utility (TMUI). It identifies this activity by monitoring for specific URI paths such as "*/mgmt/tm/auth/user/*" with the PATCH method and a 200 status code. This behavior is significant for a SOC as it indicates potential unauthorized access attempts, leading to remote code execution. If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary code, steal data, disrupt systems, or conduct further malicious activities within the network. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relevant for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited to as this is strict to active exploitation. Reduce noise by filtering to F5 devices with TMUI enabled or filter data as needed. @@ -16290,11 +16022,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = CVE-2022-40684 is a Fortinet appliance auth bypass that is actively being exploited and a POC is released publicy. The POC adds a SSH key to the appliance. Note that the exploit can be used with any HTTP method (GET, POST, PUT, DELETE, etc). The REST API request failing is not an indication that an attacker was unsuccessful. Horizon3 was able to modify the admin SSH keys though a REST API request that reportedly failed. The collection /api/v2/ endpoints can be used to configure the system and modify the administrator user. Any logs found that meet the above conditions and also have a URL containing /api/v2/ should be cause for concern. Further investigation of any matching log entries can reveal any damage an attack has done. Additionally, an attacker may perform the following actions to further compromise a system Modify the admin SSH key to enable the attacker to login to the compromised system. \ -Add new local users. \ -Update networking configurations to reroute traffic. \ -Download the system configuration. \ -Initiate packet captures to capture other sensitive system information. Reference Horizon3.ai +explanation = The following analytic detects attempts to exploit CVE-2022-40684, a Fortinet appliance authentication bypass vulnerability. It identifies REST API requests to the /api/v2/ endpoint using various HTTP methods (GET, POST, PUT, DELETE) that may indicate unauthorized modifications, such as adding SSH keys or creating new users. This detection leverages the Web datamodel to monitor specific URL patterns and HTTP methods. This activity is significant as it can lead to unauthorized access and control over the appliance. If confirmed malicious, attackers could gain persistent access, reroute network traffic, or capture sensitive information. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache. Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = GET requests will be noisy and need to be filtered out or removed from the query based on volume. Restrict analytic to known publically facing Fortigates, or run analytic as a Hunt until properly tuned. It is also possible the user agent may be filtered on Report Runner or Node.js only for the exploit, however, it is unknown at this if other user agents may be used. @@ -16304,17 +16032,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following hunting query assists with quickly assessing CVE-2021-44228, or Log4Shell, activity mapped to the Web Datamodel. This is a combination query attempting to identify, score and dashboard. Because the Log4Shell vulnerability requires the string to be in the logs, this will work to identify the activity anywhere in the HTTP headers using _raw. Modify the first line to use the same pattern matching against other log sources. Scoring is based on a simple rubric of 0-5. 5 being the best match, and less than 5 meant to identify additional patterns that will equate to a higher total score. \ -The first jndi match identifies the standard pattern of `{jndi:` \ -jndi_fastmatch is meant to identify any jndi in the logs. The score is set low and is meant to be the "base" score used later. \ -jndi_proto is a protocol match that identifies `jndi` and one of `ldap, ldaps, rmi, dns, nis, iiop, corba, nds, http, https.` \ -all_match is a very well written regex by https://gist.github.com/Schvenn that identifies nearly all patterns of this attack behavior. \ -env works to identify environment variables in the header, meant to capture `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `env`. \ -uri_detect is string match looking for the common uri paths currently being scanned/abused in the wild. \ -keywords matches on enumerated values that, like `$ctx:loginId`, that may be found in the header used by the adversary. \ -lookup matching is meant to catch some basic obfuscation that has been identified using upper, lower and date. \ -Scoring will then occur based on any findings. The base score is meant to be 2 , created by jndi_fastmatch. Everything else is meant to increase that score. \ -Finally, a simple table is created to show the scoring and the _raw field. Sort based on score or columns of interest. +explanation = The following analytic detects potential exploitation attempts of the Log4Shell vulnerability (CVE-2021-44228) by analyzing HTTP headers for specific patterns. It leverages the Web Datamodel and evaluates various indicators such as the presence of `{jndi:`, environment variables, and common URI paths. This detection is significant as Log4Shell allows remote code execution, posing a severe threat to systems. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, and potentially compromise sensitive data, leading to extensive damage and data breaches. how_to_implement = Out of the box, the Web datamodel is required to be pre-filled. However, tested was performed against raw httpd access logs. Change the first line to any dataset to pass the regex's against. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = It is highly possible you will find false positives, however, the base score is set to 2 for _any_ jndi found in raw logs. tune and change as needed, include any filtering. @@ -16324,7 +16042,7 @@ providing_technologies = null type = detection asset_type = VPN Appliance confidence = medium -explanation = This analytic is designed to identify the exploit phase of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a POST request is made to the /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection URI. This request exploits the command injection vulnerability to execute arbitrary commands. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable. +explanation = The following analytic identifies attempts to exploit the CVE-2023-46805 and CVE-2024-21887 vulnerabilities in Ivanti Connect Secure. It detects POST requests to specific URIs that leverage command injection to execute arbitrary commands. The detection uses the Web datamodel to monitor for these requests and checks for a 200 OK response, indicating a successful exploit attempt. This activity is significant as it can lead to unauthorized command execution on the server. If confirmed malicious, attackers could gain control over the system, leading to potential data breaches or further network compromise. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16334,7 +16052,7 @@ providing_technologies = null type = detection asset_type = VPN Appliance confidence = medium -explanation = The following analytic is designed to identify POST request activities targeting specific endpoints known to be vulnerable to the SSRF issue (CVE-2024-21893) in Ivanti's products. It aggregates data from the Web data model, focusing on endpoints /dana-ws/saml20.ws, /dana-ws/saml.ws, /dana-ws/samlecp.ws, and /dana-na/auth/saml-logout.cgi. The query filters for POST requests that received a HTTP 200 OK response, indicating successful request execution. +explanation = The following analytic identifies POST requests targeting endpoints vulnerable to the SSRF issue (CVE-2024-21893) in Ivanti's products. It leverages the Web data model, focusing on endpoints such as /dana-ws/saml20.ws, /dana-ws/saml.ws, /dana-ws/samlecp.ws, and /dana-na/auth/saml-logout.cgi. The detection filters for POST requests that received an HTTP 200 OK response, indicating successful execution. This activity is significant as it may indicate an attempt to exploit SSRF vulnerabilities, potentially allowing attackers to access internal services or sensitive data. If confirmed malicious, this could lead to unauthorized access and data exfiltration. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the HTTP Status is removed, as most failed attempts result in a 301. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16344,7 +16062,7 @@ providing_technologies = null type = detection asset_type = VPN Appliance confidence = medium -explanation = This analytic is designed to identify the "check phase" of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a GET request is made to the /api/v1/totp/user-backup-code/../../system/system-information URI. This request exploits the authentication bypass vulnerability to gain access to system information. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable. +explanation = The following analytic identifies attempts to exploit the CVE-2023-46805 and CVE-2024-21887 vulnerabilities in Ivanti Connect Secure. It detects GET requests to the /api/v1/totp/user-backup-code/../../system/system-information URI, which leverage an authentication bypass to access system information. The detection uses the Web datamodel to identify requests with a 200 OK response, indicating a successful exploit attempt. This activity is significant as it reveals potential unauthorized access to sensitive system information. If confirmed malicious, attackers could gain critical insights into the system, facilitating further exploitation and compromise. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16354,7 +16072,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The given analytic is designed to detect the exploitation of CVE-2023-35078, a vulnerability in Ivanti Endpoint Manager Mobile (EPMM) affecting versions up to 11.4. Specifically, the query searches web logs for HTTP requests to the potentially vulnerable endpoint "/mifs/aad/api/v2/authorized/users?*" with a successful status code of 200. This analytic is instrumental in detecting unauthorized remote access to restricted functionalities or resources within the application, a behavior worth identifying for a Security Operations Center (SOC). By monitoring specific patterns and successful access indicators, it reveals an active attempt to exploit the vulnerability, potentially leading to data theft, unauthorized modifications, or further system compromise. If successfully executed, the impact can be severe, necessitating immediate action. +explanation = The following analytic detects attempts to exploit CVE-2023-35078, a vulnerability in Ivanti Endpoint Manager Mobile (EPMM) versions up to 11.4. It identifies HTTP requests to the endpoint "/mifs/aad/api/v2/authorized/users?*" with a status code of 200 in web logs. This activity is significant as it indicates unauthorized remote access to restricted functionalities or resources. If confirmed malicious, this could lead to data theft, unauthorized modifications, or further system compromise, necessitating immediate action to mitigate potential severe impacts. how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = The Proof of Concept exploit script indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search. If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability. @@ -16364,7 +16082,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects potential unauthorized access attempts exploiting CVE-2023-35082 within Ivantis software products. Initially assessed to affect only MobileIron Core versions up to 11.2, further insights revealed its influence extending to Ivanti Endpoint Manager Mobile (EPMM) versions 11.10, 11.9, 11.8, and MobileIron Core 11.7 and below. The vulnerability facilitates unauthorized API access via the specific URI path /mifs/asfV3/api/v2/. The analytic identifies this behavior by monitoring web access logs for this URI pattern coupled with a HTTP 200 response code, signifying successful unauthorized access. Such behavior is imperative for a Security Operations Center (SOC) to recognize, as it highlights potential security breaches which, if not addressed, could lead to unauthorized data access, system modifications, or further exploitation. In the event of a true positive, the implications are severe: an attacker might have gained unbridled access to sensitive organizational data or could modify systems maliciously. Be vigilant of potential false positives; benign activities might occasionally match the pattern. During triage, closely scrutinize the source of the access request and its subsequent actions. This analytic aids analysts in early threat detection, allowing for proactive risk mitigation. +explanation = The following analytic detects potential unauthorized access attempts exploiting CVE-2023-35082 within Ivanti's software products. It identifies access to the specific URI path /mifs/asfV3/api/v2/ with an HTTP 200 response code in web access logs, indicating successful unauthorized access. This activity is significant for a SOC as it highlights potential security breaches that could lead to unauthorized data access or system modifications. If confirmed malicious, an attacker could gain unbridled access to sensitive organizational data or modify systems maliciously, posing severe security risks. how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = Similar to CVE-2023-35078, the path for exploitation indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search. If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability. @@ -16374,7 +16092,7 @@ providing_technologies = null type = detection asset_type = Network confidence = medium -explanation = This analytic is designed to detect unauthenticated access to the System Manager Portal in Ivanti Sentry, formerly known as MobileIron Sentry. The vulnerability, designated as CVE-2023-38035, affects all supported versions 9.18, 9.17, and 9.16, as well as older versions. The analytic works by monitoring for changes in the configuration of Sentry and the underlying operating system. Such changes could indicate an attacker attempting to execute OS commands as root. This behavior is of significant concern for a Security Operations Center (SOC) as it presents a substantial security risk, particularly if port 8443, the default port for the System Manager Portal, is exposed to the internet. If the analytic returns a true positive, it suggests that an attacker has gained unauthorized access to the Sentry system, potentially leading to a significant system compromise and data breach. It is important to note that while the issue has a high CVSS score, the risk of exploitation is low for customers who do not expose port 8443 to the internet. The search specifically looks for HTTP requests to certain endpoints ("/mics/services/configservice/*", "/mics/services/*","/mics/services/MICSLogService*") and HTTP status code of 200. Unusual or unexpected patterns in these parameters could indicate an attack. +explanation = The following analytic identifies unauthenticated access attempts to the System Manager Portal in Ivanti Sentry, exploiting CVE-2023-38035. It detects this activity by monitoring HTTP requests to specific endpoints ("/mics/services/configservice/*", "/mics/services/*", "/mics/services/MICSLogService*") with a status code of 200. This behavior is significant for a SOC as it indicates potential unauthorized access, which could lead to OS command execution as root. If confirmed malicious, this activity could result in significant system compromise and data breaches, especially if port 8443 is exposed to the internet. how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = It is important to note that false positives may occur if the search criteria are expanded beyond the HTTP status code 200. In other words, if the search includes other HTTP status codes, the likelihood of encountering false positives increases. This is due to the fact that HTTP status codes other than 200 may not necessarily indicate a successful exploitation attempt. @@ -16384,7 +16102,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analtyic identifies a Jenkins Arbitrary File Read CVE-2024-23897 exploitation. This attack allows an attacker to read arbitrary files on the Jenkins server. This can be used to obtain sensitive information such as credentials, private keys, and other sensitive information. +explanation = The following analytic identifies attempts to exploit Jenkins Arbitrary File Read CVE-2024-23897. It detects HTTP POST requests to Jenkins URLs containing "*/cli?remoting=false*" with a 200 status code. This activity is significant as it indicates potential unauthorized access to sensitive files on the Jenkins server, such as credentials and private keys. If confirmed malicious, this could lead to severe data breaches, unauthorized access, and further exploitation within the environment. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. If unable to utilize the Web datamodel, modify query to your data source. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives should be limited as this detection is based on a specific URL path and HTTP status code. Adjust the search as necessary to fit the environment. @@ -16394,7 +16112,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution. Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures. +explanation = The following analytic identifies attempts to exploit the JetBrains TeamCity Authentication Bypass vulnerability (CVE-2024-27198). It detects suspicious POST requests to the `/app/rest/users` and `/app/rest/users/id:1/tokens` endpoints, which are indicative of attempts to create new administrator users or generate admin access tokens without authentication. This detection leverages the Web datamodel and CIM-compliant log sources, such as Nginx or TeamCity logs. This activity is significant as it can lead to full control over the TeamCity server, including all projects, builds, agents, and artifacts. If confirmed malicious, attackers could gain unauthorized administrative access, leading to severe security breaches. how_to_implement = The detection relies on the Web datamodel and a CIM compliant log source, that may include Nginx, TeamCity logs, or other web server logs. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources. @@ -16404,7 +16122,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution.Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures. +explanation = The following analytic detects attempts to exploit the CVE-2024-27198 vulnerability in JetBrains TeamCity on-premises servers, which allows attackers to bypass authentication mechanisms. It leverages Suricata HTTP traffic logs to identify suspicious POST requests to the `/app/rest/users` and `/app/rest/users/id:1/tokens` endpoints. This activity is significant because it can lead to unauthorized administrative access, enabling attackers to gain full control over the TeamCity server, including projects, builds, agents, and artifacts. If confirmed malicious, this could result in severe security breaches and compromise the integrity of the development environment. how_to_implement = The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources. @@ -16414,7 +16132,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = CVE-2024-27199 reveals a critical vulnerability in JetBrains TeamCity web server, allowing unauthenticated attackers to bypass authentication for a limited set of endpoints. This vulnerability exploits path traversal issues, enabling attackers to access and potentially modify system settings or disclose sensitive server information without proper authentication. Identified vulnerable paths include /res/, /update/, and /.well-known/acme-challenge/, among others. Attackers can manipulate these paths to reach restricted JSP pages and servlet endpoints, such as /app/https/settings/uploadCertificate, which could allow for the uploading of malicious HTTPS certificates or modification of server settings. This detection aims to identify potential exploitation attempts by monitoring for unusual access patterns to these endpoints, which could indicate an authentication bypass attempt in progress. +explanation = The following analytic identifies attempts to exploit CVE-2024-27199, a critical vulnerability in JetBrains TeamCity web server, allowing unauthenticated access to specific endpoints. It detects unusual access patterns to vulnerable paths such as /res/, /update/, and /.well-known/acme-challenge/ by monitoring HTTP traffic logs via Suricata. This activity is significant as it could indicate an attacker bypassing authentication to access or modify system settings. If confirmed malicious, this could lead to unauthorized changes, disclosure of sensitive information, or uploading of malicious certificates, severely compromising the server's security. how_to_implement = The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, however, monitor, filter, and tune as needed based on organization log sources. The analytic is restricted to 200 and GET requests to specific URI paths, which should limit false positives. @@ -16424,7 +16142,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is designed to detect attempts to exploit the CVE-2023-42793 vulnerability in TeamCity On-Premises. It focuses on identifying suspicious POST requests to /app/rest/users/id:1/tokens/RPC2, which is the initial point of exploitation. This could indicate an unauthenticated attacker trying to gain administrative access through Remote Code Execution (RCE). +explanation = The following analytic detects attempts to exploit the CVE-2023-42793 vulnerability in JetBrains TeamCity On-Premises. It identifies suspicious POST requests to /app/rest/users/id:1/tokens/RPC2, leveraging the Web datamodel to monitor specific URL patterns and HTTP methods. This activity is significant as it may indicate an unauthenticated attacker attempting to gain administrative access via Remote Code Execution (RCE). If confirmed malicious, this could allow the attacker to execute arbitrary code, potentially compromising the entire TeamCity environment and leading to further unauthorized access and data breaches. how_to_implement = The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = If TeamCity is not in use, this analytic will not return results. Monitor and tune for your environment. @@ -16434,7 +16152,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects the exploitation of a remote code execution vulnerability in Juniper Networks devices. The vulnerability involves multiple steps, including uploading a malicious PHP file and an INI file to the target server, and then executing the PHP code by manipulating the PHP configuration via the uploaded INI file. The analytic specifically looks for requests to /webauth_operation.php?PHPRC=*, which are used to upload the files and execute the code, respectively. This behavior is worth identifying for a SOC because it indicates that an attacker is attempting to exploit the vulnerability to gain unauthorized access to the device and execute arbitrary code. If a true positive is found, it suggests that an attacker has successfully exploited the vulnerability and may have gained control over the device, leading to data theft, network compromise, or other damaging outcomes. Upon triage, review the request parameters and the response to determine if the exploitation was successful. Capture and inspect any relevant network traffic and server logs to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks. +explanation = The following analytic detects attempts to exploit a remote code execution vulnerability in Juniper Networks devices. It identifies requests to /webauth_operation.php?PHPRC=*, which are indicative of uploading and executing malicious PHP files. This detection leverages the Web data model, focusing on specific URL patterns and HTTP status codes. This activity is significant because it signals an attempt to gain unauthorized access and execute arbitrary code on the device. If confirmed malicious, the attacker could gain control over the device, leading to data theft, network compromise, or other severe consequences. how_to_implement = To implement this search, ensure that the Web data model is populated. The search is activated when the Web data model is accelerated. Network products, such as Suricata or Palo Alto, need to be mapped to the Web data model. Adjust the mapping as necessary to suit your specific products. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control", "Delivery", "Installation"], "mitre_attack": ["T1190", "T1105", "T1059"], "nist": ["DE.CM"]} known_false_positives = Be aware of potential false positives - legitimate uses of the /webauth_operation.php endpoint may cause benign activities to be flagged.The URL in the analytic is specific to a successful attempt to exploit the vulnerability. Review contents of the HTTP body to determine if the request is malicious. If the request is benign, add the URL to the whitelist or continue to monitor. @@ -16444,7 +16162,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = CVE-2021-44228 Log4Shell payloads can be injected via various methods, but on of the most common vectors injection is via Web calls. Many of the vulnerable java web applications that are using log4j have a web component to them are specially targets of this injection, specifically projects like Apache Struts, Flink, Druid, and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against vulnerable web applications the invocation can be seen in various part of web logs. Specifically it has been successfully exploited via headers like X-Forwarded-For, User-Agent, Referer, and X-Api-Version. In this detection we first limit the scope of our search to the Web Datamodel and use the `| from datamodel` function to benefit from schema accelerated searching capabilities, mainly because the second part of the detection is pretty heavy, it runs a regex across all _raw events that looks for `${jndi:ldap://` pattern across all potential web fields available to the raw data, like http headers for example. If you see results for this detection, it means that there was a attempt at a injection, which could be a reconnaissance activity or a valid expliotation attempt, but this does not exactly mean that the host was indeed successfully exploited. +explanation = The following analytic identifies attempts to inject Log4Shell JNDI payloads via web calls. It leverages the Web datamodel and uses regex to detect patterns like `${jndi:ldap://` in raw web event data, including HTTP headers. This activity is significant because it targets vulnerabilities in Java web applications using Log4j, such as Apache Struts and Solr. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to full system compromise. Immediate investigation is required to determine if the attempt was successful and to mitigate any potential exploitation. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = If there is a vulnerablility scannner looking for log4shells this will trigger, otherwise likely to have low false positives. @@ -16454,7 +16172,7 @@ providing_technologies = null type = detection asset_type = Endpoint confidence = medium -explanation = CVE-2021-44228 Log4Shell payloads can be injected via various methods, but on of the most common vectors injection is via Web calls. Many of the vulnerable java web applications that are using log4j have a web component to them are specially targets of this injection, specifically projects like Apache Struts, Flink, Druid, and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against vulnerable web applications the invocation can be seen in various part of web logs. Specifically it has been successfully exploited via headers like X-Forwarded-For, User-Agent, Referer, and X-Api-Version. In this detection we match the invocation function with a network connection to a malicious ip address. +explanation = The following analytic detects Log4Shell JNDI payload injections via outbound connections. It identifies suspicious LDAP lookup functions in web logs, such as `${jndi:ldap://PAYLOAD_INJECTED}`, and correlates them with network traffic to known malicious IP addresses. This detection leverages the Web and Network_Traffic data models in Splunk. Monitoring this activity is crucial as it targets vulnerabilities in Java web applications using log4j, potentially leading to remote code execution. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, and compromise sensitive data within the affected environment. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = If there is a vulnerablility scannner looking for log4shells this will trigger, otherwise likely to have low false positives. @@ -16464,7 +16182,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects potential exploitation attempts against Microsoft SharePoint Server vulnerability CVE-2023-29357. This vulnerability pertains to an elevation of privilege due to improper handling of authentication tokens. By monitoring for suspicious activities related to SharePoint Server, the analytic identifies attempts to exploit this vulnerability. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the SharePoint environment, potentially leading to data theft or other malicious activities. +explanation = The following analytic detects potential exploitation attempts against Microsoft SharePoint Server vulnerability CVE-2023-29357. It leverages the Web datamodel to monitor for specific API calls and HTTP methods indicative of privilege escalation attempts. This activity is significant as it may indicate an attacker is trying to gain unauthorized privileged access to the SharePoint environment. If confirmed malicious, the impact could include unauthorized access to sensitive data, potential data theft, and further compromise of the SharePoint server, leading to a broader security breach. how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Microsoft SharePoint. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} known_false_positives = False positives may occur if there are legitimate activities that mimic the exploitation pattern. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment. @@ -16484,7 +16202,7 @@ providing_technologies = null type = detection asset_type = Web Proxy confidence = medium -explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +explanation = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows attackers to bypass authentication via alternate paths or channels. It leverages Nginx access logs to identify web requests to the SetupWizard.aspx page, indicating potential exploitation. This activity is significant as it can lead to unauthorized administrative access and remote code execution. If confirmed malicious, attackers could create administrative users and gain full control over the affected ScreenConnect instance, posing severe security risks. Immediate remediation by updating to version 23.9.8 or above is recommended. how_to_implement = To implement this analytic, ensure proper logging is occurring with Nginx, access.log and error.log, and that these logs are being ingested into Splunk. STRT utilizes this nginx.conf https://gist.github.com/MHaggis/26f59108b04da8f1d870c9cc3a3c8eec to properly log as much data with Nginx. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise. @@ -16494,7 +16212,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is designed to detect potential exploitation attempts on publicly accessible PaperCut NG servers. It identifies connections from public IP addresses to the server and specifically monitors for URI paths commonly found in proof-of-concept (POC) scripts for exploiting PaperCut NG vulnerabilities. These URI paths have been observed in both Metasploit modules and standalone scripts used for attacking PaperCut NG servers. When a public IP address is detected accessing one or more of these suspicious URI paths, an alert may be generated to notify the security team of the potential threat. The team can then investigate the source IP address, the targeted PaperCut NG server, and any other relevant information to determine the nature of the activity and take appropriate actions to mitigate the risk. +explanation = The following analytic detects potential exploitation attempts on publicly accessible PaperCut NG servers. It identifies connections from public IP addresses to the server, specifically monitoring URI paths commonly used in proof-of-concept scripts for exploiting PaperCut NG vulnerabilities. This detection leverages web traffic data from the `Web` datamodel, focusing on specific URI paths and excluding internal IP ranges. This activity is significant as it may indicate an attempt to exploit known vulnerabilities in PaperCut NG, potentially leading to unauthorized access or control of the server. If confirmed malicious, attackers could gain administrative access, leading to data breaches or further network compromise. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may be present, filter as needed. @@ -16504,7 +16222,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following correlation will identify activity related to Windows Exchange being actively exploited by adversaries related to ProxyShell or ProxyNotShell. In addition, the analytic correlates post-exploitation Cobalt Strike analytic story. Common post-exploitation behavior has been seen in the wild includes adversaries running nltest, Cobalt Strike, Mimikatz and adding a new user. The correlation specifically looks for 5 distinct analyticstories to trigger. Modify or tune as needed for your organization. 5 analytics is an arbitrary number but was chosen to reduce the amount of noise but also require the 2 analytic stories or a ProxyShell and CobaltStrike to fire. Adversaries will exploit the vulnerable Exchange server, abuse SSRF, drop a web shell, utilize the PowerShell Exchange modules and begin post-exploitation. +explanation = The following analytic identifies potential exploitation of Windows Exchange servers via ProxyShell or ProxyNotShell vulnerabilities, followed by post-exploitation activities such as running nltest, Cobalt Strike, Mimikatz, and adding new users. It leverages data from multiple analytic stories, requiring at least five distinct sources to trigger, thus reducing noise. This activity is significant as it indicates a high likelihood of an active compromise, potentially leading to unauthorized access, privilege escalation, and persistent threats within the environment. If confirmed malicious, attackers could gain control over the Exchange server, exfiltrate data, and maintain long-term access. how_to_implement = To implement this correlation, you will need to enable ProxyShell, ProxyNotShell and Cobalt Strike analytic stories (the anaytics themselves) and ensure proper data is being collected for Web and Endpoint datamodels. Run the correlation rule seperately to validate it is not triggering too much or generating incorrectly. Validate by running ProxyShell POC code and Cobalt Strike behavior. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = False positives will be limited, however tune or modify the query as needed. @@ -16514,7 +16232,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is static indicators related to CVE-2022-22963, Spring4Shell. The 3 indicators provide an amount of fidelity that source IP is attemping to exploit a web shell on the destination. The filename and cmd are arbitrary in this exploitation. Java will write a JSP to disk and a process will spawn from Java based on the cmd passed. This is indicative of typical web shell activity. +explanation = The following analytic detects attempts to exploit the Spring4Shell vulnerability (CVE-2022-22963) by identifying specific URL patterns associated with web shell payloads. It leverages web traffic data, focusing on HTTP GET requests with URLs containing indicators like "tomcatwar.jsp," "poc.jsp," and "shell.jsp." This activity is significant as it suggests an attacker is trying to deploy a web shell, which can lead to remote code execution. If confirmed malicious, this could allow the attacker to gain persistent access, execute arbitrary commands, and potentially escalate privileges within the compromised environment. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = The jsp file names are static names used in current proof of concept code. = @@ -16524,7 +16242,7 @@ providing_technologies = null type = detection asset_type = Database Server confidence = medium -explanation = The following analytic detects long URLs that contain multiple SQL commands. A proactive approach helps to detect and respond to potential threats earlier, mitigating the risks associated with SQL injection attacks. This detection is made by a Splunk query that searches for web traffic data where the destination category is a web server and the URL length is greater than 1024 characters or the HTTP user agent length is greater than 200 characters. This detection is important because it suggests that an attacker is attempting to exploit a web application through SQL injection. SQL injection is a common technique used by attackers to exploit vulnerabilities in web applications and gain unauthorized access to databases. Attackers can insert malicious SQL commands into a URL to manipulate the application's database and retrieve sensitive information or modify data. The impact of a successful SQL injection attack can be severe, potentially leading to data breaches, unauthorized access, and even complete compromise of the affected system. False positives might occur since the legitimate use of web applications or specific URLs in your environment can trigger the detection. Therefore, you must review and validate any alerts generated by this analytic before taking any action. Next steps include reviewing the source and destination of the web traffic, as well as the specific URL and HTTP user agent. Additionally, capture and analyze any relevant on-disk artifacts and review concurrent processes to determine the source of the attack. +explanation = The following analytic detects long URLs containing multiple SQL commands, indicating a potential SQL injection attack. This detection leverages web traffic data, specifically targeting web server destinations with URLs longer than 1024 characters or HTTP user agents longer than 200 characters. SQL injection is significant as it allows attackers to manipulate a web application's database, potentially leading to unauthorized data access or modification. If confirmed malicious, this activity could result in data breaches, unauthorized access, and complete system compromise. Immediate investigation and validation of alerts are crucial to mitigate these risks. how_to_implement = To successfully implement this search, you need to be monitoring network communications to your web servers or ingesting your HTTP logs and populating the Web data model. You must also identify your web servers in the Enterprise Security assets table. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = It's possible that legitimate traffic will have long URLs or long user agent strings and that common SQL commands may be found within the URL. Please investigate as appropriate. @@ -16534,7 +16252,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic detects the presence of the Supernova webshell, which was used in the SUNBURST attack. This webshell can be used by attackers to gain unauthorized access to a compromised system and run arbitrary code. This detection is made by a Splunk query that searches for specific patterns in web URLs, including "*logoimagehandler.ashx*codes*", "*logoimagehandler.ashx*clazz*", "*logoimagehandler.ashx*method*", and "*logoimagehandler.ashx*args*". These patterns are commonly used by the Supernova webshell to communicate with its command and control server. This detection is important because it indicates a potential compromise and unauthorized access to the system to run arbitrary code, which can lead to data theft, ransomware, or other damaging outcomes. False positives might occur since the patterns used by the webshell can also be present in legitimate web traffic. In such cases, tune the search to the specific environment and monitor it closely for any suspicious activity. Next steps include reviewing the web URLs and inspecting any relevant on-disk artifacts. Additionally, review concurrent processes and network connections to identify the source of the attack. +explanation = The following analytic detects the presence of the Supernova webshell, used in the SUNBURST attack, by identifying specific patterns in web URLs. The detection leverages Splunk to search for URLs containing "*logoimagehandler.ashx*codes*", "*logoimagehandler.ashx*clazz*", "*logoimagehandler.ashx*method*", and "*logoimagehandler.ashx*args*". This activity is significant as it indicates potential unauthorized access and arbitrary code execution on a compromised system. If confirmed malicious, this could lead to data theft, ransomware deployment, or other severe outcomes. Immediate steps include reviewing the web URLs, inspecting on-disk artifacts, and analyzing concurrent processes and network connections. how_to_implement = To successfully implement this search, you need to be monitoring web traffic to your Solarwinds Orion. The logs should be ingested into splunk and populating/mapped to the Web data model. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505.003", "T1133"], "nist": ["DE.CM"]} known_false_positives = There might be false positives associted with this detection since items like args as a web argument is pretty generic. @@ -16544,10 +16262,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is designed to detect potential exploitation attempts against VMWare vRealize Network Insight that align with the characteristics of CVE-2023-20887. This specific vulnerability is a critical security flaw that, if exploited, could allow an attacker to execute arbitrary code on the affected system. \ -The analytic operates by monitoring web traffic, specifically HTTP POST requests, directed towards a specific URL endpoint ("/saas./resttosaasservlet"). This endpoint is known to be vulnerable and is a common target for attackers exploiting this vulnerability. \ -The behavior this analytic detects is the sending of HTTP POST requests to the vulnerable endpoint. This is a significant indicator of an attempted exploit as it is the primary method used to trigger the vulnerability. The analytic detects this behavior by analyzing web traffic data and identifying HTTP POST requests directed at the vulnerable endpoint. \ -Identifying this behavior is crucial for a Security Operations Center (SOC) as it can indicate an active attempt to exploit a known vulnerability within the network. If the identified behavior is a true positive, it suggests an attacker is attempting to exploit the CVE-2023-20887 vulnerability in VMWare vRealize Network Insight. The impact of such an attack could be severe, potentially allowing the attacker to execute arbitrary code on the affected system, leading to unauthorized access, data theft, or further propagation within the network. +explanation = The following analytic detects potential exploitation attempts against VMWare vRealize Network Insight, specifically targeting the CVE-2023-20887 vulnerability. It monitors web traffic for HTTP POST requests directed at the vulnerable endpoint "/saas./resttosaasservlet." This detection leverages web traffic data, focusing on specific URL patterns and HTTP methods. Identifying this behavior is crucial for a SOC as it indicates an active exploit attempt. If confirmed malicious, the attacker could execute arbitrary code, leading to unauthorized access, data theft, or further network compromise. how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. Restrict to specific dest assets to reduce false positives. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1133", "T1190", "T1210", "T1068"], "nist": ["DE.CM"]} known_false_positives = False positives will be present based on gateways in use, modify the status field as needed. @@ -16567,7 +16282,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies the server side template injection related to CVE-2022-22954. Based on the scanning activity across the internet and proof of concept code available the template injection occurs at catalog-portal/ui/oauth/verify?error=&deviceudid=. Upon triage, review parallel processes and VMware logs. Following the deviceudid= may be a command to be executed. Capture any file creates and review modified files on disk. +explanation = The following analytic detects server-side template injection attempts related to CVE-2022-22954 in VMware Workspace ONE. It leverages web or proxy logs to identify HTTP GET requests to the endpoint catalog-portal/ui/oauth/verify with the freemarker.template.utility.Execute command. This activity is significant as it indicates potential exploitation attempts that could lead to remote code execution. If confirmed malicious, an attacker could execute arbitrary commands on the server, leading to full system compromise, data exfiltration, or further lateral movement within the network. how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]} known_false_positives = False positives may be present if the activity is blocked or was not successful. Filter known vulnerablity scanners. Filter as needed. @@ -16577,7 +16292,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies the common URL requests used by a recent CVE - CVE-2022-22965, or Spring4Shell, to access a webshell on the remote webserver. The filename and cmd are arbitrary in this exploitation. Java will write a JSP to disk and a process will spawn from Java based on the cmd passed. This is indicative of typical web shell activity. +explanation = The following analytic identifies URL requests associated with CVE-2022-22965 (Spring4Shell) exploitation attempts, specifically targeting webshell access on a remote webserver. It detects HTTP GET requests with URLs containing ".jsp?cmd=" or "j&cmd=" patterns. This activity is significant as it indicates potential webshell deployment, which can lead to unauthorized remote command execution. If confirmed malicious, attackers could gain control over the webserver, execute arbitrary commands, and potentially escalate privileges, leading to severe data breaches and system compromise. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to servers. @@ -16587,7 +16302,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = This analytic identifies attempts to access the Remote ShellServlet on a web server, which is utilized to execute commands. Such activity is commonly linked with web shells and other forms of malicious behavior. It was specifically detected on a Confluence server in relation to CVE-2023-22518 and CVE-2023-22515. Activities preceding access to the shell servlet include the addition of a plugin to Confluence. Additionally, it is advisable to monitor for ShellServlet?act=3, ShellServlet, or obfuscated variations such as Sh3llServlet1. +explanation = The following analytic identifies attempts to access the Remote ShellServlet on a web server, specifically targeting Confluence servers vulnerable to CVE-2023-22518 and CVE-2023-22515. It leverages web data to detect URLs containing "*plugins/servlet/com.jsos.shell/*" with a status code of 200. This activity is significant as it is commonly associated with web shells and other malicious behaviors, potentially leading to unauthorized command execution. If confirmed malicious, attackers could gain remote code execution capabilities, compromising the server and potentially the entire network. how_to_implement = This analytic necessitates the collection of web data, which can be achieved through Splunk Stream or by utilizing the Splunk Add-on for Apache Web Server. No additional configuration is required for this analytic. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may occur depending on the web server's configuration. If the web server is intentionally configured to utilize the Remote ShellServlet, then the detections by this analytic would not be considered true positives. @@ -16597,7 +16312,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies the payload related to Spring4Shell, CVE-2022-22965. This analytic uses Splunk Stream HTTP to view the http request body, form data. STRT reviewed all the current proof of concept code and determined the commonality with the payloads being passed used the same fields "class.module.classLoader.resources.context.parent.pipeline.first". +explanation = The following analytic detects HTTP requests containing payloads related to the Spring4Shell vulnerability (CVE-2022-22965). It leverages Splunk Stream HTTP data to inspect the HTTP request body and form data for specific fields such as "class.module.classLoader.resources.context.parent.pipeline.first". This activity is significant as it indicates an attempt to exploit a critical vulnerability in Spring Framework, potentially leading to remote code execution. If confirmed malicious, this could allow attackers to gain unauthorized access, execute arbitrary code, and compromise the affected system. how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may occur and filtering may be required. Restrict analytic to asset type. @@ -16607,7 +16322,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies activity related to the web application Spring Cloud Function that was recently idenfied as vulnerable. This is CVE-2022-22963. Multiple proof of concept code was released. The URI that is hit includes `functionrouter`. The specifics of the exploit include a status of 500. In this query we did not include it, but for filtering you can add Web.status=500. The exploit data itself (based on all the POCs) is located in the form_data field. This field will include all class.modules being called. +explanation = The following analytic identifies HTTP POST requests to the Spring Cloud Function endpoint containing "functionRouter" in the URL. It leverages the Web data model to detect these requests based on specific fields such as http_method, url, and http_user_agent. This activity is significant because it targets CVE-2022-22963, a known vulnerability in Spring Cloud Function, which has multiple proof-of-concept exploits available. If confirmed malicious, this activity could allow attackers to execute arbitrary code, potentially leading to unauthorized access, data exfiltration, or further compromise of the affected system. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to servers. @@ -16617,7 +16332,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic utilizes the Web datamodel and identifies the ProxyShell or ProxyNotShell abuse. This vulnerability is a Server Side Request Forgery (SSRF) vulnerability, which is a web vulnerability that allows an adversary to exploit vulnerable functionality to access server side or local network services by affectively traversing the external firewall using vulnerable web functionality. This analytic looks for the URI path and query of autodiscover, powershell and mapi along with a POST occurring. It will tally a simple score and show the output of the events that match. This analytic may be added to by simply creating a new eval statement and modifying the hardcode digit for Score. +explanation = The following analytic detects potential abuse of the ProxyShell or ProxyNotShell vulnerabilities in Microsoft Exchange via Server Side Request Forgery (SSRF). It leverages the Web datamodel to identify suspicious POST requests with specific URI paths and queries related to autodiscover, powershell, and mapi. This activity is significant as it may indicate an attempt to exploit Exchange server vulnerabilities to access internal services or sensitive data. If confirmed malicious, this could lead to unauthorized access, data exfiltration, or further compromise of the network. how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic, Exchange OR IIS logs, mapped to `Web` datamodel in the `Web` node. In addition, confirm the latest CIM App 4.20 or higher is installed. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} known_false_positives = False positives are limited. @@ -16627,7 +16342,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic identifies potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability. The search is focused on the URL path "/wp-json/bricks/v1/render_element" with a status code of 200 and a POST method. It has been addressed by the theme developers in version 1.9.6.1 released on February 13, 2024. The vulnerability is tracked as CVE-2024-25600. The POC exploit is simple enough and will spawn commands on the target server. The exploit is actively being used in the wild. +explanation = The following analytic identifies potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability. It detects HTTP POST requests to the URL path "/wp-json/bricks/v1/render_element" with a status code of 200, leveraging the Web datamodel. This activity is significant as it indicates an attempt to exploit CVE-2024-25600, a known vulnerability that allows remote code execution. If confirmed malicious, an attacker could execute arbitrary commands on the target server, leading to potential full system compromise and unauthorized access to sensitive data. how_to_implement = The search is based on data in the Web datamodel and was modeled from NGINX logs. Ensure that the Web datamodel is accelerated and that the data source for the Web datamodel is properly configured. If using other web sources, modify they query, or review the data, as needed. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = False positives may be possible, however we restricted it to HTTP Status 200 and POST requests, based on the POC. Upon investigation review the POST body for the actual payload - or command - being executed. @@ -16637,7 +16352,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is designed to detect a Remote Code Execution (RCE) vulnerability (CVE-2023-40044) in WS_FTP, a managed file transfer software by Progress. The search specifically looks for HTTP requests to the "/AHT/AhtApiService.asmx/AuthUser" URL with a status of 200, which could indicate an exploitation attempt. +explanation = The following analytic detects potential Remote Code Execution (RCE) attempts exploiting CVE-2023-40044 in WS_FTP software. It identifies HTTP POST requests to the "/AHT/AhtApiService.asmx/AuthUser" URL with a status code of 200. This detection leverages the Web datamodel to monitor specific URL patterns and HTTP status codes. This activity is significant as it may indicate an exploitation attempt, potentially allowing an attacker to execute arbitrary code on the server. If confirmed malicious, this could lead to unauthorized access, data exfiltration, or further compromise of the affected system. how_to_implement = The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source. annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} known_false_positives = If WS_FTP Server is not in use, this analytic will not return results. Monitor and tune for your environment. Note the MetaSploit module is focused on only hitting /AHT/ and not the full /AHT/AhtApiService.asmx/AuthUser URL. @@ -16647,7 +16362,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The following analytic is designed to detect potential adware activity which is blocked by Zscaler. Utilizing Splunk search functionality, it filters web proxy logs for blocked actions associated with adware threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible adware intrusions. +explanation = The following analytic identifies potential adware activity blocked by Zscaler. It leverages web proxy logs to detect blocked actions associated with adware threats. Key data points such as device owner, user, URL category, destination URL, and IP are analyzed. This activity is significant as adware can degrade system performance, lead to unwanted advertisements, and potentially expose users to further malicious content. If confirmed malicious, it could indicate an attempt to compromise user systems, necessitating further investigation and remediation to prevent potential data breaches or system exploitation. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16657,7 +16372,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is built to identify threats blocked by the Zscaler proxy based on behavior analysis. It filters web proxy logs for entries where actions are blocked and threat names and classes are specified. The search further refines the results to include only those with reasons related to "block". It then aggregates the count, providing a clear view of the threat landscape as handled by the behavior analysis proxy. +explanation = The following analytic identifies threats blocked by the Zscaler proxy based on behavior analysis. It leverages web proxy logs to detect entries where actions are blocked and threat names and classes are specified. This detection is significant as it highlights potential malicious activities that were intercepted by Zscaler's behavior analysis, providing early indicators of threats. If confirmed malicious, these blocked threats could indicate attempted breaches or malware infections, helping security teams to understand and mitigate potential risks in their environment. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscalar configuration. @@ -16667,7 +16382,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is crafted to detect potential download of cryptomining software within a network that is blocked by Zscaler. Utilizing Splunk search functionality, it sifts through web proxy logs for blocked actions associated with cryptominer threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible cryptominer downloads. This detection, categorized as an anomaly, aids in early identification and mitigation of cryptomining activities, ensuring network integrity and resource availability. +explanation = The following analytic identifies attempts to download cryptomining software that are blocked by Zscaler. It leverages web proxy logs to detect blocked actions associated with cryptominer threats, analyzing key data points such as device owner, user, URL category, destination URL, and IP. This activity is significant for a SOC as it helps in early identification and mitigation of cryptomining activities, which can compromise network integrity and resource availability. If confirmed malicious, this activity could lead to unauthorized use of network resources for cryptomining, potentially degrading system performance and increasing operational costs. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16677,7 +16392,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is designed to identify destinations within a network deemed as potential Empolyment Searches. Utilizing Splunk's search functionality, it processes web proxy logs, focusing on entries marked as 'Job/Employment Search'. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the employment risk destinations. This anomaly-type detection aids in monitoring and managing risks, promoting a secure environment from insider threats. +explanation = The following analytic identifies web activity related to employment searches within a network. It leverages Zscaler web proxy logs, focusing on entries categorized as 'Job/Employment Search'. Key data points such as device owner, user, URL category, destination URL, and IP are analyzed. This detection is significant for SOCs as it helps monitor potential insider threats by identifying users who may be seeking new employment. If confirmed malicious, this activity could indicate a risk of data exfiltration or other insider threats, potentially leading to sensitive information leakage or other security breaches. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16687,7 +16402,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is aimed at detecting potential exploit attempts that involve command and script interpreters blocked by Zscaler. By querying web proxy logs, it isolates incidents where actions have been either blocked with references to exploits. The search compiles statistics by user, threat name, URL, hostname, file class, and filename, giving a detailed view of any exploit-related activity. Marked as a tactic, technique, and procedure (TTP), this analytic is essential for identifying and mitigating exploit attempts. +explanation = The following analytic identifies potential exploit attempts involving command and script interpreters blocked by Zscaler. It leverages web proxy logs to detect incidents where actions are blocked due to exploit references. The detection compiles statistics by user, threat name, URL, hostname, file class, and filename. This activity is significant as it helps identify and mitigate exploit attempts, which are critical for maintaining security. If confirmed malicious, such activity could lead to unauthorized code execution, privilege escalation, or persistent access within the environment, posing a severe threat to organizational security. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.CM"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16697,7 +16412,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is aimed at identifying the most significant legal liability threats blocked by zcaler web proxy. It leverages web proxy logs to list the destinations, device owners, users, URL categories, and actions that are associated with Legal Liability, by utilizing stats on unique fields, it ensures a precise focus on unique legal liability threats, thereby providing valuable insights for organizations to enforce legal compliance and risk management. +explanation = The following analytic identifies significant legal liability threats blocked by the Zscaler web proxy. It uses web proxy logs to track destinations, device owners, users, URL categories, and actions associated with legal liability. By leveraging statistics on unique fields, it ensures a precise focus on these threats. This activity is significant for SOC as it helps enforce legal compliance and risk management. If confirmed malicious, it could indicate attempts to access legally sensitive or restricted content, potentially leading to legal repercussions and compliance violations. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16707,7 +16422,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic targets the detection of potential malware activities within a network that are blocked by Zscaler. By filtering web proxy logs for blocked actions associated with malware, where a threat category is specified, the analytic aggregates occurrences by user, URL, and threat category. This approach ensures a focused identification of malware activities, making it an effective tool for ongoing network security monitoring and anomaly detection. +explanation = The following analytic identifies potential malware activities within a network that are blocked by Zscaler. It leverages web proxy logs to filter for blocked actions associated with malware, aggregating occurrences by user, URL, and threat category. This detection is significant for SOC as it highlights attempts to access malicious content, indicating potential compromise or targeted attacks. If confirmed malicious, this activity could signify an ongoing attempt to infiltrate the network, necessitating immediate investigation to prevent further threats and ensure network integrity. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscalar configuration. @@ -16717,7 +16432,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is devised to detect likely phishing attempts within a network blocked by Zscaler. By leveraging Splunk search functionality, it evaluates web proxy logs for blocked actions correlated with phishing threats, specifically those tagged as HTML.Phish. Critical data points such as the user, threat name, URL, and hostname are analyzed to accentuate possible phishing activities. This anomaly-type detection serves as an early warning system, facilitating prompt investigation and mitigation of phishing threats, thereby bolstering network security. +explanation = The following analytic identifies potential phishing attempts blocked by Zscaler within a network. It leverages web proxy logs to detect actions tagged as HTML.Phish. The detection method involves analyzing critical data points such as user, threat name, URL, and hostname. This activity is significant for a SOC as it serves as an early warning system for phishing threats, enabling prompt investigation and mitigation. If confirmed malicious, this activity could indicate an attempt to deceive users into divulging sensitive information, potentially leading to data breaches or credential theft. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscalar configuration. @@ -16727,7 +16442,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is engineered to detect potential rarely abused malicious filetypes downloaded within a network. They are usually used to spread malwares. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to potential threats. Essential data points like the deviceowner, user, urlcategory, url, dest, and filename taken are analyzed to highlight possible malicious endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of malicious download activities, ensuring a safer network environment. +explanation = The following analytic identifies the download of potentially malicious file types, such as .scr, .dll, .bat, and .lnk, within a network. It leverages web proxy logs from Zscaler, focusing on blocked actions and analyzing fields like deviceowner, user, urlcategory, url, dest, and filename. This activity is significant as these file types are often used to spread malware, posing a threat to network security. If confirmed malicious, this activity could lead to malware execution, data compromise, or further network infiltration. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16737,7 +16452,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is designed to identify blocked destinations within a network deemed as privacy risks by Zscaler. Utilizing Splunk search functionality, it processes web proxy logs, focusing on entries marked as Privacy Risk. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the privacy risk destinations. This anomaly-type detection aids in monitoring and managing privacy risks, promoting a secure network environment. +explanation = The following analytic identifies blocked destinations within a network that are deemed privacy risks by Zscaler. It leverages web proxy logs, focusing on entries marked as "Privacy Risk." Key data points such as device owner, user, URL category, destination URL, and IP are analyzed. This activity is significant for a SOC as it helps monitor and manage privacy risks, ensuring a secure network environment. If confirmed malicious, this activity could indicate attempts to access or exfiltrate sensitive information, posing a significant threat to data privacy and security. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16747,7 +16462,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is engineered to detect potential scam activities within a network by Zscaler. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to scam threats. Essential data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible scam endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of scam activities, ensuring a safer network environment. +explanation = The following analytic identifies blocked scam-related activities detected by Zscaler within a network. It leverages web proxy logs to examine actions flagged as scam threats, focusing on data points such as device owner, user, URL category, destination URL, and IP. This detection is significant for SOC as it helps in the early identification and mitigation of scam activities, ensuring network safety. If confirmed malicious, this activity could indicate attempts to deceive users, potentially leading to data theft or financial loss. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -16757,7 +16472,7 @@ providing_technologies = null type = detection asset_type = Web Server confidence = medium -explanation = The analytic is formulated to detect blocked virus download activities within a network by Zscaler. Employing Splunk's search functionality, it reviews web proxy logs for blocked actions indicative of virus threats downloads. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to pinpoint possible virus downloads. As an anomaly-type detection, this analytic facilitates early detection and remediation of virus download attempts, contributing to enhanced network security. +explanation = The following analytic identifies attempts to download viruses that were blocked by Zscaler within a network. It leverages web proxy logs to detect blocked actions indicative of virus download attempts. Key data points such as device owner, user, URL category, destination URL, and IP are analyzed. This activity is significant as it helps in early detection and remediation of potential virus threats, enhancing network security. If confirmed malicious, this activity could indicate an attempt to compromise the network, potentially leading to data breaches or further malware infections. how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment. annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]} known_false_positives = False positives are limited to Zscaler configuration. @@ -17568,7 +17283,7 @@ version = 1 references = ["https://github.security.telekom.com/2023/08/darkgate-loader.html", "https://redcanary.com/blog/intelligence-insights-october-2023"] maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}] spec_version = 3 -searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Deleting Of Net Users - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - Powershell Remote Services Add TrustedHost - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Archive Collected Data via Rar - Rule", "ESCU - Windows AutoIt3 Execution - Rule", "ESCU - Windows CAB File on Disk - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Credentials from Password Stores Creation - Rule", "ESCU - Windows Credentials from Password Stores Deletion - Rule", "ESCU - Windows Credentials from Password Stores Query - Rule", "ESCU - Windows Indicator Removal Via Rmdir - Rule", "ESCU - Windows Modify Registry AuthenticationLevelOverride - Rule", "ESCU - Windows Modify Registry DisableRemoteDesktopAntiAlias - Rule", "ESCU - Windows Modify Registry DisableSecuritySettings - Rule", "ESCU - Windows Modify Registry DontShowUI - Rule", "ESCU - Windows Modify Registry ProxyEnable - Rule", "ESCU - Windows Modify Registry ProxyServer - Rule", "ESCU - Windows MSIExec Spawn WinDBG - Rule", "ESCU - Windows System Reboot CommandLine - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - Windows WinDBG Spawning AutoIt3 - Rule"] +searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Deleting Of Net Users - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - Powershell Remote Services Add TrustedHost - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Archive Collected Data via Rar - Rule", "ESCU - Windows AutoIt3 Execution - Rule", "ESCU - Windows CAB File on Disk - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Credentials from Password Stores Creation - Rule", "ESCU - Windows Credentials from Password Stores Deletion - Rule", "ESCU - Windows Credentials from Password Stores Query - Rule", "ESCU - Windows Debugger Tool Execution - Rule", "ESCU - Windows Indicator Removal Via Rmdir - Rule", "ESCU - Windows Modify Registry AuthenticationLevelOverride - Rule", "ESCU - Windows Modify Registry DisableRemoteDesktopAntiAlias - Rule", "ESCU - Windows Modify Registry DisableSecuritySettings - Rule", "ESCU - Windows Modify Registry DontShowUI - Rule", "ESCU - Windows Modify Registry ProxyEnable - Rule", "ESCU - Windows Modify Registry ProxyServer - Rule", "ESCU - Windows MSIExec Spawn WinDBG - Rule", "ESCU - Windows System Reboot CommandLine - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - Windows Unsigned DLL Side-Loading In Same Process Path - Rule", "ESCU - Windows WinDBG Spawning AutoIt3 - Rule"] description = Telekom Security CTI has uncovered a new phishing-driven malware campaign distributing DarkGate malware. This campaign utilizes stolen email threads to trick users into downloading malicious payloads via hyperlinks. An initial false link to Emotet stirred the security community, but deeper analysis confirmed its true identity as DarkGate, with characteristics like AutoIt scripts and a known command-and-control protocol. This report by Fabian Marquardt details the intricate infection mechanisms, including MSI and VBS file deliveries, sophisticated evasion techniques, and a robust configuration extraction method surpassing current standards. The single developer behind DarkGate, active on cybercrime forums, has shifted the malware's use from private to a rent-out model, implying an expected rise in its deployment. Researchers have also developed a decryption technique for the DarkGate malware, which aids in static analysis and detection, though it requires careful validation to avoid false positives. narrative = Telekom Security CTi has recently put a spotlight on the proliferation of DarkGate malware via a sophisticated malspam campaign, initially mistaken for the notorious Emotet malware. The campaign smartly manipulates stolen email conversations, embedding hyperlinks that, once clicked, activate a malware download. Fabian Marquardt's analysis traces the infection's footprint, revealing a dual delivery mechanism through MSI and VBS files. These files, cloaked in legitimate wrappers or obscured with junk code, ultimately download the malware via embedded scripts. \ Marquardt delves into the AutoIt script-based infection, uncovering the calculated use of compiled scripts and base64-encoded data to disguise the execution of malicious shellcode. The subsequent stages of infection exhibit the malware's capability to evade detection, leveraging memory allocation techniques to bypass security measures. Marquardt also explores the loader's function, which decrypts further malicious payloads by interacting with the script's encoded components. \ @@ -18024,6 +17739,17 @@ narrative = Google Cloud Platform (GCP) admins manage access to GCP resources an In between the time between when the temporary credentials are issued and when they expire is a period of opportunity, where a user could leverage the temporary credentials to wreak havoc-spin up or remove instances, create new users, elevate privileges, and other malicious activities-throughout the environment. \ This Analytic Story includes searches that will help you monitor your GCP Audit logs logs for evidence of suspicious cross-account activity. For example, while accessing multiple GCP accounts and roles may be perfectly valid behavior, it may be suspicious when an account requests privileges of an account it has not accessed in the past. After identifying suspicious activities, you can use the provided investigative searches to help you probe more deeply. +[analytic_story://Gomir] +category = Malware +last_updated = 2024-05-29 +version = 1 +references = ["https://www.bleepingcomputer.com/news/security/kimsuky-hackers-deploy-new-linux-backdoor-via-trojanized-installers/", "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/springtail-kimsuky-backdoor-espionage"] +maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}] +spec_version = 3 +searches = ["ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux Service File Created In Systemd Directory - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Service Started Or Enabled - Rule"] +description = This analytic story includes detections that help security analysts identify and investigate unusual activities associated with the Gomir backdoor malware. Gomir is a sophisticated cyber threat that gains unauthorized access to systems. It communicates with a remote command-and-control (C2) server to execute malicious commands, steal sensitive data, and facilitate further attacks, often evading traditional security measures. +narrative = The Gomir backdoor malware is a piece of cyber threat designed to infiltrate and compromise systems covertly. Once it gains unauthorized access, Gomir establishes a persistent presence by communicating with a remote command-and-control (C2) server. This connection allows the attacker to execute a wide range of malicious commands on the infected system. Gomir is capable of stealing sensitive data, which can be exfiltrated back to the attacker. Additionally, Gomir can download and install further malicious payloads, facilitating broader cyber-espionage or destructive activities. + [analytic_story://Graceful Wipe Out Attack] category = Data Destruction last_updated = 2023-06-15 @@ -18686,7 +18412,7 @@ version = 2 references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.plugx", "https://blog.sekoia.io/my-teas-not-cold-an-overview-of-china-cyber-threat/", "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/carderbee-software-supply-chain-certificate-abuse", "https://go.recordedfuture.com/hubfs/reports/cta-2023-0808.pdf", "https://www.mandiant.com/resources/blog/infected-usb-steal-secrets", "https://attack.mitre.org/software/S0013/"] maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}] spec_version = 3 -searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious writes to windows Recycle Bin - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Masquerading Msdtc Process - Rule", "ESCU - Windows Replication Through Removable Media - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Deletion In Registry - Rule"] +searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious writes to windows Recycle Bin - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Debugger Tool Execution - Rule", "ESCU - Windows Masquerading Msdtc Process - Rule", "ESCU - Windows Replication Through Removable Media - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Deletion In Registry - Rule", "ESCU - Windows Unsigned DLL Side-Loading In Same Process Path - Rule"] description = PlugX, also referred to as "PlugX RAT" or "Kaba," is a highly sophisticated remote access Trojan (RAT) discovered in 2012. This malware is notorious for its involvement in targeted cyberattacks, primarily driven by cyber espionage objectives. PlugX provides attackers with comprehensive remote control capabilities over compromised systems, granting them the ability to execute commands, collect sensitive data, and manipulate the infected host. narrative = PlugX, known as the "silent infiltrator of the digital realm, is a shadowy figure in the world of cyber threats. This remote access Trojan (RAT), first unveiled in 2012, is not your run-of-the-mill malware. It's the go-to tool for sophisticated hackers with one goal in mind, espionage. PlugX's repertoire of capabilities reads like a spy thriller. It doesn't just breach your defenses; it goes a step further, slipping quietly into your systems, much like a ghost. Once inside, it opens the door to a world of possibilities for cybercriminals. With a few keystrokes, they can access your data, capture your screen, and silently watch your every move. In the hands of skilled hackers, it's a versatile instrument for cyber espionage. This malware thrives on persistence. It's not a one-time hit; it's in it for the long haul. Even if you reboot your system, PlugX remains, ensuring that its grip on your infrastructure doesn't waver. diff --git a/dist/DA-ESS-ContentUpdate/default/app.conf b/dist/DA-ESS-ContentUpdate/default/app.conf index b013d218f5..bbba160f85 100644 --- a/dist/DA-ESS-ContentUpdate/default/app.conf +++ b/dist/DA-ESS-ContentUpdate/default/app.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# @@ -11,7 +11,7 @@ is_configured = false state = enabled state_change_requires_restart = false -build = 20240606175332 +build = 20240626201627 [triggers] reload.analytic_stories = simple @@ -27,7 +27,7 @@ reload.es_investigations = simple [launcher] author = Splunk -version = 4.33.0 +version = 4.34.0 description = Explore the Analytic Stories included with ES Content Updates. [ui] diff --git a/dist/DA-ESS-ContentUpdate/default/collections.conf b/dist/DA-ESS-ContentUpdate/default/collections.conf index f98ac396f3..3b1e11d485 100644 --- a/dist/DA-ESS-ContentUpdate/default/collections.conf +++ b/dist/DA-ESS-ContentUpdate/default/collections.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/content-version.conf b/dist/DA-ESS-ContentUpdate/default/content-version.conf index b74e0de4a6..20bef11dc5 100644 --- a/dist/DA-ESS-ContentUpdate/default/content-version.conf +++ b/dist/DA-ESS-ContentUpdate/default/content-version.conf @@ -1,9 +1,9 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# [content-version] -version = 4.33.0 \ No newline at end of file +version = 4.34.0 \ No newline at end of file diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_all_backup_logs_for_host___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_all_backup_logs_for_host___response_task.xml index 63d0b84eae..2d6754f87a 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_all_backup_logs_for_host___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_all_backup_logs_for_host___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_amazon_eks_kubernetes_activity_by_src_ip___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_amazon_eks_kubernetes_activity_by_src_ip___response_task.xml index d279196fdd..f4a975bf89 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_amazon_eks_kubernetes_activity_by_src_ip___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_amazon_eks_kubernetes_activity_by_src_ip___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_security_hub_alerts_by_dest___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_security_hub_alerts_by_dest___response_task.xml index b511759d29..8316b8ff66 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_security_hub_alerts_by_dest___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_security_hub_alerts_by_dest___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_accesskeyid___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_accesskeyid___response_task.xml index e0f7d86519..2ef5c9ec8f 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_accesskeyid___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_accesskeyid___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_arn___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_arn___response_task.xml index fce982c6be..7bf0b3fb59 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_arn___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_investigate_user_activities_by_arn___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_acl_details_from_id___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_acl_details_from_id___response_task.xml index 85ff5944a4..f1b98ac0e3 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_acl_details_from_id___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_acl_details_from_id___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_interface_details_via_resourceid___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_interface_details_via_resourceid___response_task.xml index 5e640aae66..b6ce533201 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_interface_details_via_resourceid___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_network_interface_details_via_resourceid___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_s3_bucket_details_via_bucketname___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_s3_bucket_details_via_bucketname___response_task.xml index 75aceaec76..1ac03bf370 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_s3_bucket_details_via_bucketname___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_aws_s3_bucket_details_via_bucketname___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_gcp_kubernetes_activity_by_src_ip___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_gcp_kubernetes_activity_by_src_ip___response_task.xml index 1bffe4310f..65c9bffe86 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_gcp_kubernetes_activity_by_src_ip___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_gcp_kubernetes_activity_by_src_ip___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_city___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_city___response_task.xml index 7c583d1e4f..b0db26595b 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_city___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_city___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_country___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_country___response_task.xml index c508648c58..45cf0dd736 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_country___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_country___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_ip_address___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_ip_address___response_task.xml index 8178d321a9..7437dab28e 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_ip_address___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_ip_address___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_region___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_region___response_task.xml index 238b79be31..089af8ae00 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_region___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_all_aws_activity_from_region___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_backup_logs_for_endpoint___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_backup_logs_for_endpoint___response_task.xml index be7a032e56..c5bbc22649 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_backup_logs_for_endpoint___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_backup_logs_for_endpoint___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_certificate_logs_for_a_domain___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_certificate_logs_for_a_domain___response_task.xml index c9e743786f..348727dddf 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_certificate_logs_for_a_domain___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_certificate_logs_for_a_domain___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_server_history_for_a_host___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_server_history_for_a_host___response_task.xml index 5aece559f0..f87a37f9f7 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_server_history_for_a_host___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_server_history_for_a_host___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_traffic_ratio___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_traffic_ratio___response_task.xml index 18a49f772c..736ff6722f 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_traffic_ratio___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_dns_traffic_ratio___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_instance_details_by_instanceid___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_instance_details_by_instanceid___response_task.xml index 8a680b9c7d..e278a9ce3c 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_instance_details_by_instanceid___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_instance_details_by_instanceid___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_launch_details___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_launch_details___response_task.xml index 387a8a4d8d..b986183ed2 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_launch_details___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_ec2_launch_details___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_email_info___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_email_info___response_task.xml index 6422469c85..90ebfa65ec 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_email_info___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_email_info___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_emails_from_specific_sender___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_emails_from_specific_sender___response_task.xml index 8933de7d09..c606523afc 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_emails_from_specific_sender___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_emails_from_specific_sender___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_first_occurrence_and_last_occurrence_of_a_mac_address___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_first_occurrence_and_last_occurrence_of_a_mac_address___response_task.xml index 4fd0a149a4..27e4fba389 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_first_occurrence_and_last_occurrence_of_a_mac_address___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_first_occurrence_and_last_occurrence_of_a_mac_address___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_history_of_email_sources___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_history_of_email_sources___response_task.xml index 68002924bf..bb35ad185a 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_history_of_email_sources___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_history_of_email_sources___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_endpoint___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_endpoint___response_task.xml index 52e3206cc1..d3fe2cfb54 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_endpoint___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_endpoint___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_user___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_user___response_task.xml index ec2785bb6e..e6918af5b1 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_user___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_logon_rights_modifications_for_user___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_notable_history___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_notable_history___response_task.xml index d16aa07fba..1deb56f7d8 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_notable_history___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_notable_history___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_parent_process_info___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_parent_process_info___response_task.xml index ac55dd4ae7..4026e4d6d5 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_parent_process_info___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_parent_process_info___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_file_activity___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_file_activity___response_task.xml index cf9a72b68a..89e23461a8 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_file_activity___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_file_activity___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_info___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_info___response_task.xml index bd84af679e..f586bcf0f2 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_info___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_info___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_information_for_port_activity___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_information_for_port_activity___response_task.xml index 6614e428cd..60f34b99be 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_information_for_port_activity___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_information_for_port_activity___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_responsible_for_the_dns_traffic___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_responsible_for_the_dns_traffic___response_task.xml index fb40e2f5d7..ddf6598ea1 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_responsible_for_the_dns_traffic___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_process_responsible_for_the_dns_traffic___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_sysmon_wmi_activity_for_host___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_sysmon_wmi_activity_for_host___response_task.xml index c11b8fb734..2b8b94aa30 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_sysmon_wmi_activity_for_host___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_sysmon_wmi_activity_for_host___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_web_session_information_via_session_id___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_web_session_information_via_session_id___response_task.xml index 108d38ada9..0c99117d84 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_web_session_information_via_session_id___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_get_web_session_information_via_session_id___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_activities_via_region_name___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_activities_via_region_name___response_task.xml index 4a75d0a23c..7cfa4ba339 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_activities_via_region_name___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_activities_via_region_name___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_user_activities_by_user_field___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_user_activities_by_user_field___response_task.xml index 8024d331df..ebbe925a15 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_user_activities_by_user_field___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_aws_user_activities_by_user_field___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_failed_logins_for_multiple_destinations___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_failed_logins_for_multiple_destinations___response_task.xml index 559cbf8a27..3e6391295d 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_failed_logins_for_multiple_destinations___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_failed_logins_for_multiple_destinations___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_network_traffic_from_src_ip___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_network_traffic_from_src_ip___response_task.xml index 426a3fee32..2d303e6b08 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_network_traffic_from_src_ip___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_network_traffic_from_src_ip___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_okta_activity_by_app___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_okta_activity_by_app___response_task.xml index 62de35b5fe..8866cd07cd 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_okta_activity_by_app___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_okta_activity_by_app___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_hash_attempts___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_hash_attempts___response_task.xml index 07decf6e17..e5b333aa02 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_hash_attempts___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_hash_attempts___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_ticket_attempts___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_ticket_attempts___response_task.xml index 83e530495a..0332245142 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_ticket_attempts___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_pass_the_ticket_attempts___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_previous_unseen_user___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_previous_unseen_user___response_task.xml index 219b0f84eb..3b2bd9ff94 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_previous_unseen_user___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_previous_unseen_user___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_successful_remote_desktop_authentications___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_successful_remote_desktop_authentications___response_task.xml index 995dbb2716..90e1b79500 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_successful_remote_desktop_authentications___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_successful_remote_desktop_authentications___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_suspicious_strings_in_http_header___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_suspicious_strings_in_http_header___response_task.xml index f7dafd366b..58a2cac917 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_suspicious_strings_in_http_header___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_suspicious_strings_in_http_header___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_user_activities_in_okta___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_user_activities_in_okta___response_task.xml index 6b58b933d3..4a79138a49 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_user_activities_in_okta___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_user_activities_in_okta___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_web_posts_from_src___response_task.xml b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_web_posts_from_src___response_task.xml index 4cf660721a..0112115e21 100644 --- a/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_web_posts_from_src___response_task.xml +++ b/dist/DA-ESS-ContentUpdate/default/data/ui/panels/workbench_panel_investigate_web_posts_from_src___response_task.xml @@ -2,7 +2,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:59 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/distsearch.conf b/dist/DA-ESS-ContentUpdate/default/distsearch.conf index 23129734b3..0883f658cd 100644 --- a/dist/DA-ESS-ContentUpdate/default/distsearch.conf +++ b/dist/DA-ESS-ContentUpdate/default/distsearch.conf @@ -1,5 +1,5 @@ [replicationSettings:refineConf] replicate.analytic_stories = false -[replicationBlacklist] +[replicationDenylist] excludeESCU = apps[/\\]DA-ESS-ContentUpdate[/\\]lookups[/\\]... diff --git a/dist/DA-ESS-ContentUpdate/default/es_investigations.conf b/dist/DA-ESS-ContentUpdate/default/es_investigations.conf index 437ea1d009..d9c955903b 100644 --- a/dist/DA-ESS-ContentUpdate/default/es_investigations.conf +++ b/dist/DA-ESS-ContentUpdate/default/es_investigations.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# diff --git a/dist/DA-ESS-ContentUpdate/default/macros.conf b/dist/DA-ESS-ContentUpdate/default/macros.conf index f0d14c15e2..481def847a 100644 --- a/dist/DA-ESS-ContentUpdate/default/macros.conf +++ b/dist/DA-ESS-ContentUpdate/default/macros.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# @@ -183,6 +183,10 @@ description = customer specific splunk configurations(eg- index, source, sourcet definition = index=netops sourcetype="f5:bigip:rogue" description = customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. +[fillnull_config] +definition = null +description = Used inside security_content_summariesonly to adjust the fillnull configuration + [filter_rare_process_allow_list] definition = lookup update=true lookup_rare_process_allow_list_default process as process OUTPUTNEW allow_list | where allow_list="false" | lookup update=true lookup_rare_process_allow_list_local process as process OUTPUT allow_list | where allow_list="false" description = This macro is intended to allow_list processes that have been definied as rare @@ -331,6 +335,10 @@ description = customer specific splunk configurations(eg- index, source, sourcet definition = eventtype=okta_log OR sourcetype = "OktaIM2:log" description = customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. +[oldsummaries_config] +definition = true +description = Used inside security_content_summariesonly to adjust the allow_old_summaries configuration + [osquery] definition = sourcetype=osquery:results description = customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. @@ -604,8 +612,8 @@ definition = | inputlookup prohibited_apps_launching_cmd | rename prohibited_app description = This macro outputs a list of process that should not be the parent process of cmd.exe [prohibited_softwares] -definition = lookup prohibited_softwares app as process_name OUTPUT is_prohibited | search is_prohibited=True -description = This macro limits the output to process_names that have been marked as prohibited +definition = search * +description = This macro is deprecated. Update this macro to look for prohibited softwares in your environment [ransomware_extensions] definition = lookup update=true ransomware_extensions_lookup Extensions AS file_extension OUTPUT Name | search Name !=False @@ -637,7 +645,7 @@ definition = convert timeformat="%Y-%m-%dT%H:%M:%S" ctime($field$) description = convert epoch time to string [security_content_summariesonly] -definition = summariesonly=false allow_old_summaries=true fillnull_value=null +definition = summariesonly=`summariesonly_config` allow_old_summaries=`oldsummaries_config` fillnull_value=`fillnull_config` description = search data model's summaries only [security_group_api_calls] @@ -696,6 +704,10 @@ description = customer specific splunk configurations(eg- index, source, sourcet definition = sourcetype="PwSh:SubjectInterfacePackage" description = customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. +[summariesonly_config] +definition = false +description = Used inside security_content_summariesonly to adjust the summariesonly configuration + [suricata] definition = sourcetype=suricata description = customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. @@ -5324,6 +5336,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. +[windows_debugger_tool_execution_filter] +definition = search * +description = Update this macro to limit the output results to filter out false positives. + [windows_defacement_modify_transcodedwallpaper_file_filter] definition = search * description = Update this macro to limit the output results to filter out false positives. @@ -6672,6 +6688,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. +[windows_unsigned_dll_side_loading_in_same_process_path_filter] +definition = search * +description = Update this macro to limit the output results to filter out false positives. + [windows_unsigned_ms_dll_side_loading_filter] definition = search * description = Update this macro to limit the output results to filter out false positives. diff --git a/dist/DA-ESS-ContentUpdate/default/savedsearches.conf b/dist/DA-ESS-ContentUpdate/default/savedsearches.conf index 725be002d4..44f54e7278 100644 --- a/dist/DA-ESS-ContentUpdate/default/savedsearches.conf +++ b/dist/DA-ESS-ContentUpdate/default/savedsearches.conf @@ -1,7 +1,7 @@ ############# # Automatically generated by 'contentctl build' from # https://github.com/splunk/contentctl -# On Date: 2024-06-06T17:54:44 UTC +# On Date: 2024-06-26T20:16:58 UTC # Author: Splunk Threat Research Team - Splunk # Contact: research@splunk.com ############# @@ -104,14 +104,14 @@ search = | tstats `security_content_summariesonly` count earliest(_time) as earl [ESCU - Detect Risky SPL using Pretrained ML Model - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic uses a pretrained machine learning text classifier to detect potentially risky commands. The model is trained independently and then the model file is packaged within ESCU for usage. A command is deemed risky based on the presence of certain trigger keywords, along with the context and the role of the user (please see references). The model uses custom features to predict whether a SPL is risky using text classification. The model takes as input the command text, user and search type and outputs a risk score between [0,1]. A high score indicates higher likelihood of a command being risky. This model is on-prem only. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies potentially risky SPL commands executed by users. It leverages a pretrained machine learning text classifier that analyzes command text, user, and search type to assign a risk score between 0 and 1. This detection is significant as it helps identify suspicious or unauthorized search activities that could indicate malicious intent or misuse of the Splunk environment. If confirmed malicious, such activity could lead to unauthorized data access, data exfiltration, or further exploitation of the system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Splunk_Audit"] -action.escu.eli5 = The following analytic uses a pretrained machine learning text classifier to detect potentially risky commands. The model is trained independently and then the model file is packaged within ESCU for usage. A command is deemed risky based on the presence of certain trigger keywords, along with the context and the role of the user (please see references). The model uses custom features to predict whether a SPL is risky using text classification. The model takes as input the command text, user and search type and outputs a risk score between [0,1]. A high score indicates higher likelihood of a command being risky. This model is on-prem only. +action.escu.eli5 = The following analytic identifies potentially risky SPL commands executed by users. It leverages a pretrained machine learning text classifier that analyzes command text, user, and search type to assign a risk score between 0 and 1. This detection is significant as it helps identify suspicious or unauthorized search activities that could indicate malicious intent or misuse of the Splunk environment. If confirmed malicious, such activity could lead to unauthorized data access, data exfiltration, or further exploitation of the system. action.escu.how_to_implement = This detection depends on the MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Additionally, you need to be ingesting logs which include Search_Activity.search, Search_Activity.user, Search_Activity.search_type from your endpoints. The risk score threshold should be adjusted based on the environment. The detection uses a custom MLTK model hence we need a few more steps for deployment, as outlined here - https://gist.github.com/ksharad-splunk/be2a62227966049047f5e5c4f2adcabb. action.escu.known_false_positives = False positives may be present if suspicious behavior is observed, as determined by frequent usage of risky keywords. -action.escu.creation_date = 2022-06-16 -action.escu.modification_date = 2022-06-16 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Risky SPL using Pretrained ML Model - Rule action.escu.search_type = detection @@ -129,7 +129,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect Risky SPL using Pretrained ML Model - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 40, "cve": ["CVE-2022-32154"], "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b4aefb5f-1037-410d-a149-1e091288ba33", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b4aefb5f-1037-410d-a149-1e091288ba33", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -230,7 +230,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count values(Filesystem.file_path) as file_path min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where (Filesystem.file_name=*.pst OR Filesystem.file_name=*.ost) Filesystem.file_path != "C:\\Users\\*\\My Documents\\Outlook Files\\*" Filesystem.file_path!="C:\\Users\\*\\AppData\\Local\\Microsoft\\Outlook*" by Filesystem.action Filesystem.process_id Filesystem.file_name Filesystem.dest | `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `email_files_written_outside_of_the_outlook_directory_filter` +search = | tstats `security_content_summariesonly` count values(Filesystem.file_path) as file_path min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where (Filesystem.file_name=*.pst OR Filesystem.file_name=*.ost) Filesystem.file_path != "C:\\Users\\*\\My Documents\\Outlook Files\\*" Filesystem.file_path!="C:\\Users\\*\\AppData\\Local\\Microsoft\\Outlook*" by Filesystem.action Filesystem.process_id Filesystem.file_name Filesystem.dest | `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `email_files_written_outside_of_the_outlook_directory_filter` [ESCU - Email servers sending high volume traffic to hosts - Rule] action.escu = 0 @@ -323,14 +323,14 @@ search = | tstats `security_content_summariesonly` values(All_Email.recipient) a [ESCU - No Windows Updates in a time frame - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search looks for Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. Windows updates are typically released monthly and applied shortly thereafter. An endpoint that has not successfully applied an update in this time frame indicates the endpoint is not regularly being patched for some reason. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. It leverages the 'Update' data model in Splunk, specifically looking for the latest 'Installed' status events from Microsoft Windows. This activity is significant for a SOC because endpoints that are not regularly patched are vulnerable to known exploits and security vulnerabilities. If confirmed malicious, this could indicate a compromised endpoint that is intentionally being kept unpatched, potentially allowing attackers to exploit unpatched vulnerabilities and gain unauthorized access or control. action.escu.mappings = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} action.escu.data_models = ["Updates"] -action.escu.eli5 = This search looks for Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. Windows updates are typically released monthly and applied shortly thereafter. An endpoint that has not successfully applied an update in this time frame indicates the endpoint is not regularly being patched for some reason. +action.escu.eli5 = The following analytic identifies Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. It leverages the 'Update' data model in Splunk, specifically looking for the latest 'Installed' status events from Microsoft Windows. This activity is significant for a SOC because endpoints that are not regularly patched are vulnerable to known exploits and security vulnerabilities. If confirmed malicious, this could indicate a compromised endpoint that is intentionally being kept unpatched, potentially allowing attackers to exploit unpatched vulnerabilities and gain unauthorized access or control. action.escu.how_to_implement = To successfully implement this search, it requires that the 'Update' data model is being populated. This can be accomplished by ingesting Windows events or the Windows Update log via a universal forwarder on the Windows endpoints you wish to monitor. The Windows add-on should be also be installed and configured to properly parse Windows events in Splunk. There may be other data sources which can populate this data model, including vulnerability management systems. action.escu.known_false_positives = None identified -action.escu.creation_date = 2017-09-15 -action.escu.modification_date = 2017-09-15 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - No Windows Updates in a time frame - Rule action.escu.search_type = detection @@ -343,7 +343,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - No Windows Updates in a time frame - Rule action.correlationsearch.annotations = {"analytic_story": ["Monitor for Updates"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1a77c08c-2f56-409c-a2d3-7d64617edd4f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1a77c08c-2f56-409c-a2d3-7d64617edd4f", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -359,14 +359,14 @@ search = | tstats `security_content_summariesonly` max(_time) as lastTime from d [ESCU - Okta Authentication Failed During MFA Challenge - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an authentication attempt event against an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +description = The following analytic identifies failed authentication attempts during the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication datamodel to detect specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This activity is significant as it may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = The following analytic identifies an authentication attempt event against an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.escu.eli5 = The following analytic identifies failed authentication attempts during the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication datamodel to detect specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This activity is significant as it may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = A user may have accidentally entered the wrong credentials during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. Ensure that the user is aware of the MFA process and has the correct credentials. -action.escu.creation_date = 2024-03-11 -action.escu.modification_date = 2024-03-11 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Authentication Failed During MFA Challenge - Rule action.escu.search_type = detection @@ -384,11 +384,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Authentication Failed During MFA Challenge - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e2b99e7d-d956-411a-a120-2b14adfdde93", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e2b99e7d-d956-411a-a120-2b14adfdde93", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an authentication attempt event against an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.notable.param.rule_description = The following analytic identifies failed authentication attempts during the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication datamodel to detect specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This activity is significant as it may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.notable.param.rule_title = Okta Authentication Failed During MFA Challenge action.notable.param.security_domain = identity action.notable.param.severity = high @@ -406,14 +406,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Okta IDP Lifecycle Modifications - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational. +description = The following analytic identifies modifications to Okta Identity Provider (IDP) lifecycle events, including creation, activation, deactivation, and deletion of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms. Unauthorized or anomalous changes could indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could manipulate authentication processes, potentially gaining unauthorized access or disrupting identity management systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational. +action.escu.eli5 = The following analytic identifies modifications to Okta Identity Provider (IDP) lifecycle events, including creation, activation, deactivation, and deletion of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms. Unauthorized or anomalous changes could indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could manipulate authentication processes, potentially gaining unauthorized access or disrupting identity management systems. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta IDP Lifecycle Modifications - Rule action.escu.search_type = detection @@ -431,7 +431,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta IDP Lifecycle Modifications - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Okta Activity"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e0be2c83-5526-4219-a14f-c3db2e763d15", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e0be2c83-5526-4219-a14f-c3db2e763d15", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -447,14 +447,14 @@ search = `okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecy [ESCU - Okta MFA Exhaustion Hunt - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies patterns within Okta data to determine the amount of successful and failed pushes. Based on that, eval statements determine a finding of whether this is suspicious or not. The events are within a window of time and may be tuned as needed. +description = The following analytic detects patterns of successful and failed Okta MFA push attempts to identify potential MFA exhaustion attacks. It leverages Okta event logs, specifically focusing on push verification events, and uses statistical evaluations to determine suspicious activity. This activity is significant as it may indicate an attacker attempting to bypass MFA by overwhelming the user with push notifications. If confirmed malicious, this could lead to unauthorized access, compromising the security of the affected accounts and potentially the entire environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = The following analytic identifies patterns within Okta data to determine the amount of successful and failed pushes. Based on that, eval statements determine a finding of whether this is suspicious or not. The events are within a window of time and may be tuned as needed. +action.escu.eli5 = The following analytic detects patterns of successful and failed Okta MFA push attempts to identify potential MFA exhaustion attacks. It leverages Okta event logs, specifically focusing on push verification events, and uses statistical evaluations to determine suspicious activity. This activity is significant as it may indicate an attacker attempting to bypass MFA by overwhelming the user with push notifications. If confirmed malicious, this could lead to unauthorized access, compromising the security of the affected accounts and potentially the entire environment. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete. -action.escu.creation_date = 2022-09-27 -action.escu.modification_date = 2022-09-27 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta MFA Exhaustion Hunt - Rule action.escu.search_type = detection @@ -467,7 +467,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta MFA Exhaustion Hunt - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover", "Okta MFA Exhaustion"], "cis20": ["CIS 10"], "confidence": 60, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "97e2fe57-3740-402c-988a-76b64ce04b8d", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "97e2fe57-3740-402c-988a-76b64ce04b8d", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -483,32 +483,14 @@ search = `okta` eventType=system.push.send_factor_verify_push OR ((legacyEventTy [ESCU - Okta Mismatch Between Source and Response for Verify Push Request - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic. \ -For each Okta Verify Push challenge, the following two events are recorded in Okta System Log \ -Source of Push (Sign-In) \ -eventType eq \"system.push.send_factor_verify_push\" \ -User Push Response (Okta Verify client) \ -eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" \ -In sequence, the logic for the analytic - \ -* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) \ -* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. * Creates a ratio of successful sign-ins to pushes. \ -* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic. \ -For each Okta Verify Push challenge, the following two events are recorded in Okta System Log \ -Source of Push (Sign-In) \ -eventType eq \"system.push.send_factor_verify_push\" \ -User Push Response (Okta Verify client) \ -eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" \ -In sequence, the logic for the analytic - \ -* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) \ -* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. * Creates a ratio of successful sign-ins to pushes. \ -* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session. +action.escu.eli5 = The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed. -action.escu.creation_date = 2023-03-17 -action.escu.modification_date = 2023-03-17 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Mismatch Between Source and Response for Verify Push Request - Rule action.escu.search_type = detection @@ -526,20 +508,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Okta Mismatch Between Source and Response for Verify Push Request - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover", "Okta MFA Exhaustion"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8085b79b-9b85-4e67-ad63-351c9e9a5e9a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8085b79b-9b85-4e67-ad63-351c9e9a5e9a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic. \ -For each Okta Verify Push challenge, the following two events are recorded in Okta System Log \ -Source of Push (Sign-In) \ -eventType eq \"system.push.send_factor_verify_push\" \ -User Push Response (Okta Verify client) \ -eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" \ -In sequence, the logic for the analytic - \ -* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) \ -* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. * Creates a ratio of successful sign-ins to pushes. \ -* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session. +action.notable.param.rule_description = The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems. action.notable.param.rule_title = Okta Mismatch Between Source and Response for Verify Push Request action.notable.param.security_domain = access action.notable.param.severity = high @@ -557,14 +530,14 @@ search = `okta` eventType IN (system.push.send_factor_verify_push) OR (eventType [ESCU - Okta Multi-Factor Authentication Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +description = The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.escu.eli5 = The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = Legitimate use case may require for users to disable MFA. Filter lightly and monitor for any unusual activity. -action.escu.creation_date = 2024-03-11 -action.escu.modification_date = 2024-03-11 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Multi-Factor Authentication Disabled - Rule action.escu.search_type = detection @@ -582,11 +555,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Multi-Factor Authentication Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7c0348ce-bdf9-45f6-8a57-c18b5976f00a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7c0348ce-bdf9-45f6-8a57-c18b5976f00a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.notable.param.rule_description = The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network. action.notable.param.rule_title = Okta Multi-Factor Authentication Disabled action.notable.param.security_domain = identity action.notable.param.severity = high @@ -604,14 +577,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime [ESCU - Okta Multiple Accounts Locked Out - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts. +description = The following analytic detects multiple Okta accounts being locked out within a short period. It uses the user.account.lock event from Okta logs, aggregated over a 5-minute window, to identify this behavior. This activity is significant as it may indicate a brute force or password spraying attack, where an adversary attempts to guess passwords, leading to account lockouts. If confirmed malicious, this could result in potential account takeovers or unauthorized access to sensitive Okta accounts, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts. +action.escu.eli5 = The following analytic detects multiple Okta accounts being locked out within a short period. It uses the user.account.lock event from Okta logs, aggregated over a 5-minute window, to identify this behavior. This activity is significant as it may indicate a brute force or password spraying attack, where an adversary attempts to guess passwords, leading to account lockouts. If confirmed malicious, this could result in potential account takeovers or unauthorized access to sensitive Okta accounts, posing a significant security risk. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity. -action.escu.creation_date = 2024-03-06 -action.escu.modification_date = 2024-03-06 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Multiple Accounts Locked Out - Rule action.escu.search_type = detection @@ -629,7 +602,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Multiple Accounts Locked Out - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a511426e-184f-4de6-8711-cfd2af29d1e1", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a511426e-184f-4de6-8711-cfd2af29d1e1", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -645,14 +618,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime, [ESCU - Okta Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity. -action.escu.creation_date = 2024-03-05 -action.escu.modification_date = 2024-03-05 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -660,7 +633,7 @@ action.escu.product = ["Splunk Enterprise", "Splunk Enterprise Security", "Splun action.escu.providing_technologies = ["Okta"] action.escu.analytic_story = ["Okta Account Takeover"] action.risk = 1 -action.risk.param._risk_message = Multiple failed MFA requests for user [$src_user$] from IP Address - [$src_ip$]. Investigate further to determine if this was authorized. +action.risk.param._risk_message = Multiple failed MFA requests for user $src_user$ from IP Address - $src_ip$ action.risk.param._risk = [{"threat_object_field": "src_ip", "threat_object_type": "ip_address"}, {"risk_object_field": "src_user", "risk_object_type": "user", "risk_score": 42}] action.risk.param._risk_score = 0 action.risk.param.verbose = 0 @@ -670,7 +643,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "826dbaae-a1e6-4c8c-b384-d16898956e73", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "826dbaae-a1e6-4c8c-b384-d16898956e73", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -681,27 +654,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR | bucket _time span=5m | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) by _time src_user | where count >= 5 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multiple_failed_mfa_requests_for_user_filter` +search = `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR | bucket _time span=5m | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) by _time src_user | where count >= 10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multiple_failed_mfa_requests_for_user_filter` [ESCU - Okta Multiple Failed Requests to Access Applications - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows: * Retrieves policy evaluation and SSO details in events that contain the Application requested \ -* Formats target fields so we can aggregate specifically on Applications (AppInstances) \ -* Groups by User, Session and IP \ -* Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies \ -* Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects multiple failed attempts to access applications in Okta, potentially indicating the reuse of a stolen web session cookie. It leverages Okta logs to evaluate policy and SSO events, aggregating data by user, session, and IP. The detection triggers when more than half of the app sign-on attempts are unsuccessful across multiple applications. This activity is significant as it may indicate an attempt to bypass authentication mechanisms. If confirmed malicious, it could lead to unauthorized access to sensitive applications and data, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550.004", "T1538"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows: * Retrieves policy evaluation and SSO details in events that contain the Application requested \ -* Formats target fields so we can aggregate specifically on Applications (AppInstances) \ -* Groups by User, Session and IP \ -* Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies \ -* Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps. +action.escu.eli5 = The following analytic detects multiple failed attempts to access applications in Okta, potentially indicating the reuse of a stolen web session cookie. It leverages Okta logs to evaluate policy and SSO events, aggregating data by user, session, and IP. The detection triggers when more than half of the app sign-on attempts are unsuccessful across multiple applications. This activity is significant as it may indicate an attempt to bypass authentication mechanisms. If confirmed malicious, it could lead to unauthorized access to sensitive applications and data, posing a significant security risk. action.escu.how_to_implement = This analytic is specific to Okta and requires Okta:im2 logs to be ingested. action.escu.known_false_positives = False positives may be present based on organization size and configuration of Okta. -action.escu.creation_date = 2023-03-17 -action.escu.modification_date = 2023-03-17 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Multiple Failed Requests to Access Applications - Rule action.escu.search_type = detection @@ -714,7 +679,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Okta Multiple Failed Requests to Access Applications - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550.004", "T1538"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c21fed1-7000-4a2e-9105-5aaafa437247", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c21fed1-7000-4a2e-9105-5aaafa437247", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -730,14 +695,14 @@ search = `okta` target{}.type=AppInstance (eventType=policy.evaluate_sign_on out [ESCU - Okta Multiple Users Failing To Authenticate From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts. +description = The following analytic identifies instances where more than 10 unique user accounts have failed to authenticate from a single IP address within a 5-minute window in an Okta tenant. This detection uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to compromise multiple user accounts, potentially leading to unauthorized access to organizational resources and data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts. +action.escu.eli5 = The following analytic identifies instances where more than 10 unique user accounts have failed to authenticate from a single IP address within a 5-minute window in an Okta tenant. This detection uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to compromise multiple user accounts, potentially leading to unauthorized access to organizational resources and data breaches. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. -action.escu.creation_date = 2024-03-06 -action.escu.modification_date = 2024-03-06 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Multiple Users Failing To Authenticate From Ip - Rule action.escu.search_type = detection @@ -755,7 +720,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Multiple Users Failing To Authenticate From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de365ffa-42f5-46b5-b43f-fa72290b8218", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de365ffa-42f5-46b5-b43f-fa72290b8218", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -771,14 +736,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime [ESCU - Okta New API Token Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts. +description = The following analytic detects the creation of a new API token within an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to identify events where the `system.api_token.create` command is executed. This activity is significant because creating a new API token can indicate potential account takeover attempts or unauthorized access, allowing an adversary to maintain persistence. If confirmed malicious, this could enable attackers to execute API calls, access sensitive data, and perform administrative actions within the Okta environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts. +action.escu.eli5 = The following analytic detects the creation of a new API token within an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to identify events where the `system.api_token.create` command is executed. This activity is significant because creating a new API token can indicate potential account takeover attempts or unauthorized access, allowing an adversary to maintain persistence. If confirmed malicious, this could enable attackers to execute API calls, access sensitive data, and perform administrative actions within the Okta environment. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. -action.escu.creation_date = 2022-09-21 -action.escu.modification_date = 2022-09-21 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta New API Token Created - Rule action.escu.search_type = detection @@ -796,11 +761,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta New API Token Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c3d22720-35d3-4da4-bd0a-740d37192bd4", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c3d22720-35d3-4da4-bd0a-740d37192bd4", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts. +action.notable.param.rule_description = The following analytic detects the creation of a new API token within an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to identify events where the `system.api_token.create` command is executed. This activity is significant because creating a new API token can indicate potential account takeover attempts or unauthorized access, allowing an adversary to maintain persistence. If confirmed malicious, this could enable attackers to execute API calls, access sensitive data, and perform administrative actions within the Okta environment. action.notable.param.rule_title = Okta New API Token Created action.notable.param.security_domain = access action.notable.param.severity = high @@ -818,14 +783,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime [ESCU - Okta New Device Enrolled on Account - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts. +description = The following analytic identifies when a new device is enrolled on an Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to detect the creation of new device enrollments. This activity is significant as it may indicate a legitimate user setting up a new device or an adversary adding a device to maintain unauthorized access. If confirmed malicious, this could lead to potential account takeover, unauthorized access, and persistent control over the compromised Okta account. Monitoring this behavior is crucial for detecting and mitigating unauthorized access attempts. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts. +action.escu.eli5 = The following analytic identifies when a new device is enrolled on an Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to detect the creation of new device enrollments. This activity is significant as it may indicate a legitimate user setting up a new device or an adversary adding a device to maintain unauthorized access. If confirmed malicious, this could lead to potential account takeover, unauthorized access, and persistent control over the compromised Okta account. Monitoring this behavior is crucial for detecting and mitigating unauthorized access attempts. action.escu.how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = It is possible that the user has legitimately added a new device to their account. Please verify this activity. -action.escu.creation_date = 2024-03-08 -action.escu.modification_date = 2024-03-08 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta New Device Enrolled on Account - Rule action.escu.search_type = detection @@ -843,11 +808,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta New Device Enrolled on Account - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 40, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb27cbce-d4de-432c-932f-2e206e9130fb", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb27cbce-d4de-432c-932f-2e206e9130fb", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts. +action.notable.param.rule_description = The following analytic identifies when a new device is enrolled on an Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to detect the creation of new device enrollments. This activity is significant as it may indicate a legitimate user setting up a new device or an adversary adding a device to maintain unauthorized access. If confirmed malicious, this could lead to potential account takeover, unauthorized access, and persistent control over the compromised Okta account. Monitoring this behavior is crucial for detecting and mitigating unauthorized access attempts. action.notable.param.rule_title = Okta New Device Enrolled on Account action.notable.param.security_domain = identity action.notable.param.severity = high @@ -865,14 +830,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime [ESCU - Okta Phishing Detection with FastPass Origin Check - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies failed user authentication attempts in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically looking for events where multi-factor authentication (MFA) fails with the reason "FastPass declined phishing attempt." This activity is significant as it indicates that attackers are targeting users with real-time phishing proxies, attempting to capture credentials. If confirmed malicious, this could lead to unauthorized access to user accounts, potentially compromising sensitive information and furthering lateral movement within the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1556"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers. +action.escu.eli5 = The following analytic identifies failed user authentication attempts in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically looking for events where multi-factor authentication (MFA) fails with the reason "FastPass declined phishing attempt." This activity is significant as it indicates that attackers are targeting users with real-time phishing proxies, attempting to capture credentials. If confirmed malicious, this could lead to unauthorized access to user accounts, potentially compromising sensitive information and furthering lateral movement within the organization. action.escu.how_to_implement = This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment. action.escu.known_false_positives = Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed. -action.escu.creation_date = 2023-03-09 -action.escu.modification_date = 2023-03-09 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Phishing Detection with FastPass Origin Check - Rule action.escu.search_type = detection @@ -890,11 +855,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Okta Phishing Detection with FastPass Origin Check - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 100, "impact": 100, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1556"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4ca0057-cbf3-44f8-82ea-4e330ee901d3", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4ca0057-cbf3-44f8-82ea-4e330ee901d3", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers. +action.notable.param.rule_description = The following analytic identifies failed user authentication attempts in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically looking for events where multi-factor authentication (MFA) fails with the reason "FastPass declined phishing attempt." This activity is significant as it indicates that attackers are targeting users with real-time phishing proxies, attempting to capture credentials. If confirmed malicious, this could lead to unauthorized access to user accounts, potentially compromising sensitive information and furthering lateral movement within the organization. action.notable.param.rule_title = Okta Phishing Detection with FastPass Origin Check action.notable.param.security_domain = access action.notable.param.severity = high @@ -912,14 +877,14 @@ search = `okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE [ESCU - Okta Risk Threshold Exceeded - Rule] action.escu = 0 action.escu.enabled = 1 -description = This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user. +description = The following correlation identifies when a user exceeds a risk threshold based on multiple suspicious Okta activities. It leverages the Risk Framework from Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is significant as it highlights potentially compromised user accounts exhibiting multiple tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed malicious, this activity could indicate a serious security breach, allowing attackers to gain unauthorized access, escalate privileges, or persist within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1110"], "nist": ["DE.AE"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user. +action.escu.eli5 = The following correlation identifies when a user exceeds a risk threshold based on multiple suspicious Okta activities. It leverages the Risk Framework from Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is significant as it highlights potentially compromised user accounts exhibiting multiple tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed malicious, this activity could indicate a serious security breach, allowing attackers to gain unauthorized access, escalate privileges, or persist within the environment. action.escu.how_to_implement = This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories are enabled. TTPs may be set to Notables for point detections; anomalies should not be notables but rather risk generators. The correlation relies on risk before generating a notable. Modify the value as needed. action.escu.known_false_positives = False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization. -action.escu.creation_date = 2024-04-02 -action.escu.modification_date = 2024-04-02 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Risk Threshold Exceeded - Rule action.escu.search_type = detection @@ -932,11 +897,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - RIR - Okta Risk Threshold Exceeded - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover", "Okta MFA Exhaustion", "Suspicious Okta Activity"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1110"], "nist": ["DE.AE"], "type": "Correlation"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d8b967dd-657f-4d88-93b5-c588bcd7218c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d8b967dd-657f-4d88-93b5-c588bcd7218c", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user. +action.notable.param.rule_description = The following correlation identifies when a user exceeds a risk threshold based on multiple suspicious Okta activities. It leverages the Risk Framework from Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is significant as it highlights potentially compromised user accounts exhibiting multiple tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed malicious, this activity could indicate a serious security breach, allowing attackers to gain unauthorized access, escalate privileges, or persist within the environment. action.notable.param.rule_title = RBA: Okta Risk Threshold Exceeded action.notable.param.security_domain = access action.notable.param.severity = high @@ -954,14 +919,14 @@ search = | tstats `security_content_summariesonly` values(All_Risk.analyticstori [ESCU - Okta Successful Single Factor Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search. +description = The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search. +action.escu.eli5 = The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment. action.escu.how_to_implement = This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary. -action.escu.creation_date = 2024-04-08 -action.escu.modification_date = 2024-04-08 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Successful Single Factor Authentication - Rule action.escu.search_type = detection @@ -979,7 +944,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Successful Single Factor Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "98f6ad4f-4325-4096-9d69-45dc8e638e82", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "98f6ad4f-4325-4096-9d69-45dc8e638e82", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1042,20 +1007,14 @@ search = `okta` eventType=user.account.report_suspicious_activity_by_enduser | s [ESCU - Okta Suspicious Use of a Session Cookie - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. A detection opportunity arises when an adversary attempts to reuse a stolen web session cookie. \ -* Retrieves policy evaluation events from successful authentication events. \ -* Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window. \ -* It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination. +description = The following analytic identifies suspicious use of a session cookie by detecting multiple client values (IP, User Agent, etc.) changing for the same Device Token associated with a specific user. It leverages policy evaluation events from successful authentication logs in Okta. This activity is significant as it may indicate an adversary attempting to reuse a stolen web session cookie, potentially bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized access to user accounts, leading to data breaches or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1539"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. A detection opportunity arises when an adversary attempts to reuse a stolen web session cookie. \ -* Retrieves policy evaluation events from successful authentication events. \ -* Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window. \ -* It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination. +action.escu.eli5 = The following analytic identifies suspicious use of a session cookie by detecting multiple client values (IP, User Agent, etc.) changing for the same Device Token associated with a specific user. It leverages policy evaluation events from successful authentication logs in Okta. This activity is significant as it may indicate an adversary attempting to reuse a stolen web session cookie, potentially bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized access to user accounts, leading to data breaches or further exploitation within the environment. action.escu.how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = False positives may occur, depending on the organization's size and the configuration of Okta. -action.escu.creation_date = 2024-03-17 -action.escu.modification_date = 2024-03-17 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Suspicious Use of a Session Cookie - Rule action.escu.search_type = detection @@ -1073,7 +1032,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Suspicious Use of a Session Cookie - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover", "Suspicious Okta Activity"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1539"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71ad47d1-d6bd-4e0a-b35c-020ad9a6959e", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71ad47d1-d6bd-4e0a-b35c-020ad9a6959e", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1089,14 +1048,14 @@ search = `okta` eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, [ESCU - Okta ThreatInsight Threat Detected - Rule] action.escu = 0 action.escu.enabled = 1 -description = This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users. +description = The following analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on security.threat.detected events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users. +action.escu.eli5 = The following analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on security.threat.detected events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture. action.escu.how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = False positives may occur. It is recommended to fine-tune Okta settings and the analytic to ensure high fidelity. Adjust the risk score as necessary. -action.escu.creation_date = 2022-09-21 -action.escu.modification_date = 2022-09-21 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta ThreatInsight Threat Detected - Rule action.escu.search_type = detection @@ -1114,7 +1073,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta ThreatInsight Threat Detected - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "140504ae-5fe2-4d65-b2bc-a211813fbca6", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "140504ae-5fe2-4d65-b2bc-a211813fbca6", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1130,14 +1089,14 @@ search = `okta` eventType = security.threat.detected | rename client.geographica [ESCU - Okta Unauthorized Access to Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment. +description = The following analytic identifies attempts by users to access Okta applications that have not been assigned to them. It leverages Okta Identity Management logs, specifically focusing on failed access attempts to unassigned applications. This activity is significant for a SOC as it may indicate potential unauthorized access attempts, which could lead to exposure of sensitive information or disruption of services. If confirmed malicious, such activity could result in data breaches, non-compliance with data protection laws, and overall compromise of the IT environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment. +action.escu.eli5 = The following analytic identifies attempts by users to access Okta applications that have not been assigned to them. It leverages Okta Identity Management logs, specifically focusing on failed access attempts to unassigned applications. This activity is significant for a SOC as it may indicate potential unauthorized access attempts, which could lead to exposure of sensitive information or disruption of services. If confirmed malicious, such activity could result in data breaches, non-compliance with data protection laws, and overall compromise of the IT environment. action.escu.how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = There is a possibility that a user may accidentally click on the wrong application, which could trigger this event. It is advisable to verify the location from which this activity originates. -action.escu.creation_date = 2024-03-07 -action.escu.modification_date = 2024-03-07 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta Unauthorized Access to Application - Rule action.escu.search_type = detection @@ -1155,7 +1114,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta Unauthorized Access to Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f661629-9750-4cb9-897c-1f05d6db8727", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f661629-9750-4cb9-897c-1f05d6db8727", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1171,14 +1130,14 @@ search = | tstats values(Authentication.app) as app values(Authentication.action [ESCU - Okta User Logins from Multiple Cities - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches. +description = The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1586.003"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches. +action.escu.eli5 = The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment. action.escu.how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). action.escu.known_false_positives = It is uncommon for a user to log in from multiple cities simultaneously, which may indicate a false positive. -action.escu.creation_date = 2024-03-07 -action.escu.modification_date = 2024-03-07 +action.escu.creation_date = 2024-05-09 +action.escu.modification_date = 2024-05-09 action.escu.confidence = high action.escu.full_search_name = ESCU - Okta User Logins from Multiple Cities - Rule action.escu.search_type = detection @@ -1196,7 +1155,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Okta User Logins from Multiple Cities - Rule action.correlationsearch.annotations = {"analytic_story": ["Okta Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1586.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a3d1df37-c2a9-41d0-aa8f-59f82d6192a8", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a3d1df37-c2a9-41d0-aa8f-59f82d6192a8", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1212,14 +1171,14 @@ search = | tstats `security_content_summariesonly` values(Authentication.app) a [ESCU - Path traversal SPL injection - Rule] action.escu = 0 action.escu.enabled = 1 -description = On May 3rd, 2022, Splunk published a security advisory for a Path traversal in search parameter that can potentiall allow SPL injection. An attacker can cause the application to load data from incorrect endpoints, urls leading to outcomes such as running arbitrary SPL queries. +description = The following analytic identifies attempts at path traversal in search parameters, which can lead to SPL injection. It detects this activity by searching for specific patterns in the `_internal` index that indicate path traversal attempts (e.g., "../../../../"). This activity is significant for a SOC because it can allow an attacker to manipulate the application to load data from incorrect endpoints, potentially running arbitrary SPL queries. If confirmed malicious, this could lead to unauthorized data access, code execution, or further exploitation of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = On May 3rd, 2022, Splunk published a security advisory for a Path traversal in search parameter that can potentiall allow SPL injection. An attacker can cause the application to load data from incorrect endpoints, urls leading to outcomes such as running arbitrary SPL queries. +action.escu.eli5 = The following analytic identifies attempts at path traversal in search parameters, which can lead to SPL injection. It detects this activity by searching for specific patterns in the `_internal` index that indicate path traversal attempts (e.g., "../../../../"). This activity is significant for a SOC because it can allow an attacker to manipulate the application to load data from incorrect endpoints, potentially running arbitrary SPL queries. If confirmed malicious, this could lead to unauthorized data access, code execution, or further exploitation of the Splunk environment. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This search will provide search UI requests with path traversal parameter ("../../../../../../../../../") which shows exploitation attempts. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests. action.escu.known_false_positives = This search may find additional path traversal exploitation attempts. -action.escu.creation_date = 2024-03-19 -action.escu.modification_date = 2024-03-19 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Path traversal SPL injection - Rule action.escu.search_type = detection @@ -1237,11 +1196,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Path traversal SPL injection - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "cve": ["CVE-2022-26889"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dfe55688-82ed-4d24-a21b-ed8f0e0fda99", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dfe55688-82ed-4d24-a21b-ed8f0e0fda99", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = On May 3rd, 2022, Splunk published a security advisory for a Path traversal in search parameter that can potentiall allow SPL injection. An attacker can cause the application to load data from incorrect endpoints, urls leading to outcomes such as running arbitrary SPL queries. +action.notable.param.rule_description = The following analytic identifies attempts at path traversal in search parameters, which can lead to SPL injection. It detects this activity by searching for specific patterns in the `_internal` index that indicate path traversal attempts (e.g., "../../../../"). This activity is significant for a SOC because it can allow an attacker to manipulate the application to load data from incorrect endpoints, potentially running arbitrary SPL queries. If confirmed malicious, this could lead to unauthorized data access, code execution, or further exploitation of the Splunk environment. action.notable.param.rule_title = Path traversal SPL injection action.notable.param.security_domain = threat action.notable.param.severity = high @@ -1259,14 +1218,14 @@ search = `path_traversal_spl_injection` | search "\/..\/..\/..\/..\/..\/..\/..\ [ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it. +description = The following analytic identifies potential persistent Cross-Site Scripting (XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface views. It leverages audit logs from the `audit_searches` data source to detect actions involving Base64-encoded images in error messages. This activity is significant because it can allow attackers to inject malicious scripts that execute in the context of other users, leading to unauthorized actions or data exposure. If confirmed malicious, this could result in persistent control over the affected Splunk instance, compromising its integrity and confidentiality. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it. +action.escu.eli5 = The following analytic identifies potential persistent Cross-Site Scripting (XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface views. It leverages audit logs from the `audit_searches` data source to detect actions involving Base64-encoded images in error messages. This activity is significant because it can allow attackers to inject malicious scripts that execute in the context of other users, leading to unauthorized actions or data exposure. If confirmed malicious, this could result in persistent control over the affected Splunk instance, compromising its integrity and confidentiality. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index action.escu.known_false_positives = This is a hunting search, it will not deobfuscate base64 payload, it provides however it will provide what user added the view artifact and what user opened it. It will require further investigation based on the information presented by this hunting search. -action.escu.creation_date = 2023-02-14 -action.escu.modification_date = 2023-02-14 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule action.escu.search_type = detection @@ -1284,11 +1243,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-22932"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce6e1268-e01c-4df2-a617-0f034ed49a43", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce6e1268-e01c-4df2-a617-0f034ed49a43", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it. +action.notable.param.rule_description = The following analytic identifies potential persistent Cross-Site Scripting (XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface views. It leverages audit logs from the `audit_searches` data source to detect actions involving Base64-encoded images in error messages. This activity is significant because it can allow attackers to inject malicious scripts that execute in the context of other users, leading to unauthorized actions or data exposure. If confirmed malicious, this could result in persistent control over the affected Splunk instance, compromising its integrity and confidentiality. action.notable.param.rule_title = Persistent XSS in RapidDiag through User Interface Views action.notable.param.security_domain = threat action.notable.param.severity = high @@ -1306,14 +1265,14 @@ search = `audit_searches` path=/opt/splunk/etc/users/*/search/local/data/ui/view [ESCU - PingID Mismatch Auth Source and Verification Response - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country. +description = The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country. +action.escu.eli5 = The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data. action.escu.how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. action.escu.known_false_positives = False positives may be generated by users working out the geographic region where the organizations services or technology is hosted. -action.escu.creation_date = 2023-09-26 -action.escu.modification_date = 2023-09-26 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - PingID Mismatch Auth Source and Verification Response - Rule action.escu.search_type = detection @@ -1331,11 +1290,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - PingID Mismatch Auth Source and Verification Response - Rule action.correlationsearch.annotations = {"analytic_story": ["Compromised User Account"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "15b0694e-caa2-4009-8d83-a1f98b86d086", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "15b0694e-caa2-4009-8d83-a1f98b86d086", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country. +action.notable.param.rule_description = The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data. action.notable.param.rule_title = PingID Mismatch Auth Source and Verification Response action.notable.param.security_domain = access action.notable.param.severity = high @@ -1353,14 +1312,14 @@ search = `pingid` ("result.status" IN ("SUCCESS*","FAIL*","UNSUCCESSFUL*") NOT " [ESCU - PingID Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within a PingID environment. It triggers when 10 or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access, as the user might eventually accept the fraudulent request, compromising the security of the account and potentially the entire network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1621", "T1078", "T1110"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within a PingID environment. It triggers when 10 or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access, as the user might eventually accept the fraudulent request, compromising the security of the account and potentially the entire network. action.escu.how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. action.escu.known_false_positives = False positives may be generated by normal provisioning workflows for user device registration. -action.escu.creation_date = 2023-09-26 -action.escu.modification_date = 2023-09-26 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - PingID Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -1378,11 +1337,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - PingID Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Compromised User Account"], "cis20": ["CIS 10"], "confidence": 50, "impact": 100, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1621", "T1078", "T1110"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c1bc706a-0025-4814-ad30-288f38865036", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c1bc706a-0025-4814-ad30-288f38865036", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.notable.param.rule_description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within a PingID environment. It triggers when 10 or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access, as the user might eventually accept the fraudulent request, compromising the security of the account and potentially the entire network. action.notable.param.rule_title = PingID Multiple Failed MFA Requests For User action.notable.param.security_domain = access action.notable.param.severity = high @@ -1400,14 +1359,14 @@ search = `pingid` "result.status" IN ("FAILURE,authFail","UNSUCCESSFUL_ATTEMPT") [ESCU - PingID New MFA Method After Credential Reset - Rule] action.escu = 0 action.escu.enabled = 1 -description = A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning. +description = The following analytic identifies the provisioning of a new MFA device shortly after a password reset. It detects this activity by correlating Windows Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating device pairing. This behavior is significant as it may indicate a social engineering attack where a threat actor impersonates a valid user to reset credentials and add a new MFA device. If confirmed malicious, this activity could allow an attacker to gain persistent access to the compromised account, bypassing traditional security measures. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning. +action.escu.eli5 = The following analytic identifies the provisioning of a new MFA device shortly after a password reset. It detects this activity by correlating Windows Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating device pairing. This behavior is significant as it may indicate a social engineering attack where a threat actor impersonates a valid user to reset credentials and add a new MFA device. If confirmed malicious, this activity could allow an attacker to gain persistent access to the compromised account, bypassing traditional security measures. action.escu.how_to_implement = Target environment must ingest Windows Event Log and PingID(PingOne) data sources. Specifically from logs from Active Directory Domain Controllers and JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription. action.escu.known_false_positives = False positives may be generated by normal provisioning workflows that generate a password reset followed by a device registration. -action.escu.creation_date = 2023-09-26 -action.escu.modification_date = 2023-09-26 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - PingID New MFA Method After Credential Reset - Rule action.escu.search_type = detection @@ -1425,11 +1384,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - PingID New MFA Method After Credential Reset - Rule action.correlationsearch.annotations = {"analytic_story": ["Compromised User Account"], "cis20": ["CIS 10"], "confidence": 50, "impact": 100, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2fcbce12-cffa-4c84-b70c-192604d201d0", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2fcbce12-cffa-4c84-b70c-192604d201d0", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning. +action.notable.param.rule_description = The following analytic identifies the provisioning of a new MFA device shortly after a password reset. It detects this activity by correlating Windows Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating device pairing. This behavior is significant as it may indicate a social engineering attack where a threat actor impersonates a valid user to reset credentials and add a new MFA device. If confirmed malicious, this activity could allow an attacker to gain persistent access to the compromised account, bypassing traditional security measures. action.notable.param.rule_title = PingID New MFA Method After Credential Reset action.notable.param.security_domain = access action.notable.param.severity = high @@ -1530,14 +1489,14 @@ search = `splunk_python` *runshellscript* | eval log_split=split(_raw, "runshel [ESCU - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. Splunk drilldown vulnerability disclosure in Dashboard application that can potentially allow exposure of tokens from privilege users. An attacker can create dashboard and share it to privileged user (admin) and detokenize variables using external urls within dashboards drilldown function. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies the presence of environment variables in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for specific patterns in the XML data. This activity is significant because it can expose sensitive tokens from privileged users if an attacker shares a malicious dashboard. If confirmed malicious, this could allow an attacker to detokenize variables and potentially gain unauthorized access to sensitive information or escalate privileges within the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = Splunk drilldown vulnerability disclosure in Dashboard application that can potentially allow exposure of tokens from privilege users. An attacker can create dashboard and share it to privileged user (admin) and detokenize variables using external urls within dashboards drilldown function. +action.escu.eli5 = The following analytic identifies the presence of environment variables in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for specific patterns in the XML data. This activity is significant because it can expose sensitive tokens from privileged users if an attacker shares a malicious dashboard. If confirmed malicious, this could allow an attacker to detokenize variables and potentially gain unauthorized access to sensitive information or escalate privileges within the Splunk environment. action.escu.how_to_implement = This search uses REST function to query for dashboards with environment variables present in URL options. action.escu.known_false_positives = This search may reveal non malicious URLs with environment variables used in organizations. -action.escu.creation_date = 2022-08-02 -action.escu.modification_date = 2022-08-02 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule action.escu.search_type = detection @@ -1555,11 +1514,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "cve": ["CVE-2022-37438"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f844c3f6-fd99-43a2-ba24-93e35fe84be6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f844c3f6-fd99-43a2-ba24-93e35fe84be6", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Splunk drilldown vulnerability disclosure in Dashboard application that can potentially allow exposure of tokens from privilege users. An attacker can create dashboard and share it to privileged user (admin) and detokenize variables using external urls within dashboards drilldown function. +action.notable.param.rule_description = The following analytic identifies the presence of environment variables in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for specific patterns in the XML data. This activity is significant because it can expose sensitive tokens from privileged users if an attacker shares a malicious dashboard. If confirmed malicious, this could allow an attacker to detokenize variables and potentially gain unauthorized access to sensitive information or escalate privileges within the Splunk environment. action.notable.param.rule_title = Splunk Account Discovery Drilldown Dashboard Disclosure action.notable.param.security_domain = threat action.notable.param.severity = high @@ -1613,14 +1572,14 @@ search = | rest splunk_server=local /services/data/lookup-table-files/ | fields [ESCU - Splunk Authentication Token Exposure in Debug Log - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG. +description = The following analytic identifies exposed authentication tokens in debug logs within Splunk Enterprise. It leverages logs from the `splunkd` component with a DEBUG log level, specifically searching for event messages that validate tokens. This activity is significant because exposed tokens can be exploited by attackers to gain unauthorized access to the Splunk environment. If confirmed malicious, this exposure could lead to unauthorized data access, privilege escalation, and potential compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability is crucial for maintaining the security and integrity of the Splunk deployment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1654"], "nist": ["DE.CM"]} action.escu.data_models = ["Web"] -action.escu.eli5 = This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG. +action.escu.eli5 = The following analytic identifies exposed authentication tokens in debug logs within Splunk Enterprise. It leverages logs from the `splunkd` component with a DEBUG log level, specifically searching for event messages that validate tokens. This activity is significant because exposed tokens can be exploited by attackers to gain unauthorized access to the Splunk environment. If confirmed malicious, this exposure could lead to unauthorized data access, privilege escalation, and potential compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability is crucial for maintaining the security and integrity of the Splunk deployment. action.escu.how_to_implement = Requires access to internal Splunk indexes. action.escu.known_false_positives = Only applies to affected versions of Splunk Enterprise below 9.2.1, 9.1.4, and 9.0.9 -action.escu.creation_date = 2024-03-18 -action.escu.modification_date = 2024-03-18 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Authentication Token Exposure in Debug Log - Rule action.escu.search_type = detection @@ -1638,11 +1597,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Authentication Token Exposure in Debug Log - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2024-29945"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1654"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9a67e749-d291-40dd-8376-d422e7ecf8b5", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9a67e749-d291-40dd-8376-d422e7ecf8b5", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG. +action.notable.param.rule_description = The following analytic identifies exposed authentication tokens in debug logs within Splunk Enterprise. It leverages logs from the `splunkd` component with a DEBUG log level, specifically searching for event messages that validate tokens. This activity is significant because exposed tokens can be exploited by attackers to gain unauthorized access to the Splunk environment. If confirmed malicious, this exposure could lead to unauthorized data access, privilege escalation, and potential compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability is crucial for maintaining the security and integrity of the Splunk deployment. action.notable.param.rule_title = Splunk Authentication Token Exposure in Debug Log action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -1660,14 +1619,14 @@ search = `splunkd` component=JsonWebToken log_level=DEBUG eventtype="splunkd-log [ESCU - Splunk Code Injection via custom dashboard leading to RCE - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This hunting search provides information about a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can execute arbitrary code via the dashboard pdf generation component. Please review events with file=export in the _internal index for the potential targets of exploitation. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies attempts to exploit a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, where an authenticated user can execute arbitrary code via the dashboard PDF generation component. It detects this activity by analyzing events in the _internal index with the file=export parameter. This behavior is significant because it indicates a potential code injection attack, which could lead to remote code execution (RCE). If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary commands, and potentially compromise the entire Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This hunting search provides information about a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can execute arbitrary code via the dashboard pdf generation component. Please review events with file=export in the _internal index for the potential targets of exploitation. +action.escu.eli5 = The following analytic identifies attempts to exploit a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, where an authenticated user can execute arbitrary code via the dashboard PDF generation component. It detects this activity by analyzing events in the _internal index with the file=export parameter. This behavior is significant because it indicates a potential code injection attack, which could lead to remote code execution (RCE). If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary commands, and potentially compromise the entire Splunk environment. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. action.escu.known_false_positives = Not all exports and downloads are malicious, special attention must be put as well on /en-US/splunkd/__raw/services/pdfgen/render in the context of this search. -action.escu.creation_date = 2022-10-11 -action.escu.modification_date = 2022-10-11 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Code Injection via custom dashboard leading to RCE - Rule action.escu.search_type = detection @@ -1680,7 +1639,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Splunk Code Injection via custom dashboard leading to RCE - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2022-43571"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b06b41d7-9570-4985-8137-0784f582a1b3", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b06b41d7-9570-4985-8137-0784f582a1b3", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1696,14 +1655,14 @@ search = `splunkd_ui` uri_path=*/data/ui/views/* OR uri_path=*saved/searches/* | [ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of the risky command - Delete - that may be utilized in Splunk to delete some or all data queried for. In order to use Delete in Splunk, one must be assigned the role. This is typically not used and should generate an anomaly if it is used. +description = The following analytic detects the use of the 'delete' command in Splunk, which can be used to remove queried data. This detection leverages the Splunk Audit data model, specifically monitoring ad-hoc searches containing the 'delete' command by non-system users. This activity is significant because the 'delete' command is rarely used and can indicate potential data tampering or unauthorized data removal. If confirmed malicious, this activity could lead to the loss of critical log data, hindering incident investigations and compromising the integrity of the monitoring environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Splunk_Audit"] -action.escu.eli5 = The following analytic identifies the use of the risky command - Delete - that may be utilized in Splunk to delete some or all data queried for. In order to use Delete in Splunk, one must be assigned the role. This is typically not used and should generate an anomaly if it is used. +action.escu.eli5 = The following analytic detects the use of the 'delete' command in Splunk, which can be used to remove queried data. This detection leverages the Splunk Audit data model, specifically monitoring ad-hoc searches containing the 'delete' command by non-system users. This activity is significant because the 'delete' command is rarely used and can indicate potential data tampering or unauthorized data removal. If confirmed malicious, this activity could lead to the loss of critical log data, hindering incident investigations and compromising the integrity of the monitoring environment. action.escu.how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index. In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/. action.escu.known_false_positives = False positives may be present if this command is used as a common practice. Filter as needed. -action.escu.creation_date = 2022-05-27 -action.escu.modification_date = 2022-05-27 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule action.escu.search_type = detection @@ -1721,7 +1680,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 30, "cve": ["CVE-2022-32154"], "impact": 90, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8d3d5d5e-ca43-42be-aa1f-bc64375f6b04", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8d3d5d5e-ca43-42be-aa1f-bc64375f6b04", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1737,14 +1696,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule] action.escu = 0 action.escu.enabled = 1 -description = The Splunk platform contains built-in search processing language (SPL) safeguards to warn you when you are about to unknowingly run a search that contains commands that might be a security risk. This warning appears when you click a link or type a URL that loads a search that contains risky commands. The warning does not appear when you create ad hoc searches. This warning alerts you to the possibility of unauthorized actions by a malicious user. Unauthorized actions include - Copying or transferring data (data exfiltration), Deleting data and Overwriting data. All risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga. A possible scenario when this might occur is when a malicious actor creates a search that includes commands that exfiltrate or damage data. The malicious actor then sends an unsuspecting user a link to the search. The URL contains a query string (q) and a search identifier (sid), but the sid is not valid. The malicious actor hopes the user will use the link and the search will run. During analysis, pivot based on user name and filter any user or queries not needed. Queries ran from a dashboard are seen as adhoc queries. When a query runs from a dashboard it will not show in audittrail logs the source dashboard name. The query defaults to adhoc and no Splunk system user activity. In addition, modify this query by removing key commands that generate too much noise, or too little, and create separate queries with higher confidence to alert on. +description = The following analytic identifies the execution of risky commands within the Splunk platform, such as `runshellscript`, `delete`, and `sendemail`. It leverages the Search_Activity data model to detect ad hoc searches containing these commands, excluding those run by the splunk-system-user. This activity is significant because it may indicate attempts at data exfiltration, deletion, or other unauthorized actions by a malicious user. If confirmed malicious, this could lead to data loss, unauthorized data transfer, or system compromise, severely impacting the organization's security posture. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Splunk_Audit"] -action.escu.eli5 = The Splunk platform contains built-in search processing language (SPL) safeguards to warn you when you are about to unknowingly run a search that contains commands that might be a security risk. This warning appears when you click a link or type a URL that loads a search that contains risky commands. The warning does not appear when you create ad hoc searches. This warning alerts you to the possibility of unauthorized actions by a malicious user. Unauthorized actions include - Copying or transferring data (data exfiltration), Deleting data and Overwriting data. All risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga. A possible scenario when this might occur is when a malicious actor creates a search that includes commands that exfiltrate or damage data. The malicious actor then sends an unsuspecting user a link to the search. The URL contains a query string (q) and a search identifier (sid), but the sid is not valid. The malicious actor hopes the user will use the link and the search will run. During analysis, pivot based on user name and filter any user or queries not needed. Queries ran from a dashboard are seen as adhoc queries. When a query runs from a dashboard it will not show in audittrail logs the source dashboard name. The query defaults to adhoc and no Splunk system user activity. In addition, modify this query by removing key commands that generate too much noise, or too little, and create separate queries with higher confidence to alert on. +action.escu.eli5 = The following analytic identifies the execution of risky commands within the Splunk platform, such as `runshellscript`, `delete`, and `sendemail`. It leverages the Search_Activity data model to detect ad hoc searches containing these commands, excluding those run by the splunk-system-user. This activity is significant because it may indicate attempts at data exfiltration, deletion, or other unauthorized actions by a malicious user. If confirmed malicious, this could lead to data loss, unauthorized data transfer, or system compromise, severely impacting the organization's security posture. action.escu.how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index. In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. action.escu.known_false_positives = False positives will be present until properly filtered by Username and search name. -action.escu.creation_date = 2022-05-23 -action.escu.modification_date = 2022-05-23 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule action.escu.search_type = detection @@ -1757,7 +1716,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 40, "cve": ["CVE-2022-32154", "CVE-2024-29946"], "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1cf58ae1-9177-40b8-a26c-8966040f11ae", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1cf58ae1-9177-40b8-a26c-8966040f11ae", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1773,14 +1732,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Splunk Command and Scripting Interpreter Risky SPL MLTK - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection utilizes machine learning model named "risky_command_abuse" trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline". It should be scheduled to run hourly to detect whether a user has run searches containing risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga with abnormally long running time in the past one hour, comparing with his/her past seven days history. This search uses the trained baseline to infer whether a search is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0) +description = The following analytic identifies the execution of risky SPL commands with abnormally long run times by leveraging a machine learning model named "risky_command_abuse." It uses the Splunk Audit data model to compare current search activities against a baseline of the past seven days. This activity is significant for a SOC as it can indicate potential misuse or abuse of powerful SPL commands, which could lead to unauthorized data access or system manipulation. If confirmed malicious, this activity could allow an attacker to execute arbitrary scripts, delete data, or exfiltrate sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Splunk_Audit"] -action.escu.eli5 = This detection utilizes machine learning model named "risky_command_abuse" trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline". It should be scheduled to run hourly to detect whether a user has run searches containing risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga with abnormally long running time in the past one hour, comparing with his/her past seven days history. This search uses the trained baseline to infer whether a search is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0) +action.escu.eli5 = The following analytic identifies the execution of risky SPL commands with abnormally long run times by leveraging a machine learning model named "risky_command_abuse." It uses the Splunk Audit data model to compare current search activities against a baseline of the past seven days. This activity is significant for a SOC as it can indicate potential misuse or abuse of powerful SPL commands, which could lead to unauthorized data access or system manipulation. If confirmed malicious, this activity could allow an attacker to execute arbitrary scripts, delete data, or exfiltrate sensitive information. action.escu.how_to_implement = This detection depends on MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Baseline model needs to be built using "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline" before this search can run. Please note that the current search only finds matches exactly one space between separator bar and risky commands. action.escu.known_false_positives = If the run time of a search exceeds the boundaries of outlier defined by the fitted density function model, false positives can occur, incorrectly labeling a long running search as potentially risky. -action.escu.creation_date = 2022-05-27 -action.escu.modification_date = 2022-05-27 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Command and Scripting Interpreter Risky SPL MLTK - Rule action.escu.search_type = detection @@ -1798,7 +1757,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Command and Scripting Interpreter Risky SPL MLTK - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 40, "cve": ["CVE-2022-32154"], "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "19d0146c-2eae-4e53-8d39-1198a78fa9ca", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "19d0146c-2eae-4e53-8d39-1198a78fa9ca", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1814,14 +1773,14 @@ search = | tstats sum(Search_Activity.total_run_time) AS run_time, values(Search [ESCU - Splunk csrf in the ssg kvstore client endpoint - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability. +description = The following analytic identifies attempts to exploit a cross-site request forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client endpoint. It detects GET requests to the vulnerable endpoint using internal index data, focusing on specific URI paths and HTTP methods. This activity is significant because it can allow unauthorized updates to SSG KV store collections, potentially leading to data manipulation or unauthorized access. If confirmed malicious, this could enable attackers to alter critical configurations or exfiltrate sensitive information, compromising the integrity and security of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability. +action.escu.eli5 = The following analytic identifies attempts to exploit a cross-site request forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client endpoint. It detects GET requests to the vulnerable endpoint using internal index data, focusing on specific URI paths and HTTP methods. This activity is significant because it can allow unauthorized updates to SSG KV store collections, potentially leading to data manipulation or unauthorized access. If confirmed malicious, this could enable attackers to alter critical configurations or exfiltrate sensitive information, compromising the integrity and security of the Splunk environment. action.escu.how_to_implement = Requires access to internal index. action.escu.known_false_positives = This hunting search only applies to the affected versions and setup mentioned in the description of this search, it does not extract payload so it requires manual investigation after executing search. This search will produce false positives. -action.escu.creation_date = 2023-02-14 -action.escu.modification_date = 2023-02-14 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk csrf in the ssg kvstore client endpoint - Rule action.escu.search_type = detection @@ -1839,11 +1798,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk csrf in the ssg kvstore client endpoint - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-22942"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4742d5f7-ce00-45ce-9c79-5e98b43b4410", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4742d5f7-ce00-45ce-9c79-5e98b43b4410", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability. +action.notable.param.rule_description = The following analytic identifies attempts to exploit a cross-site request forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client endpoint. It detects GET requests to the vulnerable endpoint using internal index data, focusing on specific URI paths and HTTP methods. This activity is significant because it can allow unauthorized updates to SSG KV store collections, potentially leading to data manipulation or unauthorized access. If confirmed malicious, this could enable attackers to alter critical configurations or exfiltrate sensitive information, compromising the integrity and security of the Splunk environment. action.notable.param.rule_title = Splunk csrf in the ssg kvstore client endpoint action.notable.param.security_domain = threat action.notable.param.severity = high @@ -1861,14 +1820,14 @@ search = `splunkda` uri_path="/en-US/splunkd/__raw/services/ssg/kvstore_client" [ESCU - Splunk Data exfiltration from Analytics Workspace using sid query - Rule] action.escu = 0 action.escu.enabled = 1 -description = This hunting search allows operator to discover attempts to exfiltrate data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires the attacker to compel a victim to initiate a request within their browser (phishing). The attacker cannot exploit the vulnerability at will. +description = The following analytic identifies attempts to exfiltrate data by executing a prepositioned malicious search ID in Splunk's Analytic Workspace. It leverages the `audit_searches` data source to detect suspicious `mstats` commands indicative of injection attempts. This activity is significant as it may indicate a phishing-based attack where an attacker compels a victim to initiate a malicious request, potentially leading to unauthorized data access. If confirmed malicious, this could result in significant data exfiltration, compromising sensitive information and impacting the organization's security posture. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This hunting search allows operator to discover attempts to exfiltrate data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires the attacker to compel a victim to initiate a request within their browser (phishing). The attacker cannot exploit the vulnerability at will. +action.escu.eli5 = The following analytic identifies attempts to exfiltrate data by executing a prepositioned malicious search ID in Splunk's Analytic Workspace. It leverages the `audit_searches` data source to detect suspicious `mstats` commands indicative of injection attempts. This activity is significant as it may indicate a phishing-based attack where an attacker compels a victim to initiate a malicious request, potentially leading to unauthorized data access. If confirmed malicious, this could result in significant data exfiltration, compromising sensitive information and impacting the organization's security posture. action.escu.how_to_implement = The vulnerability affects only instances with Splunk Web Enabled. After running this search, please run "Splunk Command and Scripting Interpreter Risky SPL MLTK" to gain more insight into potentially risky commands which could lead to data exfiltration. action.escu.known_false_positives = This search may produce false positives. This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. Special attention must be paid to "/en-US/app/search/analytics_workspace?sid=[sid]" which is where the malicious code will be inserted to trigger attack at victim. -action.escu.creation_date = 2022-11-01 -action.escu.modification_date = 2022-11-01 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Data exfiltration from Analytics Workspace using sid query - Rule action.escu.search_type = detection @@ -1881,7 +1840,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Data exfiltration from Analytics Workspace using sid query - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2022-43566"], "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b6d77c6c-f011-4b03-8650-8f10edb7c4a8", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b6d77c6c-f011-4b03-8650-8f10edb7c4a8", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1897,14 +1856,14 @@ search = `audit_searches` info=granted search NOT ("audit_searches") search NOT [ESCU - Splunk Digital Certificates Infrastructure Version - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search will check the TLS validation is properly configured on the search head it is run from as well as its search peers after Splunk version 9. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +description = The following analytic identifies improper TLS validation configuration on Splunk search heads and peers post version 9. It leverages REST API calls to retrieve server information and SSL configuration settings, checking fields like `sslVerifyServerCert` and `sslVerifyServerName`. This activity is significant for a SOC as improper TLS settings can expose the infrastructure to man-in-the-middle attacks and data breaches. If confirmed malicious, attackers could intercept or manipulate data, compromising the integrity and confidentiality of communications within the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search will check the TLS validation is properly configured on the search head it is run from as well as its search peers after Splunk version 9. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +action.escu.eli5 = The following analytic identifies improper TLS validation configuration on Splunk search heads and peers post version 9. It leverages REST API calls to retrieve server information and SSL configuration settings, checking fields like `sslVerifyServerCert` and `sslVerifyServerName`. This activity is significant for a SOC as improper TLS settings can expose the infrastructure to man-in-the-middle attacks and data breaches. If confirmed malicious, attackers could intercept or manipulate data, compromising the integrity and confidentiality of communications within the Splunk environment. action.escu.how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. action.escu.known_false_positives = No known at this time. -action.escu.creation_date = 2022-05-26 -action.escu.modification_date = 2022-05-26 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Digital Certificates Infrastructure Version - Rule action.escu.search_type = detection @@ -1917,7 +1876,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Digital Certificates Infrastructure Version - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2022-32153"], "impact": 50, "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3c162281-7edb-4ebc-b9a4-5087aaf28fa7", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3c162281-7edb-4ebc-b9a4-5087aaf28fa7", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1933,14 +1892,14 @@ search = | rest /services/server/info | table splunk_server version server_roles [ESCU - Splunk Digital Certificates Lack of Encryption - Rule] action.escu = 0 action.escu.enabled = 1 -description = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. In other circumstances, a client may be allowed to publish a forwarder bundle to other clients, which may allow for arbitrary code execution. The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as well. This is a great opportunity to configure TLS across the environment. This search looks for forwarders that are not using TLS and adds risk to those entities. +description = The following analytic identifies Splunk forwarder connections that are not using TLS encryption. It leverages data from the `splunkd` logs, specifically looking for connections where the `ssl` field is set to "false". This activity is significant because unencrypted connections can expose sensitive data and allow unauthorized access, posing a security risk. If confirmed malicious, an attacker could exploit this vulnerability to download or publish forwarder bundles, potentially leading to arbitrary code execution and further compromise of the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. In other circumstances, a client may be allowed to publish a forwarder bundle to other clients, which may allow for arbitrary code execution. The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as well. This is a great opportunity to configure TLS across the environment. This search looks for forwarders that are not using TLS and adds risk to those entities. +action.escu.eli5 = The following analytic identifies Splunk forwarder connections that are not using TLS encryption. It leverages data from the `splunkd` logs, specifically looking for connections where the `ssl` field is set to "false". This activity is significant because unencrypted connections can expose sensitive data and allow unauthorized access, posing a security risk. If confirmed malicious, an attacker could exploit this vulnerability to download or publish forwarder bundles, potentially leading to arbitrary code execution and further compromise of the environment. action.escu.how_to_implement = This anomaly search looks for forwarder connections that are not currently using TLS. It then presents the source IP, the type of forwarder, and the version of the forwarder. You can also remove the "ssl=false" argument from the initial stanza in order to get a full list of all your forwarders that are sending data, and the version of Splunk software they are running, for audit purposes. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. action.escu.known_false_positives = None at this time -action.escu.creation_date = 2022-05-26 -action.escu.modification_date = 2022-05-26 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Digital Certificates Lack of Encryption - Rule action.escu.search_type = detection @@ -1958,7 +1917,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Digital Certificates Lack of Encryption - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "cve": ["CVE-2022-32151"], "impact": 25, "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "386a7ebc-737b-48cf-9ca8-5405459ed508", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "386a7ebc-737b-48cf-9ca8-5405459ed508", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -1974,14 +1933,14 @@ search = `splunkd` group="tcpin_connections" ssl="false" | stats values(sourceIp [ESCU - Splunk DoS Using Malformed SAML Request - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang. +description = The following analytic detects a denial of service (DoS) attempt using a malformed SAML request targeting the /saml/acs REST endpoint in Splunk Enterprise versions lower than 9.0.6 and 8.2.12. It leverages `splunkd` logs, specifically looking for error messages containing "xpointer" in the `expr` field. This activity is significant because it can cause the Splunk daemon to crash or hang, disrupting service availability. If confirmed malicious, this attack could lead to prolonged downtime, impacting the organization's ability to monitor and respond to security events. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang. +action.escu.eli5 = The following analytic detects a denial of service (DoS) attempt using a malformed SAML request targeting the /saml/acs REST endpoint in Splunk Enterprise versions lower than 9.0.6 and 8.2.12. It leverages `splunkd` logs, specifically looking for error messages containing "xpointer" in the `expr` field. This activity is significant because it can cause the Splunk daemon to crash or hang, disrupting service availability. If confirmed malicious, this attack could lead to prolonged downtime, impacting the organization's ability to monitor and respond to security events. action.escu.how_to_implement = To run this search, you must have access to the _internal index. action.escu.known_false_positives = This search will show false positives. The analyst must look for errors and a pointer indicating a malicious file. -action.escu.creation_date = 2023-09-05 -action.escu.modification_date = 2023-09-05 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk DoS Using Malformed SAML Request - Rule action.escu.search_type = detection @@ -1994,7 +1953,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk DoS Using Malformed SAML Request - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 30, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8e8a86d5-f323-4567-95be-8e817e2baee6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8e8a86d5-f323-4567-95be-8e817e2baee6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2046,14 +2005,14 @@ search = `splunk_crash_log` "*Segmentation fault*" | stats count by host _time | [ESCU - Splunk DoS via Malformed S2S Request - Rule] action.escu = 0 action.escu.enabled = 1 -description = On March 24th, 2022, Splunk published a security advisory for a possible Denial of Service stemming from the lack of validation in a specific key-value field in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation in patched versions of Splunk. +description = The following analytic identifies attempts to exploit a Denial of Service (DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread" and the message "Invalid _meta atom." This activity is significant as it targets a known vulnerability that could disrupt Splunk services. If confirmed malicious, this could lead to service outages, impacting the availability and reliability of Splunk for monitoring and analysis. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = On March 24th, 2022, Splunk published a security advisory for a possible Denial of Service stemming from the lack of validation in a specific key-value field in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation in patched versions of Splunk. +action.escu.eli5 = The following analytic identifies attempts to exploit a Denial of Service (DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread" and the message "Invalid _meta atom." This activity is significant as it targets a known vulnerability that could disrupt Splunk services. If confirmed malicious, this could lead to service outages, impacting the availability and reliability of Splunk for monitoring and analysis. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will only find attempted exploitation on versions of Splunk already patched for CVE-2021-3422. action.escu.known_false_positives = None. -action.escu.creation_date = 2022-03-24 -action.escu.modification_date = 2022-03-24 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk DoS via Malformed S2S Request - Rule action.escu.search_type = detection @@ -2071,11 +2030,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk DoS via Malformed S2S Request - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2021-3422"], "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fc246e56-953b-40c1-8634-868f9e474cbd", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fc246e56-953b-40c1-8634-868f9e474cbd", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = On March 24th, 2022, Splunk published a security advisory for a possible Denial of Service stemming from the lack of validation in a specific key-value field in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation in patched versions of Splunk. +action.notable.param.rule_description = The following analytic identifies attempts to exploit a Denial of Service (DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread" and the message "Invalid _meta atom." This activity is significant as it targets a known vulnerability that could disrupt Splunk services. If confirmed malicious, this could lead to service outages, impacting the availability and reliability of Splunk for monitoring and analysis. action.notable.param.rule_title = Splunk DoS via Malformed S2S Request action.notable.param.security_domain = threat action.notable.param.severity = high @@ -2093,14 +2052,14 @@ search = `splunkd` log_level="ERROR" component="TcpInputProc" thread_name="FwdDa [ESCU - Splunk DOS via printf search function - Rule] action.escu = 0 action.escu.enabled = 1 -description = This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance. +description = The following analytic identifies the use of the `printf` SPL function in Splunk searches, which can be exploited for a denial of service (DoS) attack. It detects this activity by querying the `audit_searches` data source for specific patterns involving `makeresults`, `eval`, `fieldformat`, and `printf` functions, excluding searches by the `splunk_system_user`. This activity is significant because it targets a known vulnerability in Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, potentially disrupting the availability of the Splunk instance. If confirmed malicious, this could lead to service outages and impact the monitoring and logging capabilities of the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance. +action.escu.eli5 = The following analytic identifies the use of the `printf` SPL function in Splunk searches, which can be exploited for a denial of service (DoS) attack. It detects this activity by querying the `audit_searches` data source for specific patterns involving `makeresults`, `eval`, `fieldformat`, and `printf` functions, excluding searches by the `splunk_system_user`. This activity is significant because it targets a known vulnerability in Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, potentially disrupting the availability of the Splunk instance. If confirmed malicious, this could lead to service outages and impact the monitoring and logging capabilities of the organization. action.escu.how_to_implement = This search requires the ability to search internal indexes. action.escu.known_false_positives = This search may produces false positives, analyst most focuse in the use of printf conversion function of eval to craft an expression that splunkd cannot interpret correctly causing it to crash. -action.escu.creation_date = 2023-08-30 -action.escu.modification_date = 2023-08-30 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk DOS via printf search function - Rule action.escu.search_type = detection @@ -2113,7 +2072,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk DOS via printf search function - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2023-40594"], "impact": 100, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499.004"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "78b48d08-075c-4eac-bd07-e364c3780867", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "78b48d08-075c-4eac-bd07-e364c3780867", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2165,14 +2124,14 @@ search = `audittrail` action IN ("change_own_password","password_change","edit_p [ESCU - Splunk Endpoint Denial of Service DoS Zip Bomb - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search allows operator to identify Splunk search app crashes resulting from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before crash. This search will provide Universal Forwarder errors from uploaded binary files (zip compression) which are used for this attack. If an analyst sees results from this search we suggest you investigate and triage what zip file was uploaded, zip compressed files may have different extensions. +description = The following analytic identifies crashes in the Splunk search app caused by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and 8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder error logs for specific messages indicating invalid or binary file issues. This activity is significant because it can disrupt Splunk operations, leading to potential data loss or monitoring gaps. If confirmed malicious, this attack could result in a denial of service, hindering the organization's ability to monitor and respond to other security incidents effectively. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search allows operator to identify Splunk search app crashes resulting from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before crash. This search will provide Universal Forwarder errors from uploaded binary files (zip compression) which are used for this attack. If an analyst sees results from this search we suggest you investigate and triage what zip file was uploaded, zip compressed files may have different extensions. +action.escu.eli5 = The following analytic identifies crashes in the Splunk search app caused by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and 8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder error logs for specific messages indicating invalid or binary file issues. This activity is significant because it can disrupt Splunk operations, leading to potential data loss or monitoring gaps. If confirmed malicious, this attack could result in a denial of service, hindering the organization's ability to monitor and respond to other security incidents effectively. action.escu.how_to_implement = Need to monitor Splunkd data from Universal Forwarders. action.escu.known_false_positives = This search may reveal non malicious zip files causing errors as well. -action.escu.creation_date = 2022-08-02 -action.escu.modification_date = 2022-08-02 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Endpoint Denial of Service DoS Zip Bomb - Rule action.escu.search_type = detection @@ -2190,11 +2149,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Endpoint Denial of Service DoS Zip Bomb - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 75, "cve": ["CVE-2022-37439"], "impact": 100, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b237d393-2f57-4531-aad7-ad3c17c8b041", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b237d393-2f57-4531-aad7-ad3c17c8b041", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search allows operator to identify Splunk search app crashes resulting from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before crash. This search will provide Universal Forwarder errors from uploaded binary files (zip compression) which are used for this attack. If an analyst sees results from this search we suggest you investigate and triage what zip file was uploaded, zip compressed files may have different extensions. +action.notable.param.rule_description = The following analytic identifies crashes in the Splunk search app caused by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and 8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder error logs for specific messages indicating invalid or binary file issues. This activity is significant because it can disrupt Splunk operations, leading to potential data loss or monitoring gaps. If confirmed malicious, this attack could result in a denial of service, hindering the organization's ability to monitor and respond to other security incidents effectively. action.notable.param.rule_title = Splunk Endpoint Denial of Service DoS Zip Bomb action.notable.param.security_domain = threat action.notable.param.severity = high @@ -2212,14 +2171,14 @@ search = `splunkd` component=FileClassifierManager event_message=*invalid* event [ESCU - Splunk Enterprise KV Store Incorrect Authorization - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections. +description = The following analytic detects unauthorized attempts to reload Splunk KV Store collections via the REST API. It leverages internal index logs to identify POST requests to the `/servicesNS/nobody/search/admin/collections-conf/_reload` endpoint, focusing on status codes starting with '2'. This activity is significant as it may indicate improper permission handling, potentially leading to unauthorized deletion of KV Store collections. If confirmed malicious, this could result in data loss or unauthorized data manipulation, impacting the integrity and availability of critical Splunk data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections. +action.escu.eli5 = The following analytic detects unauthorized attempts to reload Splunk KV Store collections via the REST API. It leverages internal index logs to identify POST requests to the `/servicesNS/nobody/search/admin/collections-conf/_reload` endpoint, focusing on status codes starting with '2'. This activity is significant as it may indicate improper permission handling, potentially leading to unauthorized deletion of KV Store collections. If confirmed malicious, this could result in data loss or unauthorized data manipulation, impacting the integrity and availability of critical Splunk data. action.escu.how_to_implement = Requires access to internal indexes and REST API enabled instances. action.escu.known_false_positives = This is a hunting search and will produce false positives. Operator must follow results into instances where curl requests coming from actual users may indicate intent of exploitation. -action.escu.creation_date = 2024-01-18 -action.escu.modification_date = 2024-01-18 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Enterprise KV Store Incorrect Authorization - Rule action.escu.search_type = detection @@ -2232,7 +2191,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Enterprise KV Store Incorrect Authorization - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2024-23675"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8f0e8380-a835-4f2b-b749-9ce119364df0", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8f0e8380-a835-4f2b-b749-9ce119364df0", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2295,14 +2254,14 @@ search = `splunk_python` request_path="/en-US/app/search/C:\\Program" *strings* [ESCU - Splunk ES DoS Investigations Manager via Investigation Creation - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted. +description = The following analytic detects the creation of malformed Investigations in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` with error statuses during investigation creation. This activity is significant as it can disrupt the functionality of the Investigations manager, hindering incident response efforts. If confirmed malicious, this could prevent security teams from accessing critical investigation data, severely impacting their ability to manage and respond to security incidents effectively. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted. +action.escu.eli5 = The following analytic detects the creation of malformed Investigations in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` with error statuses during investigation creation. This activity is significant as it can disrupt the functionality of the Investigations manager, hindering incident response efforts. If confirmed malicious, this could prevent security teams from accessing critical investigation data, severely impacting their ability to manage and respond to security incidents effectively. action.escu.how_to_implement = This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2. action.escu.known_false_positives = The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event. -action.escu.creation_date = 2024-01-04 -action.escu.modification_date = 2024-01-04 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk ES DoS Investigations Manager via Investigation Creation - Rule action.escu.search_type = detection @@ -2320,11 +2279,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk ES DoS Investigations Manager via Investigation Creation - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2024-22165"], "impact": 100, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7f6a07bd-82ef-46b8-8eba-802278abd00e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7f6a07bd-82ef-46b8-8eba-802278abd00e", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted. +action.notable.param.rule_description = The following analytic detects the creation of malformed Investigations in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` with error statuses during investigation creation. This activity is significant as it can disrupt the functionality of the Investigations manager, hindering incident response efforts. If confirmed malicious, this could prevent security teams from accessing critical investigation data, severely impacting their ability to manage and respond to security incidents effectively. action.notable.param.rule_title = Splunk ES DoS Investigations Manager via Investigation Creation action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -2342,14 +2301,14 @@ search = `splunkd_investigation_rest_handler` method=put msg=*investigation* sta [ESCU - Splunk ES DoS Through Investigation Attachments - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible. +description = The following analytic detects attempts to perform a denial of service (DoS) attack through investigation attachments in Splunk Enterprise Security (ES) versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` for error statuses related to investigation objects. This activity is significant because it can render the Investigation feature inaccessible, disrupting incident response and forensic analysis. If confirmed malicious, this attack could prevent security teams from effectively managing and investigating security incidents, leading to prolonged exposure and potential data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible. +action.escu.eli5 = The following analytic detects attempts to perform a denial of service (DoS) attack through investigation attachments in Splunk Enterprise Security (ES) versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` for error statuses related to investigation objects. This activity is significant because it can render the Investigation feature inaccessible, disrupting incident response and forensic analysis. If confirmed malicious, this attack could prevent security teams from effectively managing and investigating security incidents, leading to prolonged exposure and potential data breaches. action.escu.how_to_implement = This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2. action.escu.known_false_positives = This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager. -action.escu.creation_date = 2024-01-04 -action.escu.modification_date = 2024-01-04 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk ES DoS Through Investigation Attachments - Rule action.escu.search_type = detection @@ -2367,11 +2326,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk ES DoS Through Investigation Attachments - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2024-22164"], "impact": 100, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb85b25e-2d6b-4e39-bd27-50db42edcb8f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb85b25e-2d6b-4e39-bd27-50db42edcb8f", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible. +action.notable.param.rule_description = The following analytic detects attempts to perform a denial of service (DoS) attack through investigation attachments in Splunk Enterprise Security (ES) versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring the `splunkd_investigation_rest_handler` for error statuses related to investigation objects. This activity is significant because it can render the Investigation feature inaccessible, disrupting incident response and forensic analysis. If confirmed malicious, this attack could prevent security teams from effectively managing and investigating security incidents, leading to prolonged exposure and potential data breaches. action.notable.param.rule_title = Splunk ES DoS Through Investigation Attachments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -2389,14 +2348,14 @@ search = `splunkd_investigation_rest_handler` status=error object=investigation [ESCU - Splunk HTTP Response Splitting Via Rest SPL Command - Rule] action.escu = 0 action.escu.enabled = 1 -description = A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will. +description = The following analytic identifies attempts to exploit an HTTP response splitting vulnerability via the rest SPL command in Splunk. It detects this activity by analyzing audit logs for specific search commands that include REST methods like POST, PUT, PATCH, or DELETE. This behavior is significant because it indicates a potential attempt to access restricted REST endpoints, which could lead to unauthorized access to sensitive information. If confirmed malicious, this activity could allow an attacker to access restricted content, such as password files, by injecting commands into HTTP requests. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.006"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will. +action.escu.eli5 = The following analytic identifies attempts to exploit an HTTP response splitting vulnerability via the rest SPL command in Splunk. It detects this activity by analyzing audit logs for specific search commands that include REST methods like POST, PUT, PATCH, or DELETE. This behavior is significant because it indicates a potential attempt to access restricted REST endpoints, which could lead to unauthorized access to sensitive information. If confirmed malicious, this activity could allow an attacker to access restricted content, such as password files, by injecting commands into HTTP requests. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This search may assist in detecting possible http response splitting exploitation attemptss. action.escu.known_false_positives = This search may have produce false positives as malformed or erroneous requests made to this endpoint may be executed willingly or erroneously by operators. -action.escu.creation_date = 2023-05-23 -action.escu.modification_date = 2023-05-23 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk HTTP Response Splitting Via Rest SPL Command - Rule action.escu.search_type = detection @@ -2409,7 +2368,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk HTTP Response Splitting Via Rest SPL Command - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.006"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e615a0e1-a1b2-4196-9865-8aa646e1708c", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e615a0e1-a1b2-4196-9865-8aa646e1708c", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2508,14 +2467,14 @@ search = | rest /services/apps/local | search disabled=0 core=0 label="Splunk Ad [ESCU - Splunk list all nonstandard admin accounts - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search will enumerate all Splunk Accounts with administrative rights on this instance. It deliberately ignores the default admin account since this is assumed to be present. This search may help in a detection the Cross-Site Scripting Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies nonstandard Splunk accounts with administrative rights on the instance, excluding the default admin account. It uses REST API calls to retrieve user data and filters for accounts with admin capabilities. This activity is significant as unauthorized admin accounts can indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could leverage these accounts to execute commands, escalate privileges, or persist within the environment, posing a significant risk to the integrity and security of the Splunk instance. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search will enumerate all Splunk Accounts with administrative rights on this instance. It deliberately ignores the default admin account since this is assumed to be present. This search may help in a detection the Cross-Site Scripting Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. +action.escu.eli5 = The following analytic identifies nonstandard Splunk accounts with administrative rights on the instance, excluding the default admin account. It uses REST API calls to retrieve user data and filters for accounts with admin capabilities. This activity is significant as unauthorized admin accounts can indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could leverage these accounts to execute commands, escalate privileges, or persist within the environment, posing a significant risk to the integrity and security of the Splunk instance. action.escu.how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures. If there have been admin account, in addition to the standard admin account, intentionally created on this server, then edit the filter macro to exclude them. action.escu.known_false_positives = It is not possible to discern from the user table whether or not users with admin rights have been created intentionally, accidentally, or as a result of exploitation. Each user with these rights should be investigated and, if legitimate, added to the filter macro above. If a user is not believed to be legitimate, then further investigation should take place. -action.escu.creation_date = 2023-02-07 -action.escu.modification_date = 2023-02-07 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk list all nonstandard admin accounts - Rule action.escu.search_type = detection @@ -2528,7 +2487,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Splunk list all nonstandard admin accounts - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-22933"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "401d689c-8596-4c6b-a710-7b6fdca296d3", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "401d689c-8596-4c6b-a710-7b6fdca296d3", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2544,14 +2503,14 @@ search = | rest splunk_server=local /services/authentication/users |search capab [ESCU - Splunk Low Privilege User Can View Hashed Splunk Password - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance. +description = The following analytic identifies low-privilege users attempting to view hashed Splunk passwords by querying the conf-user-seed REST endpoint. It leverages data from the `splunkd_web` logs, specifically monitoring access to the conf-user-seed endpoint. This activity is significant because it can indicate an attempt to escalate privileges by obtaining hashed credentials, potentially leading to admin account takeover. If confirmed malicious, this could allow an attacker to gain administrative control over the Splunk instance, compromising the entire environment's security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance. +action.escu.eli5 = The following analytic identifies low-privilege users attempting to view hashed Splunk passwords by querying the conf-user-seed REST endpoint. It leverages data from the `splunkd_web` logs, specifically monitoring access to the conf-user-seed endpoint. This activity is significant because it can indicate an attempt to escalate privileges by obtaining hashed credentials, potentially leading to admin account takeover. If confirmed malicious, this could allow an attacker to gain administrative control over the Splunk instance, compromising the entire environment's security. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover attempts to access con-user-seed file content. action.escu.known_false_positives = This search may produce false positives as accounts with high privileges may access this file. Operator will need to investigate these actions in order to discern exploitation attempts. -action.escu.creation_date = 2023-05-09 -action.escu.modification_date = 2023-05-09 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Low Privilege User Can View Hashed Splunk Password - Rule action.escu.search_type = detection @@ -2564,7 +2523,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Low Privilege User Can View Hashed Splunk Password - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a1be424d-e59c-4583-b6f9-2dcc23be4875", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a1be424d-e59c-4583-b6f9-2dcc23be4875", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2580,14 +2539,14 @@ search = `splunkd_web` uri="*/servicesNS/nobody/system/configs/conf-user-seed*" [ESCU - Splunk Path Traversal In Splunk App For Lookup File Edit - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance. +description = The following analytic identifies path traversal attempts in the Splunk App for Lookup File Editing. It detects specially crafted web requests targeting lookup files by analyzing the `uri_query` field in the `_internal` index. This activity is significant because it allows low-privilege users to read and write to restricted areas of the Splunk installation directory, potentially accessing sensitive files like password hashes. If confirmed malicious, this could lead to unauthorized access, data breaches, and further exploitation of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance. +action.escu.eli5 = The following analytic identifies path traversal attempts in the Splunk App for Lookup File Editing. It detects specially crafted web requests targeting lookup files by analyzing the `uri_query` field in the `_internal` index. This activity is significant because it allows low-privilege users to read and write to restricted areas of the Splunk installation directory, potentially accessing sensitive files like password hashes. If confirmed malicious, this could lead to unauthorized access, data breaches, and further exploitation of the Splunk environment. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests. action.escu.known_false_positives = This search may find additional path traversal exploitation attempts or malformed requests. -action.escu.creation_date = 2023-05-11 -action.escu.modification_date = 2023-05-11 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Path Traversal In Splunk App For Lookup File Edit - Rule action.escu.search_type = detection @@ -2600,7 +2559,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Path Traversal In Splunk App For Lookup File Edit - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ed58987-738d-4917-9e44-b8ef6ab948a6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ed58987-738d-4917-9e44-b8ef6ab948a6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2616,14 +2575,14 @@ search = `splunkda` uri_query=*lookup_file* | table clientip uri_query lookup_fi [ESCU - Splunk Persistent XSS Via URL Validation Bypass W Dashboard - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user. The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone. +description = The following analytic detects attempts to bypass URL validation in Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13 by targeting the vulnerable bootstrap version 2.3.1. It leverages `splunkd_web` logs, specifically monitoring GET requests to JavaScript files within the vulnerable bootstrap path. This activity is significant as it can allow a low-privileged user to perform path traversal, potentially accessing restricted and confidential information. If confirmed malicious, this could lead to unauthorized data access and compromise of sensitive information, including targeting admin users. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user. The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone. +action.escu.eli5 = The following analytic detects attempts to bypass URL validation in Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13 by targeting the vulnerable bootstrap version 2.3.1. It leverages `splunkd_web` logs, specifically monitoring GET requests to JavaScript files within the vulnerable bootstrap path. This activity is significant as it can allow a low-privileged user to perform path traversal, potentially accessing restricted and confidential information. If confirmed malicious, this could lead to unauthorized data access and compromise of sensitive information, including targeting admin users. action.escu.how_to_implement = This search does not require additional data to be ingested. This search requires ability to search _internal index. This search helps discover access to vulnerable bootstrap versions. action.escu.known_false_positives = This search will produce numerous false positives as it shows ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files occur during normal Splunk usage. To reduce or eliminate false positives, update the a version of Splunk which has addressed the vulnerability. -action.escu.creation_date = 2023-05-09 -action.escu.modification_date = 2023-05-09 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Persistent XSS Via URL Validation Bypass W Dashboard - Rule action.escu.search_type = detection @@ -2636,7 +2595,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Persistent XSS Via URL Validation Bypass W Dashboard - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 20, "cve": ["CVE-2019-8331"], "impact": 80, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a43558f-a53c-4ee4-86c1-30b1e8ef3606", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a43558f-a53c-4ee4-86c1-30b1e8ef3606", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2652,14 +2611,14 @@ search = `splunkd_web` method=GET uri_path="*bootstrap-2.3.1*" file="*.js" | tab [ESCU - Splunk Process Injection Forwarder Bundle Downloads - Rule] action.escu = 0 action.escu.enabled = 1 -description = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. This hunting search pulls a full list of forwarder bundle downloads where the peer column is the forwarder, the host column is the Deployment Server, and then you have a list of the apps downloaded and the serverclasses in which the peer is a member of. You should look for apps or clients that you do not recognize as being part of your environment. +description = The following analytic identifies unauthorized forwarder bundle downloads from Splunk Deployment Servers. It leverages native Splunk logs, specifically the `splunkd` component "PackageDownloadRestHandler," to detect instances where an unauthenticated client may have downloaded forwarder bundles. This activity is significant because it could indicate a potential security breach, allowing unauthorized access to sensitive configurations and applications. If confirmed malicious, an attacker could gain insights into the deployment server's environment, potentially leading to further exploitation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. This hunting search pulls a full list of forwarder bundle downloads where the peer column is the forwarder, the host column is the Deployment Server, and then you have a list of the apps downloaded and the serverclasses in which the peer is a member of. You should look for apps or clients that you do not recognize as being part of your environment. +action.escu.eli5 = The following analytic identifies unauthorized forwarder bundle downloads from Splunk Deployment Servers. It leverages native Splunk logs, specifically the `splunkd` component "PackageDownloadRestHandler," to detect instances where an unauthenticated client may have downloaded forwarder bundles. This activity is significant because it could indicate a potential security breach, allowing unauthorized access to sensitive configurations and applications. If confirmed malicious, an attacker could gain insights into the deployment server's environment, potentially leading to further exploitation or lateral movement within the network. action.escu.how_to_implement = This hunting search uses native logs produced when a deployment server is within your environment. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. action.escu.known_false_positives = None at this time. -action.escu.creation_date = 2022-05-26 -action.escu.modification_date = 2022-05-26 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Process Injection Forwarder Bundle Downloads - Rule action.escu.search_type = detection @@ -2672,7 +2631,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Process Injection Forwarder Bundle Downloads - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 70, "cve": ["CVE-2022-32157"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ea57d78-1aac-45d2-a913-0cd603fb6e9e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ea57d78-1aac-45d2-a913-0cd603fb6e9e", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2688,14 +2647,14 @@ search = `splunkd` component="PackageDownloadRestHandler" | stats values(app) va [ESCU - Splunk Protocol Impersonation Weak Encryption Configuration - Rule] action.escu = 0 action.escu.enabled = 1 -description = On June 14th, 2022, Splunk released a security advisory relating to TLS validation occuring within the httplib and urllib python libraries shipped with Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration settings need to be set. This search will check those configurations on the search head it is run from as well as its search peers. In addition to these settings, the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be enabled as well. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +description = The following analytic identifies weak encryption configurations in Splunk related to TLS validation within the httplib and urllib Python libraries. It uses REST API calls to check specific configuration settings on the search head and its peers, ensuring compliance with security advisories. This activity is significant for a SOC as weak encryption can be exploited for protocol impersonation attacks, leading to unauthorized access. If confirmed malicious, attackers could intercept and manipulate data, compromising the integrity and confidentiality of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1001.003"], "nist": ["DE.AE"]} action.escu.data_models = ["Web"] -action.escu.eli5 = On June 14th, 2022, Splunk released a security advisory relating to TLS validation occuring within the httplib and urllib python libraries shipped with Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration settings need to be set. This search will check those configurations on the search head it is run from as well as its search peers. In addition to these settings, the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be enabled as well. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked. +action.escu.eli5 = The following analytic identifies weak encryption configurations in Splunk related to TLS validation within the httplib and urllib Python libraries. It uses REST API calls to check specific configuration settings on the search head and its peers, ensuring compliance with security advisories. This activity is significant for a SOC as weak encryption can be exploited for protocol impersonation attacks, leading to unauthorized access. If confirmed malicious, attackers could intercept and manipulate data, compromising the integrity and confidentiality of the Splunk environment. action.escu.how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (The `dispatch_rest_to_indexers` capability). Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks. action.escu.known_false_positives = While all of the settings on each device returned by this search may appear to be hardened, you will still need to verify the value of PYTHONHTTPSVERIFY in $SPLUNK_HOME/etc/splunk-launch.conf on each device in order to harden the python configuration. -action.escu.creation_date = 2022-05-25 -action.escu.modification_date = 2022-05-25 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Protocol Impersonation Weak Encryption Configuration - Rule action.escu.search_type = detection @@ -2708,7 +2667,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Protocol Impersonation Weak Encryption Configuration - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2022-32151"], "impact": 50, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1001.003"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "900892bf-70a9-4787-8c99-546dd98ce461", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "900892bf-70a9-4787-8c99-546dd98ce461", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2832,14 +2791,14 @@ search = `splunkda` method="POST" uri="*/services/indexing/preview*" | table hos [ESCU - Splunk RCE via Serialized Session Payload - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use of the 'collect' SPL command which writes a file within the Splunk Enterprise installation. The attacker can then use this file to submit a serialized payload that can result in execution of code within the payload. Please refer to the following URL for additional information on these disclosures - https://advisory.splunk.com +description = The following analytic detects the execution of a specially crafted query using the 'collect' SPL command in Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1. It leverages audit logs to identify searches containing both 'makeresults' and 'collect' commands. This activity is significant because it can indicate an attempt to serialize untrusted data, potentially leading to arbitrary code execution. If confirmed malicious, this could allow an attacker to execute code within the Splunk environment, leading to unauthorized access and control over the system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use of the 'collect' SPL command which writes a file within the Splunk Enterprise installation. The attacker can then use this file to submit a serialized payload that can result in execution of code within the payload. Please refer to the following URL for additional information on these disclosures - https://advisory.splunk.com +action.escu.eli5 = The following analytic detects the execution of a specially crafted query using the 'collect' SPL command in Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1. It leverages audit logs to identify searches containing both 'makeresults' and 'collect' commands. This activity is significant because it can indicate an attempt to serialize untrusted data, potentially leading to arbitrary code execution. If confirmed malicious, this could allow an attacker to execute code within the Splunk environment, leading to unauthorized access and control over the system. action.escu.how_to_implement = Requires access to the _audit index. action.escu.known_false_positives = There are numerous many uses of the 'makeresults' and 'collect' SPL commands. Please evaluate the results of this search for potential abuse. -action.escu.creation_date = 2023-10-02 -action.escu.modification_date = 2023-10-02 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk RCE via Serialized Session Payload - Rule action.escu.search_type = detection @@ -2852,7 +2811,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk RCE via Serialized Session Payload - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-40595"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d1d8fda6-874a-400f-82cf-dcbb59d8e4db", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d1d8fda6-874a-400f-82cf-dcbb59d8e4db", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2868,14 +2827,14 @@ search = `audit_searches` file=* (search="*makeresults*" AND search="*collect*") [ESCU - Splunk RCE via Splunk Secure Gateway Splunk Mobile alerts feature - Rule] action.escu = 0 action.escu.enabled = 1 -description = This hunting search provides information on possible exploitation attempts against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0, 8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands remotely through the use of specially crafted requests to the mobile alerts feature in the Splunk Secure Gateway app. +description = The following analytic identifies potential exploitation attempts against the Splunk Secure Gateway App's Mobile Alerts feature in Splunk versions 9.0, 8.2.x, and 8.1.x. It detects suspicious activity by monitoring requests to the mobile alerts endpoint using specific URI paths and query parameters. This activity is significant because an authenticated user could exploit this vulnerability to execute arbitrary operating system commands remotely. If confirmed malicious, this could lead to unauthorized code execution, compromising the integrity and security of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This hunting search provides information on possible exploitation attempts against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0, 8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands remotely through the use of specially crafted requests to the mobile alerts feature in the Splunk Secure Gateway app. +action.escu.eli5 = The following analytic identifies potential exploitation attempts against the Splunk Secure Gateway App's Mobile Alerts feature in Splunk versions 9.0, 8.2.x, and 8.1.x. It detects suspicious activity by monitoring requests to the mobile alerts endpoint using specific URI paths and query parameters. This activity is significant because an authenticated user could exploit this vulnerability to execute arbitrary operating system commands remotely. If confirmed malicious, this could lead to unauthorized code execution, compromising the integrity and security of the Splunk environment. action.escu.how_to_implement = This search only applies if Splunk Mobile Gateway is deployed in the vulnerable Splunk versions. action.escu.known_false_positives = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. Focus of this search is "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" which is the injection point. -action.escu.creation_date = 2022-10-11 -action.escu.modification_date = 2022-10-11 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk RCE via Splunk Secure Gateway Splunk Mobile alerts feature - Rule action.escu.search_type = detection @@ -2888,7 +2847,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk RCE via Splunk Secure Gateway Splunk Mobile alerts feature - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 90, "cve": ["CVE-2022-43567"], "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "baa41f09-df48-4375-8991-520beea161be", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "baa41f09-df48-4375-8991-520beea161be", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -2935,7 +2894,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `splunkd_ui` ((uri="*NO_BINARY_CHECK=1*" AND "*input.path=*.xsl*") OR uri="*dispatch*.xsl*") AND uri!= "*splunkd_ui*" | rex field=uri "(?=\s*([\S\s]+))" | eval decoded_field=urldecode(string) | eval action=case(match(status,"200"),"Allowed",match(status,"303|500|401|403|404|301|406"),"Blocked",1=1,"Unknown") | stats count min(_time) as firstTime max(_time) as lastTime by clientip useragent uri decoded_field action host | rename clientip as src, uri as dest_uri | iplocation src | fillnull value="N/A" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | table firstTime, lastTime src, useragent, action, count, Country, Region, City, dest_uri, decoded_field +search = `splunkd_ui` ((uri="*NO_BINARY_CHECK=1*" AND "*input.path=*.xsl*") OR uri="*dispatch*.xsl*") AND uri!= "*splunkd_ui*" | rex field=uri "(?=\s*([\S\s]+))" | eval decoded_field=urldecode(string) | eval action=case(match(status,"200"),"Allowed",match(status,"303|500|401|403|404|301|406"),"Blocked",1=1,"Unknown") | stats count min(_time) as firstTime max(_time) as lastTime by clientip useragent uri decoded_field action host | rename clientip as src, uri as dest_uri | iplocation src | fillnull value="N/A" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | table firstTime, lastTime src, useragent, action, count, Country, Region, City, dest_uri, decoded_field | `splunk_rce_via_user_xslt_filter` [ESCU - Splunk Reflected XSS in the templates lists radio - Rule] action.escu = 0 @@ -2976,14 +2935,14 @@ search = `splunkd_webx` user=admin status=200 uri=*/lists/entities/x/ui/views* u [ESCU - Splunk Reflected XSS on App Search Table Endpoint - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function. +description = The following analytic identifies attempts to exploit a reflected cross-site scripting (XSS) vulnerability on the app search table endpoint in Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12. It detects this activity by analyzing web request logs for specific dataset commands (`makeresults`, `count`, `eval`, `baseSPL`) within the `splunkd_web` index. This activity is significant because successful exploitation can lead to the execution of arbitrary commands on the Splunk platform, potentially compromising the entire instance. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, and manipulate data within the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function. +action.escu.eli5 = The following analytic identifies attempts to exploit a reflected cross-site scripting (XSS) vulnerability on the app search table endpoint in Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12. It detects this activity by analyzing web request logs for specific dataset commands (`makeresults`, `count`, `eval`, `baseSPL`) within the `splunkd_web` index. This activity is significant because successful exploitation can lead to the execution of arbitrary commands on the Splunk platform, potentially compromising the entire instance. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, and manipulate data within the Splunk environment. action.escu.how_to_implement = Need access to the internal indexes. action.escu.known_false_positives = This search will produce false positives. It is necessary to also look at uri_query parameter to determine the possible malicious intention of inserting makeresults within the uri string. -action.escu.creation_date = 2023-09-05 -action.escu.modification_date = 2023-09-05 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Reflected XSS on App Search Table Endpoint - Rule action.escu.search_type = detection @@ -2996,7 +2955,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Reflected XSS on App Search Table Endpoint - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 40, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "182f9080-4137-4629-94ac-cb1083ac981a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "182f9080-4137-4629-94ac-cb1083ac981a", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3048,14 +3007,14 @@ search = | tstats fillnull_value="N/A" count min(_time) as firstTime max(_time) [ESCU - Splunk Stored XSS via Data Model objectName field - Rule] action.escu = 0 action.escu.enabled = 1 -description = Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent cross site scripting via Data Model object name. An authenticated user can inject and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) in the object name Data Model. +description = The following analytic identifies attempts to exploit a stored cross-site scripting (XSS) vulnerability in Splunk Enterprise via the Data Model object name field. It detects this activity by analyzing web access logs (`splunkd_webx`) for specific URI patterns and non-null query parameters. This activity is significant because it allows authenticated users to inject and store malicious scripts, leading to persistent XSS attacks. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of other users, potentially leading to data theft, session hijacking, or further compromise of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent cross site scripting via Data Model object name. An authenticated user can inject and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) in the object name Data Model. +action.escu.eli5 = The following analytic identifies attempts to exploit a stored cross-site scripting (XSS) vulnerability in Splunk Enterprise via the Data Model object name field. It detects this activity by analyzing web access logs (`splunkd_webx`) for specific URI patterns and non-null query parameters. This activity is significant because it allows authenticated users to inject and store malicious scripts, leading to persistent XSS attacks. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of other users, potentially leading to data theft, session hijacking, or further compromise of the Splunk environment. action.escu.how_to_implement = This vulnerability only affects Splunk Web enabled instances. This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. action.escu.known_false_positives = This search may produce false positives and does not cover exploitation attempts via code obfuscation, focus of search is suspicious requests against "/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model" which is the injection point. -action.escu.creation_date = 2022-10-11 -action.escu.modification_date = 2022-10-11 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Stored XSS via Data Model objectName field - Rule action.escu.search_type = detection @@ -3068,7 +3027,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Stored XSS via Data Model objectName field - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2022-43569"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "062bff76-5f9c-496e-a386-cb1adcf69871", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "062bff76-5f9c-496e-a386-cb1adcf69871", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3084,14 +3043,14 @@ search = `splunkd_webx` uri=/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel [ESCU - Splunk Unauthenticated Log Injection Web Service Log - Rule] action.escu = 0 action.escu.enabled = 1 -description = An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server. +description = The following analytic identifies potential log injection attempts into the Splunk server via specially crafted web URLs. It detects ANSI escape codes within the `uri_path` field of `splunkd_webx` logs. This activity is significant as it can lead to log file manipulation, potentially obfuscating malicious actions or misleading analysts. If confirmed malicious, an attacker could manipulate log files to hide their tracks or execute further attacks, compromising the integrity of the logging system and making incident response more challenging. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server. +action.escu.eli5 = The following analytic identifies potential log injection attempts into the Splunk server via specially crafted web URLs. It detects ANSI escape codes within the `uri_path` field of `splunkd_webx` logs. This activity is significant as it can lead to log file manipulation, potentially obfuscating malicious actions or misleading analysts. If confirmed malicious, an attacker could manipulate log files to hide their tracks or execute further attacks, compromising the integrity of the logging system and making incident response more challenging. action.escu.how_to_implement = This only affects web enabled Splunk instances. The detection does require the ability to search the _internal index. action.escu.known_false_positives = This hunting search will produce false positives if ANSI escape characters are included in URLs either voluntarily or by accident. This search will not detect obfuscated ANSI characters. -action.escu.creation_date = 2023-07-13 -action.escu.modification_date = 2023-07-13 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk Unauthenticated Log Injection Web Service Log - Rule action.escu.search_type = detection @@ -3104,7 +3063,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk Unauthenticated Log Injection Web Service Log - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 30, "cve": ["CVE-2023-32712"], "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de3908dc-1298-446d-84b9-fa81d37e959b", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de3908dc-1298-446d-84b9-fa81d37e959b", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3120,14 +3079,14 @@ search = `splunkd_webx` uri_path IN ("*\x1B*", "*\u001b*", "*\033*", "*\0x9*", [ESCU - Splunk unnecessary file extensions allowed by lookup table uploads - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads. +description = The following analytic identifies user activity related to uploading lookup tables with unnecessary filename extensions in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods (POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This behavior is significant because it can indicate attempts to upload potentially malicious files disguised as lookup tables. If confirmed malicious, this activity could allow an attacker to execute unauthorized code or manipulate data within the Splunk environment, leading to potential data breaches or system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads. +action.escu.eli5 = The following analytic identifies user activity related to uploading lookup tables with unnecessary filename extensions in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods (POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This behavior is significant because it can indicate attempts to upload potentially malicious files disguised as lookup tables. If confirmed malicious, this activity could allow an attacker to execute unauthorized code or manipulate data within the Splunk environment, leading to potential data breaches or system compromise. action.escu.how_to_implement = Requires access to internal splunkd_access. action.escu.known_false_positives = This is a hunting search, the search provides information on upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary after executing search. This search will produce false positives as payload cannot be directly discerned. -action.escu.creation_date = 2023-02-14 -action.escu.modification_date = 2023-02-14 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk unnecessary file extensions allowed by lookup table uploads - Rule action.escu.search_type = detection @@ -3145,11 +3104,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk unnecessary file extensions allowed by lookup table uploads - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-22937"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b7d1293f-e78f-415e-b5f6-443df3480082", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b7d1293f-e78f-415e-b5f6-443df3480082", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads. +action.notable.param.rule_description = The following analytic identifies user activity related to uploading lookup tables with unnecessary filename extensions in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods (POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This behavior is significant because it can indicate attempts to upload potentially malicious files disguised as lookup tables. If confirmed malicious, this activity could allow an attacker to execute unauthorized code or manipulate data within the Splunk environment, leading to potential data breaches or system compromise. action.notable.param.rule_title = Splunk unnecessary file extensions allowed by lookup table uploads action.notable.param.security_domain = threat action.notable.param.severity = high @@ -3167,14 +3126,14 @@ search = `splunkda` method IN ("POST", "DELETE") uri_path=/servicesNS/*/ui/views [ESCU - Splunk User Enumeration Attempt - Rule] action.escu = 0 action.escu.enabled = 1 -description = On May 3rd, 2022, Splunk published a security advisory for username enumeration stemming from verbose login failure messages present on some REST endpoints. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +description = The following analytic identifies attempts to enumerate usernames in Splunk by detecting multiple failed authentication attempts from the same source. It leverages data from the `_audit` index, specifically focusing on failed authentication events. This activity is significant for a SOC because it can indicate an attacker trying to discover valid usernames, which is a precursor to more targeted attacks like password spraying or brute force attempts. If confirmed malicious, this activity could lead to unauthorized access, compromising the security of the Splunk environment and potentially exposing sensitive data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = On May 3rd, 2022, Splunk published a security advisory for username enumeration stemming from verbose login failure messages present on some REST endpoints. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +action.escu.eli5 = The following analytic identifies attempts to enumerate usernames in Splunk by detecting multiple failed authentication attempts from the same source. It leverages data from the `_audit` index, specifically focusing on failed authentication events. This activity is significant for a SOC because it can indicate an attacker trying to discover valid usernames, which is a precursor to more targeted attacks like password spraying or brute force attempts. If confirmed malicious, this activity could lead to unauthorized access, compromising the security of the Splunk environment and potentially exposing sensitive data. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to find password spraying or brute force authorization attempts in addition to someone enumerating usernames. action.escu.known_false_positives = Automation executing authentication attempts against your Splunk infrastructure with outdated credentials may cause false positives. -action.escu.creation_date = 2024-03-19 -action.escu.modification_date = 2024-03-19 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk User Enumeration Attempt - Rule action.escu.search_type = detection @@ -3192,11 +3151,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk User Enumeration Attempt - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "cve": ["CVE-2021-33845"], "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "25625cb4-1c4d-4463-b0f9-7cb462699cde", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "25625cb4-1c4d-4463-b0f9-7cb462699cde", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = On May 3rd, 2022, Splunk published a security advisory for username enumeration stemming from verbose login failure messages present on some REST endpoints. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +action.notable.param.rule_description = The following analytic identifies attempts to enumerate usernames in Splunk by detecting multiple failed authentication attempts from the same source. It leverages data from the `_audit` index, specifically focusing on failed authentication events. This activity is significant for a SOC because it can indicate an attacker trying to discover valid usernames, which is a precursor to more targeted attacks like password spraying or brute force attempts. If confirmed malicious, this activity could lead to unauthorized access, compromising the security of the Splunk environment and potentially exposing sensitive data. action.notable.param.rule_title = Splunk User Enumeration Attempt action.notable.param.security_domain = access action.notable.param.severity = high @@ -3214,14 +3173,14 @@ search = `splunkd_failed_auths` | stats count(user) as auths by user, src | whe [ESCU - Splunk XSS in Highlighted JSON Events - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2. The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment. +description = The following analytic identifies potential exploitation of a Cross-Site Scripting (XSS) vulnerability in Splunk Enterprise 9.1.2. It detects suspicious requests to the Splunk web GUI that may execute JavaScript within script tags. This detection leverages logs from the `splunkd_ui` data source, focusing on specific URI paths and HTTP methods. This activity is significant as it can allow attackers to execute arbitrary JavaScript, potentially accessing the API with the logged-in user's permissions. If the user is an admin, the attacker could create an admin account, leading to full control over the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2. The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment. +action.escu.eli5 = The following analytic identifies potential exploitation of a Cross-Site Scripting (XSS) vulnerability in Splunk Enterprise 9.1.2. It detects suspicious requests to the Splunk web GUI that may execute JavaScript within script tags. This detection leverages logs from the `splunkd_ui` data source, focusing on specific URI paths and HTTP methods. This activity is significant as it can allow attackers to execute arbitrary JavaScript, potentially accessing the API with the logged-in user's permissions. If the user is an admin, the attacker could create an admin account, leading to full control over the Splunk environment. action.escu.how_to_implement = This search only applies to web-GUI-enabled Splunk instances and operator must have access to internal indexes. action.escu.known_false_positives = This is a hunting search and will produce false positives as it is not possible to view contents of a request payload. It shows the artifact resulting from a potential exploitation payload (the creation of a user with admin privileges). -action.escu.creation_date = 2023-11-16 -action.escu.modification_date = 2023-11-16 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk XSS in Highlighted JSON Events - Rule action.escu.search_type = detection @@ -3234,7 +3193,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk XSS in Highlighted JSON Events - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1030bc63-0b37-4ac9-9ae0-9361c955a3cc", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1030bc63-0b37-4ac9-9ae0-9361c955a3cc", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3250,14 +3209,14 @@ search = `splunkd_ui` "/en-US/splunkd/__raw/servicesNS/nobody/search/authenticat [ESCU - Splunk XSS in Monitoring Console - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. On May 3rd, 2022, Splunk published a security advisory for a reflective Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation in the Distributed Monitoring Console app. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies attempts to exploit a reflective Cross-Site Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app. It detects GET requests with suspicious query parameters by analyzing `splunkd_web` logs in the _internal index. This activity is significant because it targets a known vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts in the context of the user's browser. If confirmed malicious, this could lead to unauthorized actions, data theft, or further compromise of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = On May 3rd, 2022, Splunk published a security advisory for a reflective Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation in the Distributed Monitoring Console app. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +action.escu.eli5 = The following analytic identifies attempts to exploit a reflective Cross-Site Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app. It detects GET requests with suspicious query parameters by analyzing `splunkd_web` logs in the _internal index. This activity is significant because it targets a known vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts in the context of the user's browser. If confirmed malicious, this could lead to unauthorized actions, data theft, or further compromise of the Splunk environment. action.escu.how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will find attempted exploitation of CVE-2022-27183. action.escu.known_false_positives = Use of the monitoring console where the less-than sign (<) is the first character in the description field. -action.escu.creation_date = 2022-04-27 -action.escu.modification_date = 2022-04-27 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk XSS in Monitoring Console - Rule action.escu.search_type = detection @@ -3275,11 +3234,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Splunk XSS in Monitoring Console - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "cve": ["CVE-2022-27183"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b11accac-6fa3-4103-8a1a-7210f1a67087", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b11accac-6fa3-4103-8a1a-7210f1a67087", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = On May 3rd, 2022, Splunk published a security advisory for a reflective Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation in the Distributed Monitoring Console app. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk. +action.notable.param.rule_description = The following analytic identifies attempts to exploit a reflective Cross-Site Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app. It detects GET requests with suspicious query parameters by analyzing `splunkd_web` logs in the _internal index. This activity is significant because it targets a known vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts in the context of the user's browser. If confirmed malicious, this could lead to unauthorized actions, data theft, or further compromise of the Splunk environment. action.notable.param.rule_title = Splunk XSS in Monitoring Console action.notable.param.security_domain = threat action.notable.param.severity = high @@ -3297,14 +3256,14 @@ search = `splunkd_web` method="GET" uri_query="description=%3C*" | table _time [ESCU - Splunk XSS in Save table dialog header in search page - Rule] action.escu = 0 action.escu.enabled = 1 -description = This is a hunting search to find persistent cross-site scripting XSS code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise (8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code that can lead to persistent cross site scripting. +description = The following analytic identifies persistent cross-site scripting (XSS) attempts in the 'Save Table' dialog on the Splunk search page. It detects POST requests to the endpoint `/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model` containing potential XSS payloads. This activity is significant because it can allow a remote user with the "power" role to inject malicious scripts, leading to persistent XSS vulnerabilities. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of the affected user, potentially leading to data theft, session hijacking, or further exploitation within the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This is a hunting search to find persistent cross-site scripting XSS code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise (8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code that can lead to persistent cross site scripting. +action.escu.eli5 = The following analytic identifies persistent cross-site scripting (XSS) attempts in the 'Save Table' dialog on the Splunk search page. It detects POST requests to the endpoint `/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model` containing potential XSS payloads. This activity is significant because it can allow a remote user with the "power" role to inject malicious scripts, leading to persistent XSS vulnerabilities. If confirmed malicious, this could enable attackers to execute arbitrary scripts in the context of the affected user, potentially leading to data theft, session hijacking, or further exploitation within the Splunk environment. action.escu.how_to_implement = Watch for POST requests combined with XSS script strings or obfuscation against the injection point /en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model. action.escu.known_false_positives = If host is vulnerable and XSS script strings are inputted they will show up in search. Not all Post requests are malicious as they will show when users create and save dashboards. This search may produce several results with non malicious POST requests. Only affects Splunk Web enabled instances. -action.escu.creation_date = 2022-10-11 -action.escu.modification_date = 2022-10-11 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk XSS in Save table dialog header in search page - Rule action.escu.search_type = detection @@ -3317,7 +3276,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk XSS in Save table dialog header in search page - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2022-43561"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a974d1ee-ddca-4837-b6ad-d55a8a239c20", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a974d1ee-ddca-4837-b6ad-d55a8a239c20", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3333,14 +3292,14 @@ search = `splunkd_webx` method=POST uri=/en-US/splunkd/__raw/servicesNS/nobody/ [ESCU - Splunk XSS via View - Rule] action.escu = 0 action.escu.enabled = 1 -description = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. This hunting search shows users action, application and role used for creating views related to this vulnerability. +description = The following analytic identifies potential Cross-Site Scripting (XSS) attempts via the 'layoutPanel' attribute in the 'module' tag within XML Views in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It leverages internal logs from "splunk_web_service" and "splunk_python" sourcetypes, focusing on messages containing "loadParams." This activity is significant as it can lead to unauthorized script execution within the Splunk Web interface, potentially compromising the security of the instance. If confirmed malicious, attackers could execute arbitrary scripts, leading to data theft, session hijacking, or further exploitation of the Splunk environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. This hunting search shows users action, application and role used for creating views related to this vulnerability. +action.escu.eli5 = The following analytic identifies potential Cross-Site Scripting (XSS) attempts via the 'layoutPanel' attribute in the 'module' tag within XML Views in Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It leverages internal logs from "splunk_web_service" and "splunk_python" sourcetypes, focusing on messages containing "loadParams." This activity is significant as it can lead to unauthorized script execution within the Splunk Web interface, potentially compromising the security of the instance. If confirmed malicious, attackers could execute arbitrary scripts, leading to data theft, session hijacking, or further exploitation of the Splunk environment. action.escu.how_to_implement = This data is collected by default in Splunk. Upon first enabling this rule, a number of errors may be observed. Those that are due to improperly formatted, but non-nefarious, XML views should be be remedied in the corresponding view. Please take care investigating potential XSS as accessing an affected page could retrigger the exploit. action.escu.known_false_positives = The error detected above can be generated for a wide variety of improperly formatted XML views. There will be false positives as the search cannot extract the malicious payload and the view should be manually investigated. -action.escu.creation_date = 2023-02-07 -action.escu.modification_date = 2023-02-07 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Splunk XSS via View - Rule action.escu.search_type = detection @@ -3353,7 +3312,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Splunk XSS via View - Rule action.correlationsearch.annotations = {"analytic_story": ["Splunk Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2023-22933"], "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9ac2bfea-a234-4a18-9d37-6d747e85c2e4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9ac2bfea-a234-4a18-9d37-6d747e85c2e4", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3369,16 +3328,16 @@ search = index = _internal sourcetype IN ("splunk_web_service", "splunk_python") [ESCU - Suspicious Email Attachment Extensions - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects emails containing attachments with suspicious file extensions. It leverages the Email data model in Splunk, using the tstats command to identify emails where the attachment filename is not empty. This detection is significant for SOC analysts as it highlights potential phishing or malware delivery attempts, which are common vectors for data breaches and malware infections. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, system compromise, or data exfiltration. Immediate review and analysis of the identified emails and attachments are crucial to mitigate these risks. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} action.escu.data_models = ["Email"] -action.escu.eli5 = The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack. +action.escu.eli5 = The following analytic detects emails containing attachments with suspicious file extensions. It leverages the Email data model in Splunk, using the tstats command to identify emails where the attachment filename is not empty. This detection is significant for SOC analysts as it highlights potential phishing or malware delivery attempts, which are common vectors for data breaches and malware infections. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, system compromise, or data exfiltration. Immediate review and analysis of the identified emails and attachments are crucial to mitigate these risks. action.escu.how_to_implement = You need to ingest data from emails. Specifically, the sender's address and the file names of any attachments must be mapped to the Email data model. \ **Splunk Phantom Playbook Integration** \ If Splunk Phantom is also configured in your environment, a Playbook called "Suspicious Email Attachment Investigate and Delete" can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, and add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search. The notable event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox.' action.escu.known_false_positives = None identified -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Suspicious Email Attachment Extensions - Rule action.escu.search_type = detection @@ -3396,7 +3355,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Suspicious Email Attachment Extensions - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Destruction", "Emotet Malware DHS Report TA18-201A", "Hermetic Wiper", "Suspicious Emails"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "473bd65f-06ca-4dfe-a2b8-ba04ab4a0084", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "473bd65f-06ca-4dfe-a2b8-ba04ab4a0084", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3407,7 +3366,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Email where All_Email.file_name="*" by All_Email.src_user, All_Email.file_name All_Email.message_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Email")` | `suspicious_email_attachments` | `suspicious_email_attachment_extensions_filter` +search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Email where All_Email.file_name="*" by All_Email.src_user, All_Email.file_name All_Email.message_id | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `drop_dm_object_name("All_Email")` | `suspicious_email_attachments` | `suspicious_email_attachment_extensions_filter` [ESCU - Suspicious Java Classes - Rule] action.escu = 0 @@ -3453,14 +3412,14 @@ search = `stream_http` http_method=POST http_content_length>1 | regex form_data= [ESCU - Web Servers Executing Suspicious Processes - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack. +action.escu.eli5 = The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Some of these processes may be used legitimately on web servers during maintenance or other administrative tasks. -action.escu.creation_date = 2019-04-01 -action.escu.modification_date = 2019-04-01 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Web Servers Executing Suspicious Processes - Rule action.escu.search_type = detection @@ -3478,11 +3437,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Web Servers Executing Suspicious Processes - Rule action.correlationsearch.annotations = {"analytic_story": ["Apache Struts Vulnerability"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ec3b7601-689a-4463-94e0-c9f45638efb9", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ec3b7601-689a-4463-94e0-c9f45638efb9", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack. +action.notable.param.rule_description = The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats. action.notable.param.rule_title = Web Servers Executing Suspicious Processes action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -3541,14 +3500,14 @@ search = | tstats count as api_calls values(All_Changes.command) as command from [ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search finds for the number successfully destroyed cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies an abnormally high number of cloud instances being destroyed within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to detect outliers. This activity is significant for a SOC because a sudden spike in destroyed instances could indicate malicious activity, such as an insider threat or a compromised account attempting to disrupt services. If confirmed malicious, this could lead to significant operational disruptions, data loss, and potential financial impact due to the destruction of critical cloud resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = This search finds for the number successfully destroyed cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +action.escu.eli5 = The following analytic identifies an abnormally high number of cloud instances being destroyed within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to detect outliers. This activity is significant for a SOC because a sudden spike in destroyed instances could indicate malicious activity, such as an insider threat or a compromised account attempting to disrupt services. If confirmed malicious, this could lead to significant operational disruptions, data loss, and potential financial impact due to the destruction of critical cloud resources. action.escu.how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Destroyed` to create the probability density function. action.escu.known_false_positives = Many service accounts configured within a cloud infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user. -action.escu.creation_date = 2020-08-21 -action.escu.modification_date = 2020-08-21 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule action.escu.search_type = detection @@ -3566,7 +3525,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Abnormally High Number Of Cloud Instances Destroyed - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Cloud Instance Activities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ef629fc9-1583-4590-b62a-f2247fbf7bbf", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ef629fc9-1583-4590-b62a-f2247fbf7bbf", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3582,14 +3541,14 @@ search = | tstats count as instances_destroyed values(All_Changes.object_id) as [ESCU - Abnormally High Number Of Cloud Instances Launched - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search finds for the number successfully created cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects an abnormally high number of cloud instances launched within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to identify outliers based on historical data. This activity is significant for a SOC because a sudden spike in instance creation could indicate unauthorized access or misuse of cloud resources. If confirmed malicious, this behavior could lead to resource exhaustion, increased costs, or provide attackers with additional compute resources to further their objectives. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = This search finds for the number successfully created cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers. +action.escu.eli5 = The following analytic detects an abnormally high number of cloud instances launched within a 4-hour period. It leverages cloud infrastructure logs and applies a probability density model to identify outliers based on historical data. This activity is significant for a SOC because a sudden spike in instance creation could indicate unauthorized access or misuse of cloud resources. If confirmed malicious, this behavior could lead to resource exhaustion, increased costs, or provide attackers with additional compute resources to further their objectives. action.escu.how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Launched` to create the probability density function. action.escu.known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user. -action.escu.creation_date = 2020-08-21 -action.escu.modification_date = 2020-08-21 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Abnormally High Number Of Cloud Instances Launched - Rule action.escu.search_type = detection @@ -3607,7 +3566,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Abnormally High Number Of Cloud Instances Launched - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Cryptomining", "Suspicious Cloud Instance Activities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2361e9f-3928-496c-a556-120cd4223a65", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2361e9f-3928-496c-a556-120cd4223a65", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3695,19 +3654,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `aws_cloudwatchlogs_eks` "user.username"="system:anonymous" userAgent!="AWS Security Scanner" | rename sourceIPs{} as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason) values(source) as cluster_name values(responseStatus.code) values(userAgent) as http_user_agent values(verb) values(requestURI) by src_ip user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` |`amazon_eks_kubernetes_cluster_scan_detection_filter` +search = `aws_cloudwatchlogs_eks` "user.username"="system:anonymous" userAgent!="AWS Security Scanner" | rename sourceIPs{} as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason) values(source) as cluster_name values(responseStatus.code) values(userAgent) as http_user_agent values(verb) values(requestURI) by src_ip user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` |`amazon_eks_kubernetes_cluster_scan_detection_filter` [ESCU - Amazon EKS Kubernetes Pod scan detection - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action. Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects unauthenticated requests made against the Kubernetes Pods API, indicating potential unauthorized access attempts. It leverages the `aws_cloudwatchlogs_eks` data source, filtering for events where `user.username` is "system:anonymous", `verb` is "list", and `objectRef.resource` is "pods", with `requestURI` set to "/api/v1/pods". This activity is significant as it may signal attempts to access sensitive resources or execute unauthorized commands within the Kubernetes environment. If confirmed malicious, such access could lead to data compromise, unauthorized command execution, or lateral movement within the cluster. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action. Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts. +action.escu.eli5 = The following analytic detects unauthenticated requests made against the Kubernetes Pods API, indicating potential unauthorized access attempts. It leverages the `aws_cloudwatchlogs_eks` data source, filtering for events where `user.username` is "system:anonymous", `verb` is "list", and `objectRef.resource` is "pods", with `requestURI` set to "/api/v1/pods". This activity is significant as it may signal attempts to access sensitive resources or execute unauthorized commands within the Kubernetes environment. If confirmed malicious, such access could lead to data compromise, unauthorized command execution, or lateral movement within the cluster. action.escu.how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on forAWS (version 4.4.0 or later), then configure your AWS CloudWatch EKS Logs.Please also customize the `kubernetes_pods_aws_scan_fingerprint_detection` macro to filter out the false positives. action.escu.known_false_positives = Not all unauthenticated requests are malicious, but frequency, UA and source IPs and direct request to API provide context. -action.escu.creation_date = 2020-04-15 -action.escu.modification_date = 2020-04-15 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Amazon EKS Kubernetes Pod scan detection - Rule action.escu.search_type = detection @@ -3720,7 +3679,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Amazon EKS Kubernetes Pod scan detection - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Scanning Activity"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dbfca1dd-b8e5-4ba4-be0e-e565e5d62002", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dbfca1dd-b8e5-4ba4-be0e-e565e5d62002", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3731,19 +3690,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `aws_cloudwatchlogs_eks` "user.username"="system:anonymous" verb=list objectRef.resource=pods requestURI="/api/v1/pods" | rename source as cluster_name sourceIPs{} as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason) values(responseStatus.code) values(userAgent) values(verb) values(requestURI) by src_ip cluster_name user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter` +search = `aws_cloudwatchlogs_eks` "user.username"="system:anonymous" verb=list objectRef.resource=pods requestURI="/api/v1/pods" | rename source as cluster_name sourceIPs{} as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason) values(responseStatus.code) values(userAgent) values(verb) values(requestURI) by src_ip cluster_name user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter` [ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +description = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute span. This detection leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` API call, to identify multiple IP addresses associated with the same user session. This behavior is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this activity could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.escu.eli5 = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute span. This detection leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` API call, to identify multiple IP addresses associated with the same user session. This behavior is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this activity could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. -action.escu.creation_date = 2024-02-13 -action.escu.modification_date = 2024-02-13 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule action.escu.search_type = detection @@ -3761,7 +3720,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b3424bbe-3204-4469-887b-ec144483a336", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b3424bbe-3204-4469-887b-ec144483a336", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -3772,19 +3731,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `amazon_security_lake` api.operation=DescribeEventAggregates "http_request.user_agent"!="AWS Internal" "src_endpoint.domain"!="health.amazonaws.com" | eval time = time/pow(10,3) | `security_content_ctime(time)` | bin span=5m time | stats values(src_endpoint.ip) as src_ip dc(src_endpoint.ip) as distinct_ip_count values(cloud.region) as cloud.region by time api.operation actor.user.account_uid actor.user.uid | where distinct_ip_count > 1 | rename cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id, actor.user.uid as user | `aws_concurrent_sessions_from_different_ips_filter` +search = `amazon_security_lake` api.operation=DescribeEventAggregates "http_request.user_agent"!="AWS Internal" "src_endpoint.domain"!="health.amazonaws.com" | eval time = time/pow(10,3) | `security_content_ctime(time)` | bin span=5m time | stats values(src_endpoint.ip) as src_ip dc(src_endpoint.ip) as distinct_ip_count values(cloud.region) as cloud.region by time api.operation actor.user.account_uid actor.user.uid | where distinct_ip_count > 1 | rename cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id, actor.user.uid as user | `asl_aws_concurrent_sessions_from_different_ips_filter` [ESCU - ASL AWS Defense Evasion Delete Cloudtrail - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks, making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts. +description = The following analytic detects AWS `DeleteTrail` events within CloudTrail logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema Framework (OCSF) format to identify when a CloudTrail is deleted. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate with stealth. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and investigate other potential compromises within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks, making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts. +action.escu.eli5 = The following analytic detects AWS `DeleteTrail` events within CloudTrail logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema Framework (OCSF) format to identify when a CloudTrail is deleted. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate with stealth. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and investigate other potential compromises within the AWS environment. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity. -action.escu.creation_date = 2024-02-12 -action.escu.modification_date = 2024-02-12 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS Defense Evasion Delete Cloudtrail - Rule action.escu.search_type = detection @@ -3802,11 +3761,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS Defense Evasion Delete Cloudtrail - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1f0b47e5-0134-43eb-851c-e3258638945e", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1f0b47e5-0134-43eb-851c-e3258638945e", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks, making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts. +action.notable.param.rule_description = The following analytic detects AWS `DeleteTrail` events within CloudTrail logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema Framework (OCSF) format to identify when a CloudTrail is deleted. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate with stealth. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and investigate other potential compromises within the AWS environment. action.notable.param.rule_title = ASL AWS Defense Evasion Delete Cloudtrail action.notable.param.security_domain = threat action.notable.param.severity = high @@ -3824,14 +3783,14 @@ search = `amazon_security_lake` api.operation=DeleteTrail | fillnull | stats cou [ESCU - ASL AWS Defense Evasion Delete CloudWatch Log Group - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs. This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch. By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities, hindering incident response and forensics efforts. +description = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant because attackers may delete log groups to evade detection and disrupt logging capabilities, hindering incident response efforts. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to undetected data breaches or further malicious actions within the compromised AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs. This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch. By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities, hindering incident response and forensics efforts. +action.escu.eli5 = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant because attackers may delete log groups to evade detection and disrupt logging capabilities, hindering incident response efforts. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to undetected data breaches or further malicious actions within the compromised AWS environment. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity. -action.escu.creation_date = 2024-02-12 -action.escu.modification_date = 2024-02-12 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS Defense Evasion Delete CloudWatch Log Group - Rule action.escu.search_type = detection @@ -3849,11 +3808,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS Defense Evasion Delete CloudWatch Log Group - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0f701b38-a0fb-43fd-a83d-d12265f71f33", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0f701b38-a0fb-43fd-a83d-d12265f71f33", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs. This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch. By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities, hindering incident response and forensics efforts. +action.notable.param.rule_description = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant because attackers may delete log groups to evade detection and disrupt logging capabilities, hindering incident response efforts. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to undetected data breaches or further malicious actions within the compromised AWS environment. action.notable.param.rule_title = ASL AWS Defense Evasion Delete CloudWatch Log Group action.notable.param.security_domain = threat action.notable.param.severity = high @@ -3871,14 +3830,14 @@ search = `amazon_security_lake` api.operation=DeleteLogGroup | fillnull | stats [ESCU - ASL AWS Defense Evasion Impair Security Services - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the deletion of critical AWS Security Services configurations through specific API calls to services like CloudWatch, GuardDuty, and Web Application Firewalls. By monitoring for these deletion actions, the analytic aims to identify attempts by adversaries to undermine security defenses, such as erasing logging configurations or removing detection mechanisms. This behavior is crucial for a Security Operations Center (SOC) to identify as it can indicate an attacker's intent to operate undetected by eliminating evidence of their presence and activities. The impact of such attacks is significant, potentially leaving the environment vulnerable to further exploitation without any traceable logs or alerts. +description = The following analytic detects the deletion of critical AWS Security Services configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages Amazon Security Lake logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because adversaries often use these actions to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, leading to potential data breaches, unauthorized access, and prolonged persistence within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = ["Web"] -action.escu.eli5 = The following analytic detects the deletion of critical AWS Security Services configurations through specific API calls to services like CloudWatch, GuardDuty, and Web Application Firewalls. By monitoring for these deletion actions, the analytic aims to identify attempts by adversaries to undermine security defenses, such as erasing logging configurations or removing detection mechanisms. This behavior is crucial for a Security Operations Center (SOC) to identify as it can indicate an attacker's intent to operate undetected by eliminating evidence of their presence and activities. The impact of such attacks is significant, potentially leaving the environment vulnerable to further exploitation without any traceable logs or alerts. +action.escu.eli5 = The following analytic detects the deletion of critical AWS Security Services configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages Amazon Security Lake logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because adversaries often use these actions to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, leading to potential data breaches, unauthorized access, and prolonged persistence within the AWS environment. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. -action.escu.creation_date = 2024-02-12 -action.escu.modification_date = 2024-02-12 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS Defense Evasion Impair Security Services - Rule action.escu.search_type = detection @@ -3891,7 +3850,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS Defense Evasion Impair Security Services - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5029b681-0462-47b7-82e7-f7e3d37f5a2d", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5029b681-0462-47b7-82e7-f7e3d37f5a2d", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -4083,14 +4042,14 @@ search = `amazon_security_lake` api.operation=PutImage NOT `aws_ecr_users_asl` | [ESCU - ASL AWS IAM Delete Policy - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the deletion of an AWS policy, a critical action that could indicate an attempt to alter permissions or reduce security controls. By monitoring AWS logs for `DeletePolicy` events, this analytic identifies both successful and attempted deletions, providing insights into potentially malicious activities. Identifying such behavior is crucial for a Security Operations Center (SOC) as it may signal an adversary's effort to escalate privileges or evade detection. The impact of unauthorized policy deletion is significant, potentially leading to compromised accounts or data exposure. +description = The following analytic identifies when a policy is deleted in AWS. It leverages Amazon Security Lake logs to detect the DeletePolicy API operation. Monitoring policy deletions is crucial as it can indicate unauthorized attempts to weaken security controls. If confirmed malicious, this activity could allow an attacker to remove critical security policies, potentially leading to privilege escalation or unauthorized access to sensitive resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the deletion of an AWS policy, a critical action that could indicate an attempt to alter permissions or reduce security controls. By monitoring AWS logs for `DeletePolicy` events, this analytic identifies both successful and attempted deletions, providing insights into potentially malicious activities. Identifying such behavior is crucial for a Security Operations Center (SOC) as it may signal an adversary's effort to escalate privileges or evade detection. The impact of unauthorized policy deletion is significant, potentially leading to compromised accounts or data exposure. +action.escu.eli5 = The following analytic identifies when a policy is deleted in AWS. It leverages Amazon Security Lake logs to detect the DeletePolicy API operation. Monitoring policy deletions is crucial as it can indicate unauthorized attempts to weaken security controls. If confirmed malicious, this activity could allow an attacker to remove critical security policies, potentially leading to privilege escalation or unauthorized access to sensitive resources. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only. -action.escu.creation_date = 2024-02-13 -action.escu.modification_date = 2024-02-13 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS IAM Delete Policy - Rule action.escu.search_type = detection @@ -4103,7 +4062,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS IAM Delete Policy - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 20, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "609ced68-d420-4ff7-8164-ae98b4b4018c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "609ced68-d420-4ff7-8164-ae98b4b4018c", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -4196,14 +4155,14 @@ search = `amazon_security_lake` api.operation=DeleteGroup status=Success | filln [ESCU - ASL AWS Multi-Factor Authentication Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with less risk of detection, facilitating further malicious activities. +description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. This activity is significant as disabling MFA can indicate an adversary attempting to weaken account security to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, potentially leading to unauthorized access to sensitive resources and prolonged compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with less risk of detection, facilitating further malicious activities. +action.escu.eli5 = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. This activity is significant as disabling MFA can indicate an adversary attempting to weaken account security to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, potentially leading to unauthorized access to sensitive resources and prolonged compromise. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company -action.escu.creation_date = 2024-02-13 -action.escu.modification_date = 2024-02-13 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS Multi-Factor Authentication Disabled - Rule action.escu.search_type = detection @@ -4221,11 +4180,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ASL AWS Multi-Factor Authentication Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d2df5e0-1092-4817-88a8-79c7fa054668", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d2df5e0-1092-4817-88a8-79c7fa054668", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with less risk of detection, facilitating further malicious activities. +action.notable.param.rule_description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. This activity is significant as disabling MFA can indicate an adversary attempting to weaken account security to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, potentially leading to unauthorized access to sensitive resources and prolonged compromise. action.notable.param.rule_title = ASL AWS Multi-Factor Authentication Disabled action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4243,14 +4202,14 @@ search = `amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.ope [ESCU - ASL AWS New MFA Method Registered For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects when a new Multi-Factor Authentication (MFA) method is registered for an AWS account, as logged through Amazon Security Lake (ASL). This behavior is detected by monitoring ASL logs for specific API calls associated with MFA registration. Identifying this activity is crucial for a Security Operations Center (SOC) because unauthorized registration of a new MFA method can indicate an adversary's attempt to establish or maintain access to a compromised account. The impact of such an attack is significant as it can enable persistent access for the attacker, potentially leading to further compromise and exploitation of cloud resources. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies the registration of a new Multi-Factor Authentication (MFA) method for an AWS account, as logged through Amazon Security Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` API operation within ASL logs. This behavior is significant because adversaries who gain unauthorized access to an AWS account may register a new MFA method to maintain persistence. If confirmed malicious, this activity could allow attackers to secure their access, making it harder to detect and remove their presence from the compromised environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects when a new Multi-Factor Authentication (MFA) method is registered for an AWS account, as logged through Amazon Security Lake (ASL). This behavior is detected by monitoring ASL logs for specific API calls associated with MFA registration. Identifying this activity is crucial for a Security Operations Center (SOC) because unauthorized registration of a new MFA method can indicate an adversary's attempt to establish or maintain access to a compromised account. The impact of such an attack is significant as it can enable persistent access for the attacker, potentially leading to further compromise and exploitation of cloud resources. +action.escu.eli5 = The following analytic identifies the registration of a new Multi-Factor Authentication (MFA) method for an AWS account, as logged through Amazon Security Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` API operation within ASL logs. This behavior is significant because adversaries who gain unauthorized access to an AWS account may register a new MFA method to maintain persistence. If confirmed malicious, this activity could allow attackers to secure their access, making it harder to detect and remove their presence from the compromised environment. action.escu.how_to_implement = The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App. action.escu.known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. -action.escu.creation_date = 2024-02-13 -action.escu.modification_date = 2024-02-13 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - ASL AWS New MFA Method Registered For User - Rule action.escu.search_type = detection @@ -4268,11 +4227,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - ASL AWS New MFA Method Registered For User - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "33ae0931-2a03-456b-b1d7-b016c5557fbd", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "33ae0931-2a03-456b-b1d7-b016c5557fbd", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects when a new Multi-Factor Authentication (MFA) method is registered for an AWS account, as logged through Amazon Security Lake (ASL). This behavior is detected by monitoring ASL logs for specific API calls associated with MFA registration. Identifying this activity is crucial for a Security Operations Center (SOC) because unauthorized registration of a new MFA method can indicate an adversary's attempt to establish or maintain access to a compromised account. The impact of such an attack is significant as it can enable persistent access for the attacker, potentially leading to further compromise and exploitation of cloud resources. +action.notable.param.rule_description = The following analytic identifies the registration of a new Multi-Factor Authentication (MFA) method for an AWS account, as logged through Amazon Security Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` API operation within ASL logs. This behavior is significant because adversaries who gain unauthorized access to an AWS account may register a new MFA method to maintain persistence. If confirmed malicious, this activity could allow attackers to secure their access, making it harder to detect and remove their presence from the compromised environment. action.notable.param.rule_title = ASL AWS New MFA Method Registered For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -4290,14 +4249,14 @@ search = `amazon_security_lake` api.operation=CreateVirtualMFADevice | fillnull [ESCU - AWS AMI Attribute Modification for Exfiltration - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs. +description = The following analytic detects suspicious modifications to AWS AMI attributes, such as sharing an AMI with another AWS account or making it publicly accessible. It leverages AWS CloudTrail logs to identify these changes by monitoring specific API calls. This activity is significant because adversaries can exploit these modifications to exfiltrate sensitive data stored in AWS resources. If confirmed malicious, this could lead to unauthorized access and potential data breaches, compromising the confidentiality and integrity of organizational information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs. +action.escu.eli5 = The following analytic detects suspicious modifications to AWS AMI attributes, such as sharing an AMI with another AWS account or making it publicly accessible. It leverages AWS CloudTrail logs to identify these changes by monitoring specific API calls. This activity is significant because adversaries can exploit these modifications to exfiltrate sensitive data stored in AWS resources. If confirmed malicious, this could lead to unauthorized access and potential data breaches, compromising the confidentiality and integrity of organizational information. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with others for a specific purpose. -action.escu.creation_date = 2023-03-31 -action.escu.modification_date = 2023-03-31 +action.escu.creation_date = 2024-05-09 +action.escu.modification_date = 2024-05-09 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS AMI Attribute Modification for Exfiltration - Rule action.escu.search_type = detection @@ -4315,11 +4274,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS AMI Attribute Modification for Exfiltration - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious Cloud Instance Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 100, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2132d74-cf81-4c5e-8799-ab069e67dc9f", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2132d74-cf81-4c5e-8799-ab069e67dc9f", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs. +action.notable.param.rule_description = The following analytic detects suspicious modifications to AWS AMI attributes, such as sharing an AMI with another AWS account or making it publicly accessible. It leverages AWS CloudTrail logs to identify these changes by monitoring specific API calls. This activity is significant because adversaries can exploit these modifications to exfiltrate sensitive data stored in AWS resources. If confirmed malicious, this could lead to unauthorized access and potential data breaches, compromising the confidentiality and integrity of organizational information. action.notable.param.rule_title = AWS AMI Attribute Modification for Exfiltration action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4337,14 +4296,14 @@ search = `cloudtrail` eventName=ModifyImageAttribute (requestParameters.launchPe [ESCU - AWS Concurrent Sessions From Different Ips - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +description = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute window. It leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` event, to detect this behavior. This activity is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.escu.eli5 = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute window. It leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` event, to detect this behavior. This activity is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation within the AWS environment. action.escu.how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. -action.escu.creation_date = 2023-02-01 -action.escu.modification_date = 2023-02-01 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Concurrent Sessions From Different Ips - Rule action.escu.search_type = detection @@ -4362,11 +4321,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Concurrent Sessions From Different Ips - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "51c04fdb-2746-465a-b86e-b413a09c9085", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "51c04fdb-2746-465a-b86e-b413a09c9085", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.notable.param.rule_description = The following analytic identifies an AWS IAM account with concurrent sessions originating from more than one unique IP address within a 5-minute window. It leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates` event, to detect this behavior. This activity is significant as it may indicate a session hijacking attack, where an adversary uses stolen session cookies to access AWS resources from a different location. If confirmed malicious, this could allow unauthorized access to sensitive corporate resources, leading to potential data breaches or further exploitation within the AWS environment. action.notable.param.rule_title = AWS Concurrent Sessions From Different Ips action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4384,14 +4343,14 @@ search = `cloudtrail` eventName = DescribeEventAggregates src_ip!="AWS Internal [ESCU - AWS Console Login Failed During MFA Challenge - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an authentication attempt event against an AWS Console that fails during the Multi Factor Authentication challenge. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +description = The following analytic identifies failed authentication attempts to the AWS Console during the Multi-Factor Authentication (MFA) challenge. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect when MFA was used but the login attempt still failed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials but being thwarted by MFA. If confirmed malicious, this could suggest an ongoing attempt to breach the account, potentially leading to unauthorized access and further attacks if MFA is bypassed. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an authentication attempt event against an AWS Console that fails during the Multi Factor Authentication challenge. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.escu.eli5 = The following analytic identifies failed authentication attempts to the AWS Console during the Multi-Factor Authentication (MFA) challenge. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect when MFA was used but the login attempt still failed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials but being thwarted by MFA. If confirmed malicious, this could suggest an ongoing attempt to breach the account, potentially leading to unauthorized access and further attacks if MFA is bypassed. action.escu.how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. -action.escu.creation_date = 2022-10-03 -action.escu.modification_date = 2022-10-03 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Console Login Failed During MFA Challenge - Rule action.escu.search_type = detection @@ -4409,11 +4368,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Console Login Failed During MFA Challenge - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "55349868-5583-466f-98ab-d3beb321961e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "55349868-5583-466f-98ab-d3beb321961e", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an authentication attempt event against an AWS Console that fails during the Multi Factor Authentication challenge. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.notable.param.rule_description = The following analytic identifies failed authentication attempts to the AWS Console during the Multi-Factor Authentication (MFA) challenge. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect when MFA was used but the login attempt still failed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials but being thwarted by MFA. If confirmed malicious, this could suggest an ongoing attempt to breach the account, potentially leading to unauthorized access and further attacks if MFA is bypassed. action.notable.param.rule_title = AWS Console Login Failed During MFA Challenge action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4431,14 +4390,14 @@ search = `cloudtrail` eventName= ConsoleLogin errorMessage="Failed authenticatio [ESCU - AWS Create Policy Version to allow all resources - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account. +description = The following analytic identifies the creation of a new AWS IAM policy version that allows access to all resources. It detects this activity by analyzing AWS CloudTrail logs for the CreatePolicyVersion event with a policy document that grants broad permissions. This behavior is significant because it violates the principle of least privilege, potentially exposing the environment to misuse or abuse. If confirmed malicious, an attacker could gain extensive access to AWS resources, leading to unauthorized actions, data exfiltration, or further compromise of the AWS environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account. +action.escu.eli5 = The following analytic identifies the creation of a new AWS IAM policy version that allows access to all resources. It detects this activity by analyzing AWS CloudTrail logs for the CreatePolicyVersion event with a policy document that grants broad permissions. This behavior is significant because it violates the principle of least privilege, potentially exposing the environment to misuse or abuse. If confirmed malicious, an attacker could gain extensive access to AWS resources, leading to unauthorized actions, data exfiltration, or further compromise of the AWS environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources and you must verify this activity. -action.escu.creation_date = 2024-04-16 -action.escu.modification_date = 2024-04-16 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Create Policy Version to allow all resources - Rule action.escu.search_type = detection @@ -4456,11 +4415,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Create Policy Version to allow all resources - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-b5ad-212bf3d0dac4", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-b5ad-212bf3d0dac4", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account. +action.notable.param.rule_description = The following analytic identifies the creation of a new AWS IAM policy version that allows access to all resources. It detects this activity by analyzing AWS CloudTrail logs for the CreatePolicyVersion event with a policy document that grants broad permissions. This behavior is significant because it violates the principle of least privilege, potentially exposing the environment to misuse or abuse. If confirmed malicious, an attacker could gain extensive access to AWS resources, leading to unauthorized actions, data exfiltration, or further compromise of the AWS environment. action.notable.param.rule_title = AWS Create Policy Version to allow all resources action.notable.param.security_domain = network action.notable.param.severity = high @@ -4478,14 +4437,14 @@ search = `cloudtrail` eventName=CreatePolicyVersion eventSource = iam.amazonaws. [ESCU - AWS CreateAccessKey - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed manual during threat hunting. +description = The following analytic identifies the creation of AWS IAM access keys by a user for another user, which can indicate privilege escalation. It leverages AWS CloudTrail logs to detect instances where the user creating the access key is different from the user for whom the key is created. This activity is significant because unauthorized access key creation can allow attackers to establish persistence or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized access to AWS services, data exfiltration, and long-term persistence in the environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed manual during threat hunting. +action.escu.eli5 = The following analytic identifies the creation of AWS IAM access keys by a user for another user, which can indicate privilege escalation. It leverages AWS CloudTrail logs to detect instances where the user creating the access key is different from the user for whom the key is created. This activity is significant because unauthorized access key creation can allow attackers to establish persistence or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized access to AWS services, data exfiltration, and long-term persistence in the environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user. -action.escu.creation_date = 2022-03-03 -action.escu.modification_date = 2022-03-03 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS CreateAccessKey - Rule action.escu.search_type = detection @@ -4498,7 +4457,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS CreateAccessKey - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 13"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf3d0d111", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf3d0d111", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -4514,14 +4473,14 @@ search = `cloudtrail` eventName = CreateAccessKey userAgent !=console.amazonaws. [ESCU - AWS CreateLoginProfile - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip +description = The following analytic identifies the creation of a login profile for one AWS user by another, followed by a console login from the same source IP. It uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` events based on the source IP and user identity. This activity is significant as it may indicate privilege escalation, where an attacker creates a new login profile to gain unauthorized access. If confirmed malicious, this could allow the attacker to escalate privileges and maintain persistent access to the AWS environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip +action.escu.eli5 = The following analytic identifies the creation of a login profile for one AWS user by another, followed by a console login from the same source IP. It uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` events based on the source IP and user identity. This activity is significant as it may indicate privilege escalation, where an attacker creates a new login profile to gain unauthorized access. If confirmed malicious, this could allow the attacker to escalate privileges and maintain persistent access to the AWS environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a login profile for another user. -action.escu.creation_date = 2021-07-19 -action.escu.modification_date = 2021-07-19 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS CreateLoginProfile - Rule action.escu.search_type = detection @@ -4539,11 +4498,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS CreateLoginProfile - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 13"], "confidence": 80, "impact": 90, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf444d111", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf444d111", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip +action.notable.param.rule_description = The following analytic identifies the creation of a login profile for one AWS user by another, followed by a console login from the same source IP. It uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` events based on the source IP and user identity. This activity is significant as it may indicate privilege escalation, where an attacker creates a new login profile to gain unauthorized access. If confirmed malicious, this could allow the attacker to escalate privileges and maintain persistent access to the AWS environment. action.notable.param.rule_title = AWS CreateLoginProfile action.notable.param.security_domain = network action.notable.param.severity = high @@ -4561,14 +4520,14 @@ search = `cloudtrail` eventName = CreateLoginProfile | rename requestParameters. [ESCU - AWS Credential Access Failed Login - Rule] action.escu = 0 action.escu.enabled = 1 -description = It shows that there have been an unsuccessful attempt to log in using the user identity to the AWS management console. Since the user identity has access to AWS account services and resources, an attacker might try to brute force the password for that identity. +description = The following analytic identifies unsuccessful login attempts to the AWS Management Console using a specific user identity. It leverages AWS CloudTrail logs to detect failed authentication events associated with the AWS ConsoleLogin action. This activity is significant for a SOC because repeated failed login attempts may indicate a brute force attack or unauthorized access attempts. If confirmed malicious, an attacker could potentially gain access to AWS account services and resources, leading to data breaches, resource manipulation, or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.001"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = It shows that there have been an unsuccessful attempt to log in using the user identity to the AWS management console. Since the user identity has access to AWS account services and resources, an attacker might try to brute force the password for that identity. +action.escu.eli5 = The following analytic identifies unsuccessful login attempts to the AWS Management Console using a specific user identity. It leverages AWS CloudTrail logs to detect failed authentication events associated with the AWS ConsoleLogin action. This activity is significant for a SOC because repeated failed login attempts may indicate a brute force attack or unauthorized access attempts. If confirmed malicious, an attacker could potentially gain access to AWS account services and resources, leading to data breaches, resource manipulation, or further exploitation within the AWS environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = Users may genuinely mistype or forget the password. -action.escu.creation_date = 2022-08-07 -action.escu.modification_date = 2022-08-07 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Credential Access Failed Login - Rule action.escu.search_type = detection @@ -4586,11 +4545,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Credential Access Failed Login - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a19b354d-0d7f-47f3-8ea6-1a7c36434968", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a19b354d-0d7f-47f3-8ea6-1a7c36434968", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = It shows that there have been an unsuccessful attempt to log in using the user identity to the AWS management console. Since the user identity has access to AWS account services and resources, an attacker might try to brute force the password for that identity. +action.notable.param.rule_description = The following analytic identifies unsuccessful login attempts to the AWS Management Console using a specific user identity. It leverages AWS CloudTrail logs to detect failed authentication events associated with the AWS ConsoleLogin action. This activity is significant for a SOC because repeated failed login attempts may indicate a brute force attack or unauthorized access attempts. If confirmed malicious, an attacker could potentially gain access to AWS account services and resources, leading to data breaches, resource manipulation, or further exploitation within the AWS environment. action.notable.param.rule_title = AWS Credential Access Failed Login action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4649,14 +4608,14 @@ search = `cloudtrail` eventName=GetPasswordData eventSource = ec2.amazonaws.com [ESCU - AWS Credential Access RDS Password reset - Rule] action.escu = 0 action.escu.enabled = 1 -description = The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like Credit card information, PII, Health care Data. This event should be investigated further. +description = The following analytic detects the resetting of the master user password for an Amazon RDS DB instance. It leverages AWS CloudTrail logs to identify events where the `ModifyDBInstance` API call includes a new `masterUserPassword` parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, such as credit card information, PII, and healthcare data. If confirmed malicious, this could lead to data breaches, regulatory non-compliance, and significant reputational damage. Immediate investigation is required to determine the legitimacy of the password reset. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like Credit card information, PII, Health care Data. This event should be investigated further. +action.escu.eli5 = The following analytic detects the resetting of the master user password for an Amazon RDS DB instance. It leverages AWS CloudTrail logs to identify events where the `ModifyDBInstance` API call includes a new `masterUserPassword` parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, such as credit card information, PII, and healthcare data. If confirmed malicious, this could lead to data breaches, regulatory non-compliance, and significant reputational damage. Immediate investigation is required to determine the legitimacy of the password reset. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = Users may genuinely reset the RDS password. -action.escu.creation_date = 2024-03-19 -action.escu.modification_date = 2024-03-19 +action.escu.creation_date = 2024-05-09 +action.escu.modification_date = 2024-05-09 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Credential Access RDS Password reset - Rule action.escu.search_type = detection @@ -4674,11 +4633,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Credential Access RDS Password reset - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6153c5ea-ed30-4878-81e6-21ecdb198189", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6153c5ea-ed30-4878-81e6-21ecdb198189", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like Credit card information, PII, Health care Data. This event should be investigated further. +action.notable.param.rule_description = The following analytic detects the resetting of the master user password for an Amazon RDS DB instance. It leverages AWS CloudTrail logs to identify events where the `ModifyDBInstance` API call includes a new `masterUserPassword` parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, such as credit card information, PII, and healthcare data. If confirmed malicious, this could lead to data breaches, regulatory non-compliance, and significant reputational damage. Immediate investigation is required to determine the legitimacy of the password reset. action.notable.param.rule_title = AWS Credential Access RDS Password reset action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4737,14 +4696,14 @@ search = | tstats min(_time) as firstTime max(_time) as lastTime from datamodel= [ESCU - AWS Defense Evasion Delete Cloudtrail - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment. +description = The following analytic detects the deletion of AWS CloudTrail logs by identifying `DeleteTrail` events within CloudTrail logs. This detection leverages CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those initiated from the AWS console. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to prolonged unauthorized access and further exploitation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment. +action.escu.eli5 = The following analytic detects the deletion of AWS CloudTrail logs by identifying `DeleteTrail` events within CloudTrail logs. This detection leverages CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those initiated from the AWS console. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to prolonged unauthorized access and further exploitation. action.escu.how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity. -action.escu.creation_date = 2022-07-13 -action.escu.modification_date = 2022-07-13 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion Delete Cloudtrail - Rule action.escu.search_type = detection @@ -4762,11 +4721,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion Delete Cloudtrail - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "82092925-9ca1-4e06-98b8-85a2d3889552", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "82092925-9ca1-4e06-98b8-85a2d3889552", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment. +action.notable.param.rule_description = The following analytic detects the deletion of AWS CloudTrail logs by identifying `DeleteTrail` events within CloudTrail logs. This detection leverages CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those initiated from the AWS console. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to prolonged unauthorized access and further exploitation. action.notable.param.rule_title = AWS Defense Evasion Delete Cloudtrail action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4784,14 +4743,14 @@ search = `cloudtrail` eventName = DeleteTrail eventSource = cloudtrail.amazonaws [ESCU - AWS Defense Evasion Delete CloudWatch Log Group - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment. +description = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This detection leverages CloudTrail data to monitor for successful log group deletions, excluding console-based actions. This activity is significant as it indicates potential attempts to evade logging and monitoring, which is crucial for maintaining visibility into AWS activities. If confirmed malicious, this could allow attackers to hide their tracks, making it difficult to detect further malicious actions or investigate incidents within the compromised AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment. +action.escu.eli5 = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This detection leverages CloudTrail data to monitor for successful log group deletions, excluding console-based actions. This activity is significant as it indicates potential attempts to evade logging and monitoring, which is crucial for maintaining visibility into AWS activities. If confirmed malicious, this could allow attackers to hide their tracks, making it difficult to detect further malicious actions or investigate incidents within the compromised AWS environment. action.escu.how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity. -action.escu.creation_date = 2022-07-17 -action.escu.modification_date = 2022-07-17 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion Delete CloudWatch Log Group - Rule action.escu.search_type = detection @@ -4809,11 +4768,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion Delete CloudWatch Log Group - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d308b0f1-edb7-4a62-a614-af321160710f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d308b0f1-edb7-4a62-a614-af321160710f", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment. +action.notable.param.rule_description = The following analytic detects the deletion of CloudWatch log groups in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This detection leverages CloudTrail data to monitor for successful log group deletions, excluding console-based actions. This activity is significant as it indicates potential attempts to evade logging and monitoring, which is crucial for maintaining visibility into AWS activities. If confirmed malicious, this could allow attackers to hide their tracks, making it difficult to detect further malicious actions or investigate incidents within the compromised AWS environment. action.notable.param.rule_title = AWS Defense Evasion Delete CloudWatch Log Group action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4831,14 +4790,14 @@ search = `cloudtrail` eventName = DeleteLogGroup eventSource = logs.amazonaws.co [ESCU - AWS Defense Evasion Impair Security Services - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for several delete specific API calls made to AWS Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These API calls are often leveraged by adversaries to weaken existing security defenses by deleting logging configurations in the CloudWatch alarm, delete a set of detectors from your Guardduty environment or simply delete a bunch of CloudWatch alarms to remain stealthy and avoid detection. +description = The following analytic detects attempts to delete critical AWS security service configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages CloudTrail logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because it indicates potential efforts to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, escalate privileges, or exfiltrate data without triggering security alerts, severely compromising the security posture of the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = ["Web"] -action.escu.eli5 = This analytic looks for several delete specific API calls made to AWS Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These API calls are often leveraged by adversaries to weaken existing security defenses by deleting logging configurations in the CloudWatch alarm, delete a set of detectors from your Guardduty environment or simply delete a bunch of CloudWatch alarms to remain stealthy and avoid detection. +action.escu.eli5 = The following analytic detects attempts to delete critical AWS security service configurations, such as CloudWatch alarms, GuardDuty detectors, and Web Application Firewall rules. It leverages CloudTrail logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because it indicates potential efforts to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, escalate privileges, or exfiltrate data without triggering security alerts, severely compromising the security posture of the AWS environment. action.escu.how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. -action.escu.creation_date = 2022-07-26 -action.escu.modification_date = 2022-07-26 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion Impair Security Services - Rule action.escu.search_type = detection @@ -4851,7 +4810,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion Impair Security Services - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b28c4957-96a6-47e0-a965-6c767aac1458", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b28c4957-96a6-47e0-a965-6c767aac1458", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -4867,14 +4826,14 @@ search = `cloudtrail` eventName IN ("DeleteLogStream","DeleteDetector","DeleteIP [ESCU - AWS Defense Evasion PutBucketLifecycle - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies `PutBucketLifecycle` events in CloudTrail logs where a user has created a new lifecycle rule for an S3 bucket with a short expiration period. Attackers may use this API call to impair the CloudTrail logging by removing logs from the S3 bucket by changing the object expiration day to 1 day, in which case the CloudTrail logs will be deleted. +description = The following analytic detects `PutBucketLifecycle` events in AWS CloudTrail logs where a user sets a lifecycle rule for an S3 bucket with an expiration period of fewer than three days. This detection leverages CloudTrail logs to identify suspicious lifecycle configurations. This activity is significant because attackers may use it to delete CloudTrail logs quickly, thereby evading detection and impairing forensic investigations. If confirmed malicious, this could allow attackers to cover their tracks, making it difficult to trace their actions and respond to the breach effectively. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies `PutBucketLifecycle` events in CloudTrail logs where a user has created a new lifecycle rule for an S3 bucket with a short expiration period. Attackers may use this API call to impair the CloudTrail logging by removing logs from the S3 bucket by changing the object expiration day to 1 day, in which case the CloudTrail logs will be deleted. +action.escu.eli5 = The following analytic detects `PutBucketLifecycle` events in AWS CloudTrail logs where a user sets a lifecycle rule for an S3 bucket with an expiration period of fewer than three days. This detection leverages CloudTrail logs to identify suspicious lifecycle configurations. This activity is significant because attackers may use it to delete CloudTrail logs quickly, thereby evading detection and impairing forensic investigations. If confirmed malicious, this could allow attackers to cover their tracks, making it difficult to trace their actions and respond to the breach effectively. action.escu.how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. We recommend our users to set the expiration days value according to your company's log retention policies. action.escu.known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names. -action.escu.creation_date = 2022-07-25 -action.escu.modification_date = 2022-07-25 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion PutBucketLifecycle - Rule action.escu.search_type = detection @@ -4887,7 +4846,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion PutBucketLifecycle - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 40, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce1c0e2b-9303-4903-818b-0d9002fc6ea4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce1c0e2b-9303-4903-818b-0d9002fc6ea4", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -4903,14 +4862,14 @@ search = `cloudtrail` eventName=PutBucketLifecycle user_type=IAMUser errorCode=s [ESCU - AWS Defense Evasion Stop Logging Cloudtrail - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their macliious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may easily stop logging. +description = The following analytic detects `StopLogging` events in AWS CloudTrail logs. It leverages CloudTrail event data to identify when logging is intentionally stopped, excluding console-based actions and focusing on successful attempts. This activity is significant because adversaries may stop logging to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to perform further activities without being logged, hindering incident response and forensic investigations, and potentially leading to unauthorized access or data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their macliious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may easily stop logging. +action.escu.eli5 = The following analytic detects `StopLogging` events in AWS CloudTrail logs. It leverages CloudTrail event data to identify when logging is intentionally stopped, excluding console-based actions and focusing on successful attempts. This activity is significant because adversaries may stop logging to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to perform further activities without being logged, hindering incident response and forensic investigations, and potentially leading to unauthorized access or data exfiltration. action.escu.how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudtrail logging. Please investigate this activity. -action.escu.creation_date = 2022-07-12 -action.escu.modification_date = 2022-07-12 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion Stop Logging Cloudtrail - Rule action.escu.search_type = detection @@ -4928,11 +4887,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion Stop Logging Cloudtrail - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a2f3ca2-4eb5-4389-a549-14063882e537", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a2f3ca2-4eb5-4389-a549-14063882e537", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their macliious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may easily stop logging. +action.notable.param.rule_description = The following analytic detects `StopLogging` events in AWS CloudTrail logs. It leverages CloudTrail event data to identify when logging is intentionally stopped, excluding console-based actions and focusing on successful attempts. This activity is significant because adversaries may stop logging to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to perform further activities without being logged, hindering incident response and forensic investigations, and potentially leading to unauthorized access or data exfiltration. action.notable.param.rule_title = AWS Defense Evasion Stop Logging Cloudtrail action.notable.param.security_domain = threat action.notable.param.severity = high @@ -4950,14 +4909,14 @@ search = `cloudtrail` eventName = StopLogging eventSource = cloudtrail.amazonaws [ESCU - AWS Defense Evasion Update Cloudtrail - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers may evade the logging capability by updating the settings and impairing them with wrong parameters. For example, Attackers may change the multi-regional log into a single region logs, which evades the logging for other regions. When the adversary has the right type of permissions in the compromised AWS environment, they may update the CloudTrail settings that is logging activities in your environment. +description = The following analytic detects `UpdateTrail` events in AWS CloudTrail logs. It identifies attempts to modify CloudTrail settings, potentially to evade logging. The detection leverages CloudTrail logs, focusing on `UpdateTrail` events where the user agent is not the AWS console and the operation is successful. This activity is significant because altering CloudTrail settings can disable or limit logging, hindering visibility into AWS account activities. If confirmed malicious, this could allow attackers to operate undetected, compromising the integrity and security of the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers may evade the logging capability by updating the settings and impairing them with wrong parameters. For example, Attackers may change the multi-regional log into a single region logs, which evades the logging for other regions. When the adversary has the right type of permissions in the compromised AWS environment, they may update the CloudTrail settings that is logging activities in your environment. +action.escu.eli5 = The following analytic detects `UpdateTrail` events in AWS CloudTrail logs. It identifies attempts to modify CloudTrail settings, potentially to evade logging. The detection leverages CloudTrail logs, focusing on `UpdateTrail` events where the user agent is not the AWS console and the operation is successful. This activity is significant because altering CloudTrail settings can disable or limit logging, hindering visibility into AWS account activities. If confirmed malicious, this could allow attackers to operate undetected, compromising the integrity and security of the AWS environment. action.escu.how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has updated cloudtrail logging. Please investigate this activity. -action.escu.creation_date = 2022-07-17 -action.escu.modification_date = 2022-07-17 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Defense Evasion Update Cloudtrail - Rule action.escu.search_type = detection @@ -4975,11 +4934,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Defense Evasion Update Cloudtrail - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Defense Evasion"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7c921d28-ef48-4f1b-85b3-0af8af7697db", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7c921d28-ef48-4f1b-85b3-0af8af7697db", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers may evade the logging capability by updating the settings and impairing them with wrong parameters. For example, Attackers may change the multi-regional log into a single region logs, which evades the logging for other regions. When the adversary has the right type of permissions in the compromised AWS environment, they may update the CloudTrail settings that is logging activities in your environment. +action.notable.param.rule_description = The following analytic detects `UpdateTrail` events in AWS CloudTrail logs. It identifies attempts to modify CloudTrail settings, potentially to evade logging. The detection leverages CloudTrail logs, focusing on `UpdateTrail` events where the user agent is not the AWS console and the operation is successful. This activity is significant because altering CloudTrail settings can disable or limit logging, hindering visibility into AWS account activities. If confirmed malicious, this could allow attackers to operate undetected, compromising the integrity and security of the AWS environment. action.notable.param.rule_title = AWS Defense Evasion Update Cloudtrail action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5069,14 +5028,14 @@ search = `aws_cloudwatchlogs_eks` CreateAccessKey | spath eventName | search eve [ESCU - aws detect role creation - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search provides detection of role creation by IAM users. Role creation is an event by itself if user is creating a new role with trust policies different than the available in AWS and it can be used for lateral movement and escalation of privileges. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies the creation of new IAM roles by users in AWS. It leverages CloudWatch logs to detect events where the `CreateRole` action is performed, focusing on roles with specific trust policies. This activity is significant as unauthorized role creation can facilitate lateral movement and privilege escalation within the AWS environment. If confirmed malicious, attackers could gain elevated permissions, potentially compromising sensitive resources and data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search provides detection of role creation by IAM users. Role creation is an event by itself if user is creating a new role with trust policies different than the available in AWS and it can be used for lateral movement and escalation of privileges. +action.escu.eli5 = The following analytic identifies the creation of new IAM roles by users in AWS. It leverages CloudWatch logs to detect events where the `CreateRole` action is performed, focusing on roles with specific trust policies. This activity is significant as unauthorized role creation can facilitate lateral movement and privilege escalation within the AWS environment. If confirmed malicious, attackers could gain elevated permissions, potentially compromising sensitive resources and data. action.escu.how_to_implement = You must install splunk AWS add-on and Splunk App for AWS. This search works with cloudwatch logs action.escu.known_false_positives = CreateRole is not very common in common users. This search can be adjusted to provide specific values to identify cases of abuse. In general AWS provides plenty of trust policies that fit most use cases. -action.escu.creation_date = 2020-07-27 -action.escu.modification_date = 2020-07-27 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - aws detect role creation - Rule action.escu.search_type = detection @@ -5089,7 +5048,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - aws detect role creation - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Cross Account Activity"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f04081e-ddee-4353-afe4-504f288de9ad", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f04081e-ddee-4353-afe4-504f288de9ad", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5177,14 +5136,14 @@ search = `aws_cloudwatchlogs_eks` ASIA userIdentity.type=IAMUser| spath eventNa [ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company. +description = The following analytic detects the creation of AWS KMS keys with an encryption policy accessible to everyone, including external entities. It leverages AWS CloudTrail logs to identify `CreateKey` or `PutKeyPolicy` events where the `kms:Encrypt` action is granted to all principals. This activity is significant as it may indicate a compromised account, allowing an attacker to misuse the encryption key to target other organizations. If confirmed malicious, this could lead to unauthorized data encryption, potentially disrupting operations and compromising sensitive information across multiple entities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company. +action.escu.eli5 = The following analytic detects the creation of AWS KMS keys with an encryption policy accessible to everyone, including external entities. It leverages AWS CloudTrail logs to identify `CreateKey` or `PutKeyPolicy` events where the `kms:Encrypt` action is granted to all principals. This activity is significant as it may indicate a compromised account, allowing an attacker to misuse the encryption key to target other organizations. If confirmed malicious, this could lead to unauthorized data encryption, potentially disrupting operations and compromising sensitive information across multiple entities. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-01-11 -action.escu.modification_date = 2021-01-11 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule action.escu.search_type = detection @@ -5202,11 +5161,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware Cloud"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c79c164f-4b21-4847-98f9-cf6a9f49179e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c79c164f-4b21-4847-98f9-cf6a9f49179e", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company. +action.notable.param.rule_description = The following analytic detects the creation of AWS KMS keys with an encryption policy accessible to everyone, including external entities. It leverages AWS CloudTrail logs to identify `CreateKey` or `PutKeyPolicy` events where the `kms:Encrypt` action is granted to all principals. This activity is significant as it may indicate a compromised account, allowing an attacker to misuse the encryption key to target other organizations. If confirmed malicious, this could lead to unauthorized data encryption, potentially disrupting operations and compromising sensitive information across multiple entities. action.notable.param.rule_title = AWS Detect Users creating keys with encrypt policy without MFA action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5265,14 +5224,14 @@ search = `cloudtrail` eventName=CopyObject requestParameters.x-amz-server-side-e [ESCU - AWS Disable Bucket Versioning - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects AWS CloudTrail events where bucket versioning is suspended by a user. Versioning allows the AWS Administrators to maintain different version of the S3 bucket which can be used to recover deleted data. Adversaries have leveraged this technique in the wild during a ransomware incident to disable versioning so the client cannot recover the data. +description = The following analytic detects when AWS S3 bucket versioning is suspended by a user. It leverages AWS CloudTrail logs to identify `PutBucketVersioning` events with the `VersioningConfiguration.Status` set to `Suspended`. This activity is significant because disabling versioning can prevent recovery of deleted or modified data, which is a common tactic in ransomware attacks. If confirmed malicious, this action could lead to data loss and hinder recovery efforts, severely impacting data integrity and availability. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects AWS CloudTrail events where bucket versioning is suspended by a user. Versioning allows the AWS Administrators to maintain different version of the S3 bucket which can be used to recover deleted data. Adversaries have leveraged this technique in the wild during a ransomware incident to disable versioning so the client cannot recover the data. +action.escu.eli5 = The following analytic detects when AWS S3 bucket versioning is suspended by a user. It leverages AWS CloudTrail logs to identify `PutBucketVersioning` events with the `VersioningConfiguration.Status` set to `Suspended`. This activity is significant because disabling versioning can prevent recovery of deleted or modified data, which is a common tactic in ransomware attacks. If confirmed malicious, this action could lead to data loss and hinder recovery efforts, severely impacting data integrity and availability. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that an AWS Administrator has legitimately disabled versioning on certain buckets to avoid costs. -action.escu.creation_date = 2023-05-01 -action.escu.modification_date = 2023-05-01 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Disable Bucket Versioning - Rule action.escu.search_type = detection @@ -5290,7 +5249,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Disable Bucket Versioning - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious AWS S3 Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "657902a9-987d-4879-a1b2-e7a65512824b", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "657902a9-987d-4879-a1b2-e7a65512824b", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5348,7 +5307,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventName=ModifySnapshotAttribute | rename requestParameters.createVolumePermission.add.items{}.userId as requested_account_id | search requested_account_id != NULL | eval match=if(requested_account_id==aws_account_id,"Match","No Match") | table _time user_arn src_ip requestParameters.attributeType requested_account_id aws_account_id match vendor_region user_agent userIdentity.principalId | where match = "No Match" | `aws_ec2_snapshot_shared_externally_filter` +search = `cloudtrail` eventName=ModifySnapshotAttribute | rename requestParameters.createVolumePermission.add.items{}.userId as requested_account_id | search requested_account_id != NULL | eval match=if(requested_account_id==aws_account_id,"Match","No Match") | table _time user_arn src_ip requestParameters.attributeType requested_account_id aws_account_id match vendor_region user_agent userIdentity.principalId | where match = "No Match" | `aws_ec2_snapshot_shared_externally_filter` [ESCU - AWS ECR Container Scanning Findings High - Rule] action.escu = 0 @@ -5482,14 +5441,14 @@ search = `cloudtrail` eventSource=ecr.amazonaws.com eventName=DescribeImageScanF [ESCU - AWS ECR Container Upload Outside Business Hours - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done during business hours. When done outside business hours, we want to take a look into it. +description = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) outside of standard business hours. It leverages AWS CloudTrail logs to identify `PutImage` events occurring between 8 PM and 8 AM or on weekends. This activity is significant because container uploads outside business hours can indicate unauthorized or suspicious activity, potentially pointing to a compromised account or insider threat. If confirmed malicious, this could allow an attacker to deploy unauthorized or malicious containers, leading to potential data breaches or service disruptions. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done during business hours. When done outside business hours, we want to take a look into it. +action.escu.eli5 = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) outside of standard business hours. It leverages AWS CloudTrail logs to identify `PutImage` events occurring between 8 PM and 8 AM or on weekends. This activity is significant because container uploads outside business hours can indicate unauthorized or suspicious activity, potentially pointing to a compromised account or insider threat. If confirmed malicious, this could allow an attacker to deploy unauthorized or malicious containers, leading to potential data breaches or service disruptions. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = When your development is spreaded in different time zones, applying this rule can be difficult. -action.escu.creation_date = 2023-11-09 -action.escu.modification_date = 2023-11-09 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS ECR Container Upload Outside Business Hours - Rule action.escu.search_type = detection @@ -5507,7 +5466,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS ECR Container Upload Outside Business Hours - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d4c4d4eb-3994-41ca-a25e-a82d64e125bb", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d4c4d4eb-3994-41ca-a25e-a82d64e125bb", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5523,14 +5482,14 @@ search = `cloudtrail` eventSource=ecr.amazonaws.com eventName=PutImage date_hour [ESCU - AWS ECR Container Upload Unknown User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done from only a few known users. When the user was never seen before, we should have a closer look into the event. +description = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) by an unknown user. It leverages AWS CloudTrail logs to identify `PutImage` events from the ECR service, filtering out known users. This activity is significant because container uploads should typically be performed by a limited set of authorized users. If confirmed malicious, this could indicate unauthorized access, potentially leading to the deployment of malicious containers, data exfiltration, or further compromise of the AWS environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done from only a few known users. When the user was never seen before, we should have a closer look into the event. +action.escu.eli5 = The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) by an unknown user. It leverages AWS CloudTrail logs to identify `PutImage` events from the ECR service, filtering out known users. This activity is significant because container uploads should typically be performed by a limited set of authorized users. If confirmed malicious, this could indicate unauthorized access, potentially leading to the deployment of malicious containers, data exfiltration, or further compromise of the AWS environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-08-19 -action.escu.modification_date = 2021-08-19 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS ECR Container Upload Unknown User - Rule action.escu.search_type = detection @@ -5548,7 +5507,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS ECR Container Upload Unknown User - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "300688e4-365c-4486-a065-7c884462b31d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "300688e4-365c-4486-a065-7c884462b31d", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5611,14 +5570,14 @@ search = `cloudtrail` eventName=Describe* OR eventName=List* OR eventName=Get* [ESCU - AWS Exfiltration via Anomalous GetObject API Activity - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search uses built in Splunk command `| anomalydetection` to detect anomalies with respect to users making high number of GetObject API calls to download objects from S3 in a 10 minute time window. The field `probable_cause` is the name of the field that best explains why the event is anomalous. This command identifies anomalous events by computing a probability for each GetObject event by "count" "user_type" "user_arn" and detects anomaly based on the frequencies. +description = The following analytic identifies anomalous GetObject API activity in AWS, indicating potential data exfiltration attempts. It leverages AWS CloudTrail logs and uses the `anomalydetection` command to detect unusual patterns in the frequency of GetObject API calls by analyzing fields such as "count," "user_type," and "user_arn" within a 10-minute window. This activity is significant as it may indicate unauthorized data access or exfiltration from S3 buckets. If confirmed malicious, attackers could exfiltrate sensitive data, leading to data breaches and compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search uses built in Splunk command `| anomalydetection` to detect anomalies with respect to users making high number of GetObject API calls to download objects from S3 in a 10 minute time window. The field `probable_cause` is the name of the field that best explains why the event is anomalous. This command identifies anomalous events by computing a probability for each GetObject event by "count" "user_type" "user_arn" and detects anomaly based on the frequencies. +action.escu.eli5 = The following analytic identifies anomalous GetObject API activity in AWS, indicating potential data exfiltration attempts. It leverages AWS CloudTrail logs and uses the `anomalydetection` command to detect unusual patterns in the frequency of GetObject API calls by analyzing fields such as "count," "user_type," and "user_arn" within a 10-minute window. This activity is significant as it may indicate unauthorized data access or exfiltration from S3 buckets. If confirmed malicious, attackers could exfiltrate sensitive data, leading to data breaches and compliance violations. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that a user downloaded these files to use them locally and there are AWS services in configured that perform these activities for a legitimate reason. Filter is needed. -action.escu.creation_date = 2023-04-10 -action.escu.modification_date = 2023-04-10 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Exfiltration via Anomalous GetObject API Activity - Rule action.escu.search_type = detection @@ -5636,7 +5595,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Exfiltration via Anomalous GetObject API Activity - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e4384bbf-5835-4831-8d85-694de6ad2cc6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e4384bbf-5835-4831-8d85-694de6ad2cc6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5652,14 +5611,14 @@ search = `cloudtrail` eventName=GetObject | bin _time span=10m | stats count va [ESCU - AWS Exfiltration via Batch Service - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job. +description = The following analytic identifies the creation of AWS Batch jobs that could potentially abuse the AWS Bucket Replication feature on S3 buckets. It leverages AWS CloudTrail logs to detect the `JobCreated` event, analyzing job details and their status. This activity is significant because attackers can exploit this feature to exfiltrate data by creating malicious batch jobs. If confirmed malicious, this could lead to unauthorized data transfer between S3 buckets, resulting in data breaches and loss of sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job. +action.escu.eli5 = The following analytic identifies the creation of AWS Batch jobs that could potentially abuse the AWS Bucket Replication feature on S3 buckets. It leverages AWS CloudTrail logs to detect the `JobCreated` event, analyzing job details and their status. This activity is significant because attackers can exploit this feature to exfiltrate data by creating malicious batch jobs. If confirmed malicious, this could lead to unauthorized data transfer between S3 buckets, resulting in data breaches and loss of sensitive information. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that an AWS Administrator or a user has legitimately created this job for some tasks. -action.escu.creation_date = 2023-04-24 -action.escu.modification_date = 2023-04-24 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Exfiltration via Batch Service - Rule action.escu.search_type = detection @@ -5677,11 +5636,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Exfiltration via Batch Service - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "04455dd3-ced7-480f-b8e6-5469b99e98e2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "04455dd3-ced7-480f-b8e6-5469b99e98e2", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job. +action.notable.param.rule_description = The following analytic identifies the creation of AWS Batch jobs that could potentially abuse the AWS Bucket Replication feature on S3 buckets. It leverages AWS CloudTrail logs to detect the `JobCreated` event, analyzing job details and their status. This activity is significant because attackers can exploit this feature to exfiltrate data by creating malicious batch jobs. If confirmed malicious, this could lead to unauthorized data transfer between S3 buckets, resulting in data breaches and loss of sensitive information. action.notable.param.rule_title = AWS Exfiltration via Batch Service action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5694,21 +5653,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventName = JobCreated | stats count min(_time) as firstTime max(_time) as lastTime values(serviceEventDetails.jobArn) as job_arn values(serviceEventDetails.status) as status by src_ip aws_account_id eventName errorCode userAgent| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_exfiltration_via_datasync_task_filter` +search = `cloudtrail` eventName = JobCreated | stats count min(_time) as firstTime max(_time) as lastTime values(serviceEventDetails.jobArn) as job_arn values(serviceEventDetails.status) as status by src_ip aws_account_id eventName errorCode userAgent | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `aws_exfiltration_via_batch_service_filter` [ESCU - AWS Exfiltration via Bucket Replication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region. \ -S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account. +description = The following analytic detects API calls to enable S3 bucket replication services. It leverages AWS CloudTrail logs to identify `PutBucketReplication` events, focusing on fields like `bucketName`, `ReplicationConfiguration.Rule.Destination.Bucket`, and user details. This activity is significant as it can indicate unauthorized data replication, potentially leading to data exfiltration. If confirmed malicious, attackers could replicate sensitive data to external accounts, leading to data breaches and compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region. \ -S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account. +action.escu.eli5 = The following analytic detects API calls to enable S3 bucket replication services. It leverages AWS CloudTrail logs to identify `PutBucketReplication` events, focusing on fields like `bucketName`, `ReplicationConfiguration.Rule.Destination.Bucket`, and user details. This activity is significant as it can indicate unauthorized data replication, potentially leading to data exfiltration. If confirmed malicious, attackers could replicate sensitive data to external accounts, leading to data breaches and compliance violations. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that an AWS admin has legitimately implemented data replication to ensure data availability and improve data protection/backup strategies. -action.escu.creation_date = 2023-04-28 -action.escu.modification_date = 2023-04-28 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Exfiltration via Bucket Replication - Rule action.escu.search_type = detection @@ -5726,12 +5683,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Exfiltration via Bucket Replication - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious AWS S3 Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eeb432d6-2212-43b6-9e89-fcd753f7da4c", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eeb432d6-2212-43b6-9e89-fcd753f7da4c", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region. \ -S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account. +action.notable.param.rule_description = The following analytic detects API calls to enable S3 bucket replication services. It leverages AWS CloudTrail logs to identify `PutBucketReplication` events, focusing on fields like `bucketName`, `ReplicationConfiguration.Rule.Destination.Bucket`, and user details. This activity is significant as it can indicate unauthorized data replication, potentially leading to data exfiltration. If confirmed malicious, attackers could replicate sensitive data to external accounts, leading to data breaches and compliance violations. action.notable.param.rule_title = AWS Exfiltration via Bucket Replication action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5744,19 +5700,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventName = PutBucketReplication eventSource = s3.amazonaws.com | rename requestParameters.* as * | stats count values(bucketName) as source_bucket values(ReplicationConfiguration.Rule.ID) as rule_id values(ReplicationConfiguration.Rule.Destination.Bucket) as destination_bucket by _time user_arn userName user_type src_ip aws_account_id userIdentity.principalId user_agent | `aws_exfiltration_via_ec2_snapshot_filter` +search = `cloudtrail` eventName = PutBucketReplication eventSource = s3.amazonaws.com | rename requestParameters.* as * | stats count values(bucketName) as source_bucket values(ReplicationConfiguration.Rule.ID) as rule_id values(ReplicationConfiguration.Rule.Destination.Bucket) as destination_bucket by _time user_arn userName user_type src_ip aws_account_id userIdentity.principalId user_agent | `aws_exfiltration_via_bucket_replication_filter` [ESCU - AWS Exfiltration via DataSync Task - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data. +description = The following analytic detects the creation of an AWS DataSync task, which could indicate potential data exfiltration. It leverages AWS CloudTrail logs to identify the `CreateTask` event from the DataSync service. This activity is significant because attackers can misuse DataSync to transfer sensitive data from a private AWS location to a public one, leading to data compromise. If confirmed malicious, this could result in unauthorized access to sensitive information, causing severe data breaches and compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data. +action.escu.eli5 = The following analytic detects the creation of an AWS DataSync task, which could indicate potential data exfiltration. It leverages AWS CloudTrail logs to identify the `CreateTask` event from the DataSync service. This activity is significant because attackers can misuse DataSync to transfer sensitive data from a private AWS location to a public one, leading to data compromise. If confirmed malicious, this could result in unauthorized access to sensitive information, causing severe data breaches and compliance violations. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = It is possible that an AWS Administrator has legitimately created this task for creating backup. Please check the `sourceLocationArn` and `destinationLocationArn` of this task -action.escu.creation_date = 2023-04-10 -action.escu.modification_date = 2023-04-10 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Exfiltration via DataSync Task - Rule action.escu.search_type = detection @@ -5774,11 +5730,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Exfiltration via DataSync Task - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious AWS S3 Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "05c4b09f-ea28-4c7c-a7aa-a246f665c8a2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "05c4b09f-ea28-4c7c-a7aa-a246f665c8a2", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data. +action.notable.param.rule_description = The following analytic detects the creation of an AWS DataSync task, which could indicate potential data exfiltration. It leverages AWS CloudTrail logs to identify the `CreateTask` event from the DataSync service. This activity is significant because attackers can misuse DataSync to transfer sensitive data from a private AWS location to a public one, leading to data compromise. If confirmed malicious, this could result in unauthorized access to sensitive information, causing severe data breaches and compliance violations. action.notable.param.rule_title = AWS Exfiltration via DataSync Task action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5796,14 +5752,14 @@ search = `cloudtrail` eventName = CreateTask eventSource="datasync.amazonaws.com [ESCU - AWS Exfiltration via EC2 Snapshot - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information. +description = The following analytic detects a series of AWS API calls related to EC2 snapshots within a short time window, indicating potential exfiltration via EC2 Snapshot modifications. It leverages AWS CloudTrail logs to identify actions such as creating, describing, and modifying snapshot attributes. This activity is significant as it may indicate an attacker attempting to exfiltrate data by sharing EC2 snapshots externally. If confirmed malicious, the attacker could gain access to sensitive information stored in the snapshots, leading to data breaches and potential compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information. +action.escu.eli5 = The following analytic detects a series of AWS API calls related to EC2 snapshots within a short time window, indicating potential exfiltration via EC2 Snapshot modifications. It leverages AWS CloudTrail logs to identify actions such as creating, describing, and modifying snapshot attributes. This activity is significant as it may indicate an attacker attempting to exfiltrate data by sharing EC2 snapshots externally. If confirmed malicious, the attacker could gain access to sensitive information stored in the snapshots, leading to data breaches and potential compliance violations. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. We have intentionally removed `guardduty.amazonaws.com` from src_ip to remove false positives caused by guard duty. We recommend you adjust the time window as per your environment. action.escu.known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with an other account for a specific purpose. Please check any recent change requests filed in your organization. -action.escu.creation_date = 2023-03-22 -action.escu.modification_date = 2023-03-22 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Exfiltration via EC2 Snapshot - Rule action.escu.search_type = detection @@ -5821,11 +5777,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Exfiltration via EC2 Snapshot - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious Cloud Instance Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ac90b339-13fc-4f29-a18c-4abbba1f2171", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ac90b339-13fc-4f29-a18c-4abbba1f2171", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information. +action.notable.param.rule_description = The following analytic detects a series of AWS API calls related to EC2 snapshots within a short time window, indicating potential exfiltration via EC2 Snapshot modifications. It leverages AWS CloudTrail logs to identify actions such as creating, describing, and modifying snapshot attributes. This activity is significant as it may indicate an attacker attempting to exfiltrate data by sharing EC2 snapshots externally. If confirmed malicious, the attacker could gain access to sensitive information stored in the snapshots, leading to data breaches and potential compliance violations. action.notable.param.rule_title = AWS Exfiltration via EC2 Snapshot action.notable.param.security_domain = threat action.notable.param.severity = high @@ -5843,14 +5799,14 @@ search = `cloudtrail` eventName IN ("CreateSnapshot", "DescribeSnapshotAttribute [ESCU - AWS High Number Of Failed Authentications For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an AWS account with more than 20 failed authentication events in the span of 5 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +description = The following analytic detects an AWS account experiencing more than 20 failed authentication attempts within a 5-minute window. It leverages AWS CloudTrail logs to identify multiple failed ConsoleLogin events. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, the attacker could potentially gain unauthorized access, leading to data breaches or further exploitation of the AWS environment. Security teams should consider adjusting the threshold based on their specific environment to reduce false positives. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an AWS account with more than 20 failed authentication events in the span of 5 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +action.escu.eli5 = The following analytic detects an AWS account experiencing more than 20 failed authentication attempts within a 5-minute window. It leverages AWS CloudTrail logs to identify multiple failed ConsoleLogin events. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, the attacker could potentially gain unauthorized access, leading to data breaches or further exploitation of the AWS environment. Security teams should consider adjusting the threshold based on their specific environment to reduce false positives. action.escu.how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. -action.escu.creation_date = 2023-01-27 -action.escu.modification_date = 2023-01-27 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS High Number Of Failed Authentications For User - Rule action.escu.search_type = detection @@ -5868,7 +5824,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS High Number Of Failed Authentications For User - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3236f49-daf3-4b70-b808-9290912ac64d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3236f49-daf3-4b70-b808-9290912ac64d", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5884,14 +5840,14 @@ search = `cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _t [ESCU - AWS High Number Of Failed Authentications From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an IP address failing to authenticate 20 or more times to the AWS Web Console in the span of 5 minutes. This behavior could represent a brute force attack against an AWS tenant to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +description = The following analytic detects an IP address with 20 or more failed authentication attempts to the AWS Web Console within a 5-minute window. This detection leverages CloudTrail logs, aggregating failed login events by IP address and time span. This activity is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges within an AWS environment. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation of AWS resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an IP address failing to authenticate 20 or more times to the AWS Web Console in the span of 5 minutes. This behavior could represent a brute force attack against an AWS tenant to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +action.escu.eli5 = The following analytic detects an IP address with 20 or more failed authentication attempts to the AWS Web Console within a 5-minute window. This detection leverages CloudTrail logs, aggregating failed login events by IP address and time span. This activity is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges within an AWS environment. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation of AWS resources. action.escu.how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment. action.escu.known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. -action.escu.creation_date = 2023-01-30 -action.escu.modification_date = 2023-01-30 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS High Number Of Failed Authentications From Ip - Rule action.escu.search_type = detection @@ -5909,7 +5865,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS High Number Of Failed Authentications From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f75b7f1a-b8eb-4975-a214-ff3e0a944757", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f75b7f1a-b8eb-4975-a214-ff3e0a944757", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5925,14 +5881,14 @@ search = `cloudtrail` eventName=ConsoleLogin action=failure | bucket span=5m _ti [ESCU - AWS IAM AccessDenied Discovery Events - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies excessive AccessDenied events within an hour timeframe. It is possible that an access key to AWS may have been stolen and is being misused to perform discovery events. In these instances, the access is not available with the key stolen therefore these events will be generated. +description = The following analytic identifies excessive AccessDenied events within an hour timeframe for IAM users in AWS. It leverages AWS CloudTrail logs to detect multiple failed access attempts from the same source IP and user identity. This activity is significant as it may indicate that an access key has been compromised and is being misused for unauthorized discovery actions. If confirmed malicious, this could allow attackers to gather information about the AWS environment, potentially leading to further exploitation or privilege escalation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following detection identifies excessive AccessDenied events within an hour timeframe. It is possible that an access key to AWS may have been stolen and is being misused to perform discovery events. In these instances, the access is not available with the key stolen therefore these events will be generated. +action.escu.eli5 = The following analytic identifies excessive AccessDenied events within an hour timeframe for IAM users in AWS. It leverages AWS CloudTrail logs to detect multiple failed access attempts from the same source IP and user identity. This activity is significant as it may indicate that an access key has been compromised and is being misused for unauthorized discovery actions. If confirmed malicious, this could allow attackers to gather information about the AWS environment, potentially leading to further exploitation or privilege escalation. action.escu.how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = It is possible to start this detection will need to be tuned by source IP or user. In addition, change the count values to an upper threshold to restrict false positives. -action.escu.creation_date = 2021-11-12 -action.escu.modification_date = 2021-11-12 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS IAM AccessDenied Discovery Events - Rule action.escu.search_type = detection @@ -5950,7 +5906,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS IAM AccessDenied Discovery Events - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Cloud User Activities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 20, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3e1f1568-9633-11eb-a69c-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3e1f1568-9633-11eb-a69c-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -5966,14 +5922,14 @@ search = `cloudtrail` (errorCode = "AccessDenied") user_type=IAMUser (userAgent! [ESCU - AWS IAM Assume Role Policy Brute Force - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing. +description = The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580", "T1110"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing. +action.escu.eli5 = The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services. action.escu.how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. Set the `where count` greater than a value to identify suspicious activity in your environment. action.escu.known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. -action.escu.creation_date = 2021-04-01 -action.escu.modification_date = 2021-04-01 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS IAM Assume Role Policy Brute Force - Rule action.escu.search_type = detection @@ -5991,11 +5947,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS IAM Assume Role Policy Brute Force - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 70, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580", "T1110"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f19e09b0-9308-11eb-b7ec-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f19e09b0-9308-11eb-b7ec-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing. +action.notable.param.rule_description = The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services. action.notable.param.rule_title = AWS IAM Assume Role Policy Brute Force action.notable.param.security_domain = access action.notable.param.severity = high @@ -6013,14 +5969,14 @@ search = `cloudtrail` (errorCode=MalformedPolicyDocumentException) status=failur [ESCU - AWS IAM Delete Policy - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy. +description = The following analytic detects the deletion of an IAM policy in AWS. It leverages AWS CloudTrail logs to identify `DeletePolicy` events, excluding those from AWS internal services. This activity is significant as unauthorized policy deletions can disrupt access controls and weaken security postures. If confirmed malicious, an attacker could remove critical security policies, potentially leading to privilege escalation, unauthorized access, or data exfiltration. Monitoring this behavior helps ensure that only authorized changes are made to IAM policies, maintaining the integrity and security of the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following detection identifies when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy. +action.escu.eli5 = The following analytic detects the deletion of an IAM policy in AWS. It leverages AWS CloudTrail logs to identify `DeletePolicy` events, excluding those from AWS internal services. This activity is significant as unauthorized policy deletions can disrupt access controls and weaken security postures. If confirmed malicious, an attacker could remove critical security policies, potentially leading to privilege escalation, unauthorized access, or data exfiltration. Monitoring this behavior helps ensure that only authorized changes are made to IAM policies, maintaining the integrity and security of the AWS environment. action.escu.how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only. -action.escu.creation_date = 2021-04-01 -action.escu.modification_date = 2021-04-01 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS IAM Delete Policy - Rule action.escu.search_type = detection @@ -6033,7 +5989,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS IAM Delete Policy - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 20, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ec3a9362-92fe-11eb-99d0-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ec3a9362-92fe-11eb-99d0-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6049,14 +6005,14 @@ search = `cloudtrail` eventName=DeletePolicy (userAgent!=*.amazonaws.com) | stat [ESCU - AWS IAM Failure Group Deletion - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection identifies failure attempts to delete groups. We want to identify when a group is attempting to be deleted, but either access is denied, there is a conflict or there is no group. This is indicative of administrators performing an action, but also could be suspicious behavior occurring. Review parallel IAM events - recently added users, new groups and so forth. +description = The following analytic identifies failed attempts to delete AWS IAM groups. It leverages AWS CloudTrail logs to detect events where the DeleteGroup action fails due to errors like NoSuchEntityException, DeleteConflictException, or AccessDenied. This activity is significant as it may indicate unauthorized attempts to modify IAM group configurations, which could be a precursor to privilege escalation or other malicious actions. If confirmed malicious, this could allow an attacker to disrupt IAM policies, potentially leading to unauthorized access or denial of service within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection identifies failure attempts to delete groups. We want to identify when a group is attempting to be deleted, but either access is denied, there is a conflict or there is no group. This is indicative of administrators performing an action, but also could be suspicious behavior occurring. Review parallel IAM events - recently added users, new groups and so forth. +action.escu.eli5 = The following analytic identifies failed attempts to delete AWS IAM groups. It leverages AWS CloudTrail logs to detect events where the DeleteGroup action fails due to errors like NoSuchEntityException, DeleteConflictException, or AccessDenied. This activity is significant as it may indicate unauthorized attempts to modify IAM group configurations, which could be a precursor to privilege escalation or other malicious actions. If confirmed malicious, this could allow an attacker to disrupt IAM policies, potentially leading to unauthorized access or denial of service within the AWS environment. action.escu.how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege). -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS IAM Failure Group Deletion - Rule action.escu.search_type = detection @@ -6074,7 +6030,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS IAM Failure Group Deletion - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 10, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "723b861a-92eb-11eb-93b8-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "723b861a-92eb-11eb-93b8-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6090,14 +6046,14 @@ search = `cloudtrail` eventSource=iam.amazonaws.com eventName=DeleteGroup errorC [ESCU - AWS IAM Successful Group Deletion - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following query uses IAM events to track the success of a group being deleted on AWS. This is typically not indicative of malicious behavior, but a precurser to additional events thay may unfold. Review parallel IAM events - recently added users, new groups and so forth. Inversely, review failed attempts in a similar manner. +description = The following analytic identifies the successful deletion of an IAM group in AWS. It leverages CloudTrail logs to detect `DeleteGroup` events with a success status. This activity is significant as it could indicate potential changes in user permissions or access controls, which may be a precursor to further unauthorized actions. If confirmed malicious, an attacker could disrupt access management, potentially leading to privilege escalation or unauthorized access to sensitive resources. Analysts should review related IAM events, such as recent user additions or new group creations, to assess the broader context. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1069.003", "T1098", "T1069"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following query uses IAM events to track the success of a group being deleted on AWS. This is typically not indicative of malicious behavior, but a precurser to additional events thay may unfold. Review parallel IAM events - recently added users, new groups and so forth. Inversely, review failed attempts in a similar manner. +action.escu.eli5 = The following analytic identifies the successful deletion of an IAM group in AWS. It leverages CloudTrail logs to detect `DeleteGroup` events with a success status. This activity is significant as it could indicate potential changes in user permissions or access controls, which may be a precursor to further unauthorized actions. If confirmed malicious, an attacker could disrupt access management, potentially leading to privilege escalation or unauthorized access to sensitive resources. Analysts should review related IAM events, such as recent user additions or new group creations, to assess the broader context. action.escu.how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege). -action.escu.creation_date = 2021-03-31 -action.escu.modification_date = 2021-03-31 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS IAM Successful Group Deletion - Rule action.escu.search_type = detection @@ -6110,7 +6066,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS IAM Successful Group Deletion - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 10, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1069.003", "T1098", "T1069"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e776d06c-9267-11eb-819b-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e776d06c-9267-11eb-819b-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6126,14 +6082,14 @@ search = `cloudtrail` eventSource=iam.amazonaws.com eventName=DeleteGroup errorC [ESCU - AWS Lambda UpdateFunctionCode - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is designed to detect IAM users attempting to update/modify AWS lambda code via the AWS CLI to gain persistence, futher access into your AWS environment and to facilitate planting backdoors. In this instance, an attacker may upload malicious code/binary to a lambda function which will be executed automatically when the funnction is triggered. +description = The following analytic identifies IAM users attempting to update or modify AWS Lambda code via the AWS CLI. It leverages CloudTrail logs to detect successful `UpdateFunctionCode` events initiated by IAM users. This activity is significant as it may indicate an attempt to gain persistence, further access, or plant backdoors within your AWS environment. If confirmed malicious, an attacker could upload and execute malicious code automatically when the Lambda function is triggered, potentially compromising the integrity and security of your AWS infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic is designed to detect IAM users attempting to update/modify AWS lambda code via the AWS CLI to gain persistence, futher access into your AWS environment and to facilitate planting backdoors. In this instance, an attacker may upload malicious code/binary to a lambda function which will be executed automatically when the funnction is triggered. +action.escu.eli5 = The following analytic identifies IAM users attempting to update or modify AWS Lambda code via the AWS CLI. It leverages CloudTrail logs to detect successful `UpdateFunctionCode` events initiated by IAM users. This activity is significant as it may indicate an attempt to gain persistence, further access, or plant backdoors within your AWS environment. If confirmed malicious, an attacker could upload and execute malicious code automatically when the Lambda function is triggered, potentially compromising the integrity and security of your AWS infrastructure. action.escu.how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin or an autorized IAM user has updated the lambda fuction code legitimately. -action.escu.creation_date = 2022-02-24 -action.escu.modification_date = 2022-02-24 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Lambda UpdateFunctionCode - Rule action.escu.search_type = detection @@ -6146,7 +6102,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Lambda UpdateFunctionCode - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Cloud User Activities"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "211b80d3-6340-4345-11ad-212bf3d0d111", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "211b80d3-6340-4345-11ad-212bf3d0d111", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6162,14 +6118,14 @@ search = `cloudtrail` eventSource=lambda.amazonaws.com eventName=UpdateFunctionC [ESCU - AWS Multi-Factor Authentication Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages AWS CloudTrail logs to identify events where MFA devices are deleted or deactivated. This activity is significant because disabling MFA can indicate an adversary attempting to weaken account security, potentially to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, posing a significant risk to the security and integrity of the cloud infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.escu.eli5 = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages AWS CloudTrail logs to identify events where MFA devices are deleted or deactivated. This activity is significant because disabling MFA can indicate an adversary attempting to weaken account security, potentially to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, posing a significant risk to the security and integrity of the cloud infrastructure. action.escu.how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company -action.escu.creation_date = 2022-10-04 -action.escu.modification_date = 2022-10-04 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Multi-Factor Authentication Disabled - Rule action.escu.search_type = detection @@ -6187,11 +6143,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Multi-Factor Authentication Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "374832b1-3603-420c-b456-b373e24d34c0", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "374832b1-3603-420c-b456-b373e24d34c0", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.notable.param.rule_description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages AWS CloudTrail logs to identify events where MFA devices are deleted or deactivated. This activity is significant because disabling MFA can indicate an adversary attempting to weaken account security, potentially to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, posing a significant risk to the security and integrity of the cloud infrastructure. action.notable.param.rule_title = AWS Multi-Factor Authentication Disabled action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6209,14 +6165,14 @@ search = `cloudtrail` (eventName= DeleteVirtualMFADevice OR eventName=Deactivate [ESCU - AWS Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies multiple failed multi-factor authentication requests to an AWS Console for a single user. AWS CloudTrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. AWS Environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests to an AWS Console for a single user. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect more than 10 failed MFA prompts within 5 minutes. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access to the AWS environment, potentially compromising sensitive data and resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication requests to an AWS Console for a single user. AWS CloudTrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. AWS Environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication (MFA) requests to an AWS Console for a single user. It leverages AWS CloudTrail logs, specifically the `additionalEventData` field, to detect more than 10 failed MFA prompts within 5 minutes. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access to the AWS environment, potentially compromising sensitive data and resources. action.escu.how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. -action.escu.creation_date = 2022-10-03 -action.escu.modification_date = 2022-10-03 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -6234,7 +6190,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1fece617-e614-4329-9e61-3ba228c0f353", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1fece617-e614-4329-9e61-3ba228c0f353", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6250,14 +6206,14 @@ search = `cloudtrail` eventName= ConsoleLogin "additionalEventData.MFAUsed"=Yes [ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source Ip failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment tenant to obtain initial access or elevate privileges. +description = The following analytic identifies a single source IP failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. It leverages CloudTrail logs to detect multiple failed login attempts from the same IP address. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain unauthorized access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source Ip failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment tenant to obtain initial access or elevate privileges. +action.escu.eli5 = The following analytic identifies a single source IP failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. It leverages CloudTrail logs to detect multiple failed login attempts from the same IP address. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain unauthorized access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. action.escu.how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment. action.escu.known_false_positives = No known false postives for this detection. Please review this alert -action.escu.creation_date = 2022-09-27 -action.escu.modification_date = 2022-09-27 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule action.escu.search_type = detection @@ -6275,7 +6231,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71e1fb89-dd5f-4691-8523-575420de4630", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71e1fb89-dd5f-4691-8523-575420de4630", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6286,7 +6242,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _time | stats dc(user_name) AS unique_accounts values(user_name) as tried_accounts by _time, src_ip |`aws_unusual_number_of_failed_authentications_from_ip_filter` +search = `cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _time | stats dc(user_name) AS unique_accounts values(user_name) as tried_accounts by _time, src_ip | `aws_multiple_users_failing_to_authenticate_from_ip_filter` [ESCU - AWS Network Access Control List Created with All Open Ports - Rule] action.escu = 0 @@ -6338,14 +6294,14 @@ search = `cloudtrail` eventName=CreateNetworkAclEntry OR eventName=ReplaceNetwor [ESCU - AWS Network Access Control List Deleted - Rule] action.escu = 0 action.escu.enabled = 1 -description = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the AWS console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the AWS CloudTrail logs to detect users deleting network ACLs. +description = The following analytic detects the deletion of AWS Network Access Control Lists (ACLs). It leverages AWS CloudTrail logs to identify events where a user deletes a network ACL entry. This activity is significant because deleting a network ACL can remove critical access restrictions, potentially allowing unauthorized access to cloud instances. If confirmed malicious, this action could enable attackers to bypass network security controls, leading to unauthorized access, data exfiltration, or further compromise of the cloud environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the AWS console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the AWS CloudTrail logs to detect users deleting network ACLs. +action.escu.eli5 = The following analytic detects the deletion of AWS Network Access Control Lists (ACLs). It leverages AWS CloudTrail logs to identify events where a user deletes a network ACL entry. This activity is significant because deleting a network ACL can remove critical access restrictions, potentially allowing unauthorized access to cloud instances. If confirmed malicious, this action could enable attackers to bypass network security controls, leading to unauthorized access, data exfiltration, or further compromise of the cloud environment. action.escu.how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. action.escu.known_false_positives = It's possible that a user has legitimately deleted a network ACL. -action.escu.creation_date = 2021-01-12 -action.escu.modification_date = 2021-01-12 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Network Access Control List Deleted - Rule action.escu.search_type = detection @@ -6363,7 +6319,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Network Access Control List Deleted - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Network ACL Activity"], "cis20": ["CIS 13"], "confidence": 50, "impact": 10, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ada0f478-84a8-4641-a3f1-d82362d6fd75", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ada0f478-84a8-4641-a3f1-d82362d6fd75", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6426,14 +6382,14 @@ search = `cloudtrail` eventName=CreateVirtualMFADevice | stats count values(req [ESCU - AWS Password Policy Changes - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events where a user is making successful API calls to view/update/delete the existing password policy in an AWS organization. It is unlikely for a regular user to conduct this operation. These events may potentially be malicious, adversaries often use this information to gain more understanding of the password defenses in place and exploit them to increase their attack surface when a user account is compromised. +description = The following analytic detects successful API calls to view, update, or delete the password policy in an AWS organization. It leverages AWS CloudTrail logs to identify events such as "UpdateAccountPasswordPolicy," "GetAccountPasswordPolicy," and "DeleteAccountPasswordPolicy." This activity is significant because it is uncommon for regular users to perform these actions, and such changes can indicate an adversary attempting to understand or weaken password defenses. If confirmed malicious, this could lead to compromised accounts and increased attack surface, potentially allowing unauthorized access and control over AWS resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events where a user is making successful API calls to view/update/delete the existing password policy in an AWS organization. It is unlikely for a regular user to conduct this operation. These events may potentially be malicious, adversaries often use this information to gain more understanding of the password defenses in place and exploit them to increase their attack surface when a user account is compromised. +action.escu.eli5 = The following analytic detects successful API calls to view, update, or delete the password policy in an AWS organization. It leverages AWS CloudTrail logs to identify events such as "UpdateAccountPasswordPolicy," "GetAccountPasswordPolicy," and "DeleteAccountPasswordPolicy." This activity is significant because it is uncommon for regular users to perform these actions, and such changes can indicate an adversary attempting to understand or weaken password defenses. If confirmed malicious, this could lead to compromised accounts and increased attack surface, potentially allowing unauthorized access and control over AWS resources. action.escu.how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately triggered an AWS audit tool activity which may trigger this event. -action.escu.creation_date = 2023-01-26 -action.escu.modification_date = 2023-01-26 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Password Policy Changes - Rule action.escu.search_type = detection @@ -6446,7 +6402,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Password Policy Changes - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 80, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "aee4a575-7064-4e60-b511-246f9baf9895", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "aee4a575-7064-4e60-b511-246f9baf9895", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6462,14 +6418,14 @@ search = `cloudtrail` eventName IN ("UpdateAccountPasswordPolicy","GetAccountPas [ESCU - AWS S3 Exfiltration Behavior Identified - Rule] action.escu = 0 action.escu.enabled = 1 -description = This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. +description = The following analytic identifies potential AWS S3 exfiltration behavior by correlating multiple risk events related to Collection and Exfiltration techniques. It leverages risk events from AWS sources, focusing on instances where two or more unique analytics and distinct MITRE ATT&CK IDs are triggered for a specific risk object. This activity is significant as it may indicate an ongoing data exfiltration attempt, which is critical for security teams to monitor. If confirmed malicious, this could lead to unauthorized access and theft of sensitive information, compromising the organization's data integrity and confidentiality. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. +action.escu.eli5 = The following analytic identifies potential AWS S3 exfiltration behavior by correlating multiple risk events related to Collection and Exfiltration techniques. It leverages risk events from AWS sources, focusing on instances where two or more unique analytics and distinct MITRE ATT&CK IDs are triggered for a specific risk object. This activity is significant as it may indicate an ongoing data exfiltration attempt, which is critical for security teams to monitor. If confirmed malicious, this could lead to unauthorized access and theft of sensitive information, compromising the organization's data integrity and confidentiality. action.escu.how_to_implement = You must enable all the detection searches in the Data Exfiltration Analytic story to create risk events in Enterprise Security. action.escu.known_false_positives = alse positives may be present based on automated tooling or system administrators. Filter as needed. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS S3 Exfiltration Behavior Identified - Rule action.escu.search_type = detection @@ -6482,11 +6438,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - RIR - AWS S3 Exfiltration Behavior Identified - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Suspicious Cloud Instance Activities"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"], "type": "Correlation"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "85096389-a443-42df-b89d-200efbb1b560", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "85096389-a443-42df-b89d-200efbb1b560", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information. +action.notable.param.rule_description = The following analytic identifies potential AWS S3 exfiltration behavior by correlating multiple risk events related to Collection and Exfiltration techniques. It leverages risk events from AWS sources, focusing on instances where two or more unique analytics and distinct MITRE ATT&CK IDs are triggered for a specific risk object. This activity is significant as it may indicate an ongoing data exfiltration attempt, which is critical for security teams to monitor. If confirmed malicious, this could lead to unauthorized access and theft of sensitive information, compromising the organization's data integrity and confidentiality. action.notable.param.rule_title = RBA: AWS S3 Exfiltration Behavior Identified action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6504,14 +6460,14 @@ search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_ [ESCU - AWS SAML Access by Provider User and Principal - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider. +description = The following analytic identifies specific SAML access events by a service provider, user, and targeted principal within AWS. It leverages AWS CloudTrail logs to detect the `AssumeRoleWithSAML` event, analyzing fields such as `principalArn`, `roleArn`, and `roleSessionName`. This activity is significant as it can indicate abnormal access patterns or potential credential hijacking, especially in federated environments using the SAML protocol. If confirmed malicious, this could allow attackers to assume roles and gain unauthorized access to sensitive AWS resources, leading to data breaches or further exploitation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider. +action.escu.eli5 = The following analytic identifies specific SAML access events by a service provider, user, and targeted principal within AWS. It leverages AWS CloudTrail logs to detect the `AssumeRoleWithSAML` event, analyzing fields such as `principalArn`, `roleArn`, and `roleSessionName`. This activity is significant as it can indicate abnormal access patterns or potential credential hijacking, especially in federated environments using the SAML protocol. If confirmed malicious, this could allow attackers to assume roles and gain unauthorized access to sensitive AWS resources, leading to data breaches or further exploitation. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs action.escu.known_false_positives = Attacks using a Golden SAML or SAML assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source IP sourceIPAddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks. -action.escu.creation_date = 2021-01-26 -action.escu.modification_date = 2021-01-26 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS SAML Access by Provider User and Principal - Rule action.escu.search_type = detection @@ -6529,7 +6485,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS SAML Access by Provider User and Principal - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Federated Credential Abuse"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bbe23980-6019-11eb-ae93-0242ac130002", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bbe23980-6019-11eb-ae93-0242ac130002", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6545,14 +6501,14 @@ search = `cloudtrail` eventName=Assumerolewithsaml | stats count min(_time) as f [ESCU - AWS SAML Update identity provider - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker. +description = The following analytic detects updates to the SAML provider in AWS. It leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. Monitoring updates to the SAML provider is crucial as it may indicate a perimeter compromise of federated credentials or unauthorized backdoor access set by an attacker. If confirmed malicious, this activity could allow attackers to manipulate identity federation, potentially leading to unauthorized access to cloud resources and sensitive data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker. +action.escu.eli5 = The following analytic detects updates to the SAML provider in AWS. It leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. Monitoring updates to the SAML provider is crucial as it may indicate a perimeter compromise of federated credentials or unauthorized backdoor access set by an attacker. If confirmed malicious, this activity could allow attackers to manipulate identity federation, potentially leading to unauthorized access to cloud resources and sensitive data. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = Updating a SAML provider or creating a new one may not necessarily be malicious however it needs to be closely monitored. -action.escu.creation_date = 2021-01-26 -action.escu.modification_date = 2021-01-26 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS SAML Update identity provider - Rule action.escu.search_type = detection @@ -6570,11 +6526,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS SAML Update identity provider - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Federated Credential Abuse"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2f0604c6-6030-11eb-ae93-0242ac130002", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2f0604c6-6030-11eb-ae93-0242ac130002", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker. +action.notable.param.rule_description = The following analytic detects updates to the SAML provider in AWS. It leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. Monitoring updates to the SAML provider is crucial as it may indicate a perimeter compromise of federated credentials or unauthorized backdoor access set by an attacker. If confirmed malicious, this activity could allow attackers to manipulate identity federation, potentially leading to unauthorized access to cloud resources and sensitive data. action.notable.param.rule_title = AWS SAML Update identity provider action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6592,14 +6548,14 @@ search = `cloudtrail` eventName=UpdateSAMLProvider | stats count min(_time) as f [ESCU - AWS SetDefaultPolicyVersion - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy +description = The following analytic detects when a user sets a default policy version in AWS. It leverages AWS CloudTrail logs to identify the `SetDefaultPolicyVersion` event from the IAM service. This activity is significant because attackers may exploit this technique for privilege escalation, especially if previous policy versions grant more extensive permissions than the current one. If confirmed malicious, this could allow an attacker to gain elevated access to AWS resources, potentially leading to unauthorized actions and data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy +action.escu.eli5 = The following analytic detects when a user sets a default policy version in AWS. It leverages AWS CloudTrail logs to identify the `SetDefaultPolicyVersion` event from the IAM service. This activity is significant because attackers may exploit this technique for privilege escalation, especially if previous policy versions grant more extensive permissions than the current one. If confirmed malicious, this could allow an attacker to gain elevated access to AWS resources, potentially leading to unauthorized actions and data breaches. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately set a default policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources -action.escu.creation_date = 2021-03-02 -action.escu.modification_date = 2021-03-02 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS SetDefaultPolicyVersion - Rule action.escu.search_type = detection @@ -6617,11 +6573,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS SetDefaultPolicyVersion - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf3d0dac4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6340-4345-11ad-212bf3d0dac4", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy +action.notable.param.rule_description = The following analytic detects when a user sets a default policy version in AWS. It leverages AWS CloudTrail logs to identify the `SetDefaultPolicyVersion` event from the IAM service. This activity is significant because attackers may exploit this technique for privilege escalation, especially if previous policy versions grant more extensive permissions than the current one. If confirmed malicious, this could allow an attacker to gain elevated access to AWS resources, potentially leading to unauthorized actions and data breaches. action.notable.param.rule_title = AWS SetDefaultPolicyVersion action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6639,14 +6595,14 @@ search = `cloudtrail` eventName=SetDefaultPolicyVersion eventSource = iam.amazon [ESCU - AWS Successful Console Authentication From Multiple IPs - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an AWS account successfully authenticating from more than one unique Ip address in the span of 5 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +description = The following analytic detects an AWS account successfully authenticating from multiple unique IP addresses within a 5-minute window. It leverages AWS CloudTrail logs, specifically monitoring `ConsoleLogin` events and counting distinct source IPs. This behavior is significant as it may indicate compromised credentials, potentially from a phishing attack, being used concurrently by an adversary and a legitimate user. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1535"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an AWS account successfully authenticating from more than one unique Ip address in the span of 5 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.escu.eli5 = The following analytic detects an AWS account successfully authenticating from multiple unique IP addresses within a 5-minute window. It leverages AWS CloudTrail logs, specifically monitoring `ConsoleLogin` events and counting distinct source IPs. This behavior is significant as it may indicate compromised credentials, potentially from a phishing attack, being used concurrently by an adversary and a legitimate user. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the AWS environment. action.escu.how_to_implement = You must install Splunk AWS add on and Splunk App for AWS. This search works when AWS CloudTrail events are normalized use the Authentication datamodel. action.escu.known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Successful Console Authentication From Multiple IPs - Rule action.escu.search_type = detection @@ -6664,7 +6620,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Successful Console Authentication From Multiple IPs - Rule action.correlationsearch.annotations = {"analytic_story": ["Compromised User Account", "Suspicious AWS Login Activities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 90, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1535"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "395e50e1-2b87-4fa3-8632-0dfbdcbcd2cb", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "395e50e1-2b87-4fa3-8632-0dfbdcbcd2cb", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6680,14 +6636,14 @@ search = `cloudtrail` eventName = ConsoleLogin | bin span=5m _time | stats valu [ESCU - AWS Successful Single-Factor Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a successful Console Login authentication event against an AWS IAM user for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account take over attempt that should be investigated +description = The following analytic identifies a successful Console Login authentication event for an AWS IAM user account without Multi-Factor Authentication (MFA) enabled. It leverages AWS CloudTrail logs to detect instances where MFA was not used during login. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the AWS environment, potentially leading to data exfiltration, resource manipulation, or further privilege escalation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies a successful Console Login authentication event against an AWS IAM user for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account take over attempt that should be investigated +action.escu.eli5 = The following analytic identifies a successful Console Login authentication event for an AWS IAM user account without Multi-Factor Authentication (MFA) enabled. It leverages AWS CloudTrail logs to detect instances where MFA was not used during login. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the AWS environment, potentially leading to data exfiltration, resource manipulation, or further privilege escalation. action.escu.how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs. action.escu.known_false_positives = It is possible that some accounts do not have MFA enabled for the AWS account however its agaisnt the best practices of securing AWS. -action.escu.creation_date = 2022-10-04 -action.escu.modification_date = 2022-10-04 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Successful Single-Factor Authentication - Rule action.escu.search_type = detection @@ -6705,11 +6661,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Successful Single-Factor Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a520b1fe-cc9e-4f56-b762-18354594c52f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a520b1fe-cc9e-4f56-b762-18354594c52f", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies a successful Console Login authentication event against an AWS IAM user for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account take over attempt that should be investigated +action.notable.param.rule_description = The following analytic identifies a successful Console Login authentication event for an AWS IAM user account without Multi-Factor Authentication (MFA) enabled. It leverages AWS CloudTrail logs to detect instances where MFA was not used during login. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the AWS environment, potentially leading to data exfiltration, resource manipulation, or further privilege escalation. action.notable.param.rule_title = AWS Successful Single-Factor Authentication action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6727,14 +6683,14 @@ search = `cloudtrail` eventName= ConsoleLogin errorCode=success "additionalEvent [ESCU - AWS Unusual Number of Failed Authentications From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source IP failing to authenticate into the AWS Console with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `AWS Multiple Users Failing To Authenticate From Ip`. +description = The following analytic identifies a single source IP failing to authenticate into the AWS Console with multiple valid users. It uses CloudTrail logs and calculates the standard deviation for source IP, leveraging the 3-sigma rule to detect unusual numbers of failed authentication attempts. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source IP failing to authenticate into the AWS Console with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `AWS Multiple Users Failing To Authenticate From Ip`. +action.escu.eli5 = The following analytic identifies a single source IP failing to authenticate into the AWS Console with multiple valid users. It uses CloudTrail logs and calculates the standard deviation for source IP, leveraging the 3-sigma rule to detect unusual numbers of failed authentication attempts. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or further exploitation within the AWS environment. action.escu.how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the calculation of the upperBound field to tune this search according to their environment action.escu.known_false_positives = No known false postives for this detection. Please review this alert -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS Unusual Number of Failed Authentications From Ip - Rule action.escu.search_type = detection @@ -6752,7 +6708,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS Unusual Number of Failed Authentications From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b5c9c2b-e2cb-4831-b4f1-af125ceb1386", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b5c9c2b-e2cb-4831-b4f1-af125ceb1386", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -6768,14 +6724,14 @@ search = `cloudtrail` eventName=ConsoleLogin action=failure | bucket span=10m _t [ESCU - AWS UpdateLoginProfile - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B) +description = The following analytic detects an AWS CloudTrail event where a user with permissions updates the login profile of another user. It leverages CloudTrail logs to identify instances where the user making the change is different from the user whose profile is being updated. This activity is significant because it can indicate privilege escalation attempts, where an attacker uses a compromised account to gain higher privileges. If confirmed malicious, this could allow the attacker to escalate their privileges, potentially leading to unauthorized access and control over sensitive resources within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B) +action.escu.eli5 = The following analytic detects an AWS CloudTrail event where a user with permissions updates the login profile of another user. It leverages CloudTrail logs to identify instances where the user making the change is different from the user whose profile is being updated. This activity is significant because it can indicate privilege escalation attempts, where an attacker uses a compromised account to gain higher privileges. If confirmed malicious, this could allow the attacker to escalate their privileges, potentially leading to unauthorized access and control over sensitive resources within the AWS environment. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. action.escu.known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user. -action.escu.creation_date = 2022-03-03 -action.escu.modification_date = 2022-03-03 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - AWS UpdateLoginProfile - Rule action.escu.search_type = detection @@ -6793,11 +6749,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AWS UpdateLoginProfile - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS IAM Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6a40-4115-11ad-212bf3d0d111", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2a9b80d3-6a40-4115-11ad-212bf3d0d111", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B) +action.notable.param.rule_description = The following analytic detects an AWS CloudTrail event where a user with permissions updates the login profile of another user. It leverages CloudTrail logs to identify instances where the user making the change is different from the user whose profile is being updated. This activity is significant because it can indicate privilege escalation attempts, where an attacker uses a compromised account to gain higher privileges. If confirmed malicious, this could allow the attacker to escalate their privileges, potentially leading to unauthorized access and control over sensitive resources within the AWS environment. action.notable.param.rule_title = AWS UpdateLoginProfile action.notable.param.security_domain = threat action.notable.param.severity = high @@ -6815,14 +6771,14 @@ search = `cloudtrail` eventName = UpdateLoginProfile userAgent !=console.amazon [ESCU - Azure Active Directory High Risk Sign-in - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic triggers on a high risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them in three categories high, medium and low. +description = The following analytic detects high-risk sign-in attempts against Azure Active Directory, identified by Azure Identity Protection. It leverages the RiskyUsers and UserRiskEvents log categories from Azure AD events ingested via EventHub. This activity is significant as it indicates potentially compromised accounts, flagged by heuristics and machine learning. If confirmed malicious, attackers could gain unauthorized access to sensitive resources, leading to data breaches or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003"], "nist": ["DE.CM"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The following analytic triggers on a high risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them in three categories high, medium and low. +action.escu.eli5 = The following analytic detects high-risk sign-in attempts against Azure Active Directory, identified by Azure Identity Protection. It leverages the RiskyUsers and UserRiskEvents log categories from Azure AD events ingested via EventHub. This activity is significant as it indicates potentially compromised accounts, flagged by heuristics and machine learning. If confirmed malicious, attackers could gain unauthorized access to sensitive resources, leading to data breaches or further exploitation within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category in the azure:monitor:aad sourcetype. action.escu.known_false_positives = Details for the risk calculation algorithm used by Identity Protection are unknown and may be prone to false positives. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure Active Directory High Risk Sign-in - Rule action.escu.search_type = detection @@ -6840,11 +6796,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure Active Directory High Risk Sign-in - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1ecff169-26d7-4161-9a7b-2ac4c8e61bea", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1ecff169-26d7-4161-9a7b-2ac4c8e61bea", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic triggers on a high risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them in three categories high, medium and low. +action.notable.param.rule_description = The following analytic detects high-risk sign-in attempts against Azure Active Directory, identified by Azure Identity Protection. It leverages the RiskyUsers and UserRiskEvents log categories from Azure AD events ingested via EventHub. This activity is significant as it indicates potentially compromised accounts, flagged by heuristics and machine learning. If confirmed malicious, attackers could gain unauthorized access to sensitive resources, leading to data breaches or further exploitation within the environment. action.notable.param.rule_title = Azure Active Directory High Risk Sign-in action.notable.param.security_domain = identity action.notable.param.severity = high @@ -6862,14 +6818,14 @@ search = `azure_monitor_aad` category=UserRiskEvents properties.riskLevel=high [ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight. +description = The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight. +action.escu.eli5 = The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category action.escu.known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. -action.escu.creation_date = 2024-02-09 -action.escu.modification_date = 2024-02-09 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule action.escu.search_type = detection @@ -6887,11 +6843,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Privilege Escalation", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d4fea43-9182-4c5a-ada8-13701fd5615d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d4fea43-9182-4c5a-ada8-13701fd5615d", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight. +action.notable.param.rule_description = The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment. action.notable.param.rule_title = Azure AD Admin Consent Bypassed by Service Principal action.notable.param.security_domain = identity action.notable.param.severity = high @@ -6909,14 +6865,14 @@ search = `azure_monitor_aad` operationName="Add app role assignment to service p [ESCU - Azure AD Application Administrator Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant. +description = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. It leverages Azure Active Directory events, specifically monitoring the "Add member to role" operation. This activity is significant because users in this role can manage all aspects of enterprise applications, including credentials, which can be used to impersonate application identities. If confirmed malicious, an attacker could escalate privileges, manage application settings, and potentially access sensitive resources by impersonating application identities, posing a significant security risk to the Azure AD tenant. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant. +action.escu.eli5 = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. It leverages Azure Active Directory events, specifically monitoring the "Add member to role" operation. This activity is significant because users in this role can manage all aspects of enterprise applications, including credentials, which can be used to impersonate application identities. If confirmed malicious, an attacker could escalate privileges, manage application settings, and potentially access sensitive resources by impersonating application identities, posing a significant security risk to the Azure AD tenant. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category action.escu.known_false_positives = Administrators may legitimately assign the Application Administrator role to a user. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Application Administrator Role Assigned - Rule action.escu.search_type = detection @@ -6934,11 +6890,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Application Administrator Role Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eac4de87-7a56-4538-a21b-277897af6d8d", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eac4de87-7a56-4538-a21b-277897af6d8d", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant. +action.notable.param.rule_description = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. It leverages Azure Active Directory events, specifically monitoring the "Add member to role" operation. This activity is significant because users in this role can manage all aspects of enterprise applications, including credentials, which can be used to impersonate application identities. If confirmed malicious, an attacker could escalate privileges, manage application settings, and potentially access sensitive resources by impersonating application identities, posing a significant security risk to the Azure AD tenant. action.notable.param.rule_title = Azure AD Application Administrator Role Assigned action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -6956,14 +6912,14 @@ search = `azure_monitor_aad` "operationName"="Add member to role" "properties [ESCU - Azure AD Authentication Failed During MFA Challenge - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an authentication attempt event against an Azure AD tenant that fails during the Multi Factor Authentication challenge. Error Code 500121 represents a failed attempt to authenticate using a second factor. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +description = The following analytic identifies failed authentication attempts against an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically flagged by error code 500121. It leverages Azure AD SignInLogs to detect these events. This activity is significant as it may indicate an adversary attempting to authenticate using compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing effort to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an authentication attempt event against an Azure AD tenant that fails during the Multi Factor Authentication challenge. Error Code 500121 represents a failed attempt to authenticate using a second factor. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.escu.eli5 = The following analytic identifies failed authentication attempts against an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically flagged by error code 500121. It leverages Azure AD SignInLogs to detect these events. This activity is significant as it may indicate an adversary attempting to authenticate using compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing effort to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Authentication Failed During MFA Challenge - Rule action.escu.search_type = detection @@ -6981,11 +6937,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Authentication Failed During MFA Challenge - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e62c9c2e-bf51-4719-906c-3074618fcc1c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e62c9c2e-bf51-4719-906c-3074618fcc1c", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an authentication attempt event against an Azure AD tenant that fails during the Multi Factor Authentication challenge. Error Code 500121 represents a failed attempt to authenticate using a second factor. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.notable.param.rule_description = The following analytic identifies failed authentication attempts against an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically flagged by error code 500121. It leverages Azure AD SignInLogs to detect these events. This activity is significant as it may indicate an adversary attempting to authenticate using compromised credentials on an account with MFA enabled. If confirmed malicious, this could suggest an ongoing effort to bypass MFA protections, potentially leading to unauthorized access and further compromise of the affected account. action.notable.param.rule_title = Azure AD Authentication Failed During MFA Challenge action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7003,14 +6959,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50 [ESCU - Azure AD Block User Consent For Risky Apps Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization +description = The following analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats by allowing users to grant consent to potentially malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization +action.escu.eli5 = The following analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats by allowing users to grant consent to potentially malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Block User Consent For Risky Apps Disabled - Rule action.escu.search_type = detection @@ -7028,11 +6984,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Block User Consent For Risky Apps Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "875de3d7-09bc-4916-8c0a-0929f4ced3d8", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "875de3d7-09bc-4916-8c0a-0929f4ced3d8", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization +action.notable.param.rule_description = The following analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats by allowing users to grant consent to potentially malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.notable.param.rule_title = Azure AD Block User Consent For Risky Apps Disabled action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7050,14 +7006,14 @@ search = `azure_monitor_aad` operationName="Update authorization policy" | renam [ESCU - Azure AD Concurrent Sessions From Different Ips - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an Azure AD account with concurrent sessions coming from more than one unique Ip address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +description = The following analytic detects an Azure AD account with concurrent sessions originating from multiple unique IP addresses within a 5-minute window. It leverages Azure Active Directory NonInteractiveUserSignInLogs to identify this behavior by analyzing successful authentication events and counting distinct source IPs per user. This activity is significant as it may indicate session hijacking, where an attacker uses stolen session cookies to access corporate resources from a different location. If confirmed malicious, this could lead to unauthorized access to sensitive information and potential data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an Azure AD account with concurrent sessions coming from more than one unique Ip address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.escu.eli5 = The following analytic detects an Azure AD account with concurrent sessions originating from multiple unique IP addresses within a 5-minute window. It leverages Azure Active Directory NonInteractiveUserSignInLogs to identify this behavior by analyzing successful authentication events and counting distinct source IPs per user. This activity is significant as it may indicate session hijacking, where an attacker uses stolen session cookies to access corporate resources from a different location. If confirmed malicious, this could lead to unauthorized access to sensitive information and potential data breaches. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Concurrent Sessions From Different Ips - Rule action.escu.search_type = detection @@ -7075,11 +7031,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Concurrent Sessions From Different Ips - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9126f73-9a9b-493d-96ec-0dd06695490d", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9126f73-9a9b-493d-96ec-0dd06695490d", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an Azure AD account with concurrent sessions coming from more than one unique Ip address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.notable.param.rule_description = The following analytic detects an Azure AD account with concurrent sessions originating from multiple unique IP addresses within a 5-minute window. It leverages Azure Active Directory NonInteractiveUserSignInLogs to identify this behavior by analyzing successful authentication events and counting distinct source IPs per user. This activity is significant as it may indicate session hijacking, where an attacker uses stolen session cookies to access corporate resources from a different location. If confirmed malicious, this could lead to unauthorized access to sensitive information and potential data breaches. action.notable.param.rule_title = Azure AD Concurrent Sessions From Different Ips action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7097,14 +7053,14 @@ search = `azure_monitor_aad` properties.authenticationDetails{}.succeeded=true [ESCU - Azure AD Device Code Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the execution of the Azure Device Code Phishing attack, which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically focusing on authentication requests to identify the attack. This technique involves creating malicious infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. +description = The following analytic identifies Azure Device Code Phishing attacks, which can lead to Azure Account Take-Over (ATO). It leverages Azure AD SignInLogs to detect suspicious authentication requests using the device code authentication protocol. This activity is significant as it indicates potential bypassing of Multi-Factor Authentication (MFA) and Conditional Access Policies (CAPs) through phishing emails. If confirmed malicious, attackers could gain unauthorized access to Azure AD, Exchange mailboxes, and Outlook Web Application (OWA), leading to potential data breaches and unauthorized data access. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1528", "T1566", "T1566.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the execution of the Azure Device Code Phishing attack, which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically focusing on authentication requests to identify the attack. This technique involves creating malicious infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. +action.escu.eli5 = The following analytic identifies Azure Device Code Phishing attacks, which can lead to Azure Account Take-Over (ATO). It leverages Azure AD SignInLogs to detect suspicious authentication requests using the device code authentication protocol. This activity is significant as it indicates potential bypassing of Multi-Factor Authentication (MFA) and Conditional Access Policies (CAPs) through phishing emails. If confirmed malicious, attackers could gain unauthorized access to Azure AD, Exchange mailboxes, and Outlook Web Application (OWA), leading to potential data breaches and unauthorized data access. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = In most organizations, device code authentication will be used to access common Microsoft service but it may be legitimate for others. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Device Code Authentication - Rule action.escu.search_type = detection @@ -7122,11 +7078,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Device Code Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1528", "T1566", "T1566.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d68d8732-6f7e-4ee5-a6eb-737f2b990b91", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d68d8732-6f7e-4ee5-a6eb-737f2b990b91", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the execution of the Azure Device Code Phishing attack, which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically focusing on authentication requests to identify the attack. This technique involves creating malicious infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. +action.notable.param.rule_description = The following analytic identifies Azure Device Code Phishing attacks, which can lead to Azure Account Take-Over (ATO). It leverages Azure AD SignInLogs to detect suspicious authentication requests using the device code authentication protocol. This activity is significant as it indicates potential bypassing of Multi-Factor Authentication (MFA) and Conditional Access Policies (CAPs) through phishing emails. If confirmed malicious, attackers could gain unauthorized access to Azure AD, Exchange mailboxes, and Outlook Web Application (OWA), leading to potential data breaches and unauthorized data access. action.notable.param.rule_title = Azure AD Device Code Authentication action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7144,14 +7100,14 @@ search = `azure_monitor_aad` category=SignInLogs "properties.authenticationProto [ESCU - Azure AD External Guest User Invited - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the invitation of an external guest user within Azure AD. With Azure AD B2B collaboration, users and administrators can invite external users to collaborate with internal users. External guest account invitations should be monitored by security teams as they could potentially lead to unauthorized access. An example of this attack vector was described at BlackHat 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking Azure AD Accounts by Abusing External Identities` +description = The following analytic detects the invitation of an external guest user within Azure AD. It leverages Azure AD AuditLogs to identify events where an external user is invited, using fields such as operationName and initiatedBy. Monitoring these invitations is crucial as they can lead to unauthorized access if abused. If confirmed malicious, this activity could allow attackers to gain access to internal resources, potentially leading to data breaches or further exploitation of the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the invitation of an external guest user within Azure AD. With Azure AD B2B collaboration, users and administrators can invite external users to collaborate with internal users. External guest account invitations should be monitored by security teams as they could potentially lead to unauthorized access. An example of this attack vector was described at BlackHat 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking Azure AD Accounts by Abusing External Identities` +action.escu.eli5 = The following analytic detects the invitation of an external guest user within Azure AD. It leverages Azure AD AuditLogs to identify events where an external user is invited, using fields such as operationName and initiatedBy. Monitoring these invitations is crucial as they can lead to unauthorized access if abused. If confirmed malicious, this activity could allow attackers to gain access to internal resources, potentially leading to data breaches or further exploitation of the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Administrator may legitimately invite external guest users. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD External Guest User Invited - Rule action.escu.search_type = detection @@ -7169,11 +7125,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD External Guest User Invited - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c1fb4edb-cab1-4359-9b40-925ffd797fb5", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c1fb4edb-cab1-4359-9b40-925ffd797fb5", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the invitation of an external guest user within Azure AD. With Azure AD B2B collaboration, users and administrators can invite external users to collaborate with internal users. External guest account invitations should be monitored by security teams as they could potentially lead to unauthorized access. An example of this attack vector was described at BlackHat 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking Azure AD Accounts by Abusing External Identities` +action.notable.param.rule_description = The following analytic detects the invitation of an external guest user within Azure AD. It leverages Azure AD AuditLogs to identify events where an external user is invited, using fields such as operationName and initiatedBy. Monitoring these invitations is crucial as they can lead to unauthorized access if abused. If confirmed malicious, this activity could allow attackers to gain access to internal resources, potentially leading to data breaches or further exploitation of the environment. action.notable.param.rule_title = Azure AD External Guest User Invited action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7191,14 +7147,14 @@ search = `azure_monitor_aad` operationName="Invite external user" | rename prope [ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited. +description = The following analytic detects the assignment of the 'full_access_as_app' permission to an application within Office 365 Exchange Online. This is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. The detection leverages the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This activity is significant as it grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. If malicious, this could lead to unauthorized access and data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited. +action.escu.eli5 = The following analytic detects the assignment of the 'full_access_as_app' permission to an application within Office 365 Exchange Online. This is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. The detection leverages the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This activity is significant as it grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. If malicious, this could lead to unauthorized access and data exfiltration. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. -action.escu.creation_date = 2024-01-29 -action.escu.modification_date = 2024-01-29 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule action.escu.search_type = detection @@ -7216,11 +7172,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ae286126-f2ad-421c-b240-4ea83bd1c43a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ae286126-f2ad-421c-b240-4ea83bd1c43a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited. +action.notable.param.rule_description = The following analytic detects the assignment of the 'full_access_as_app' permission to an application within Office 365 Exchange Online. This is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. The detection leverages the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This activity is significant as it grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. If malicious, this could lead to unauthorized access and data exfiltration. action.notable.param.rule_title = Azure AD FullAccessAsApp Permission Assigned action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7238,14 +7194,14 @@ search = `azure_monitor_aad` category=AuditLogs operationName="Update applicatio [ESCU - Azure AD Global Administrator Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the Azure AD Global Administrator role to an Azure AD user. The Global Administrator role is the most powerful administrator role in Azure AD and provides almost unlimited access to data, resources and settings. It is equivalent to the Domain Administrator group in an Active Directory environment. While Azure AD roles do not grant access to Azure services and resources, it is possible for a Global Administrator account to gain control of Azure resources. Adversaries and red teams alike may assign this role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment. +description = The following analytic detects the assignment of the Azure AD Global Administrator role to a user. It leverages Azure Active Directory AuditLogs to identify when the "Add member to role" operation includes the "Global Administrator" role. This activity is significant because the Global Administrator role grants extensive access to data, resources, and settings, similar to a Domain Administrator in traditional AD environments. If confirmed malicious, this could allow an attacker to establish persistence, escalate privileges, and potentially gain control over Azure resources, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of the Azure AD Global Administrator role to an Azure AD user. The Global Administrator role is the most powerful administrator role in Azure AD and provides almost unlimited access to data, resources and settings. It is equivalent to the Domain Administrator group in an Active Directory environment. While Azure AD roles do not grant access to Azure services and resources, it is possible for a Global Administrator account to gain control of Azure resources. Adversaries and red teams alike may assign this role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment. +action.escu.eli5 = The following analytic detects the assignment of the Azure AD Global Administrator role to a user. It leverages Azure Active Directory AuditLogs to identify when the "Add member to role" operation includes the "Global Administrator" role. This activity is significant because the Global Administrator role grants extensive access to data, resources, and settings, similar to a Domain Administrator in traditional AD environments. If confirmed malicious, this could allow an attacker to establish persistence, escalate privileges, and potentially gain control over Azure resources, posing a severe security risk. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Administrators may legitimately assign the Global Administrator role to a user. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Global Administrator Role Assigned - Rule action.escu.search_type = detection @@ -7263,11 +7219,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Global Administrator Role Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "Azure Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "825fed20-309d-4fd1-8aaf-cd49c1bb093c", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "825fed20-309d-4fd1-8aaf-cd49c1bb093c", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the Azure AD Global Administrator role to an Azure AD user. The Global Administrator role is the most powerful administrator role in Azure AD and provides almost unlimited access to data, resources and settings. It is equivalent to the Domain Administrator group in an Active Directory environment. While Azure AD roles do not grant access to Azure services and resources, it is possible for a Global Administrator account to gain control of Azure resources. Adversaries and red teams alike may assign this role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment. +action.notable.param.rule_description = The following analytic detects the assignment of the Azure AD Global Administrator role to a user. It leverages Azure Active Directory AuditLogs to identify when the "Add member to role" operation includes the "Global Administrator" role. This activity is significant because the Global Administrator role grants extensive access to data, resources, and settings, similar to a Domain Administrator in traditional AD environments. If confirmed malicious, this could allow an attacker to establish persistence, escalate privileges, and potentially gain control over Azure resources, posing a severe security risk. action.notable.param.rule_title = Azure AD Global Administrator Role Assigned action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7285,14 +7241,14 @@ search = `azure_monitor_aad` operationName="Add member to role" properties.tar [ESCU - Azure AD High Number Of Failed Authentications For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an Azure AD account with more than 20 failed authentication events in the span of 10 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +description = The following analytic identifies an Azure AD account experiencing more than 20 failed authentication attempts within a 10-minute window. This detection leverages Azure SignInLogs data, specifically monitoring for error code 50126 and unsuccessful authentication attempts. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, an attacker could potentially gain unauthorized access, leading to data breaches or further exploitation within the environment. Security teams should adjust the threshold based on their specific environment to reduce false positives. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an Azure AD account with more than 20 failed authentication events in the span of 10 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +action.escu.eli5 = The following analytic identifies an Azure AD account experiencing more than 20 failed authentication attempts within a 10-minute window. This detection leverages Azure SignInLogs data, specifically monitoring for error code 50126 and unsuccessful authentication attempts. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, an attacker could potentially gain unauthorized access, leading to data breaches or further exploitation within the environment. Security teams should adjust the threshold based on their specific environment to reduce false positives. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD High Number Of Failed Authentications For User - Rule action.escu.search_type = detection @@ -7310,11 +7266,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD High Number Of Failed Authentications For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "630b1694-210a-48ee-a450-6f79e7679f2c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "630b1694-210a-48ee-a450-6f79e7679f2c", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an Azure AD account with more than 20 failed authentication events in the span of 10 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection. +action.notable.param.rule_description = The following analytic identifies an Azure AD account experiencing more than 20 failed authentication attempts within a 10-minute window. This detection leverages Azure SignInLogs data, specifically monitoring for error code 50126 and unsuccessful authentication attempts. This behavior is significant as it may indicate a brute force attack targeting the account. If confirmed malicious, an attacker could potentially gain unauthorized access, leading to data breaches or further exploitation within the environment. Security teams should adjust the threshold based on their specific environment to reduce false positives. action.notable.param.rule_title = Azure AD High Number Of Failed Authentications For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7332,14 +7288,14 @@ search = `azure_monitor_aad` category= SignInLogs properties.status.errorCode=5 [ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an Ip address failing to authenticate 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could represent a brute force attack againstan Azure AD to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +description = The following analytic detects an IP address with 20 or more failed authentication attempts to an Azure AD tenant within 10 minutes. It leverages Azure AD SignInLogs to identify repeated failed logins from the same IP. This behavior is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges. If confirmed malicious, the attacker could potentially compromise user accounts, leading to unauthorized access to sensitive information and resources within the Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an Ip address failing to authenticate 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could represent a brute force attack againstan Azure AD to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +action.escu.eli5 = The following analytic detects an IP address with 20 or more failed authentication attempts to an Azure AD tenant within 10 minutes. It leverages Azure AD SignInLogs to identify repeated failed logins from the same IP. This behavior is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges. If confirmed malicious, the attacker could potentially compromise user accounts, leading to unauthorized access to sensitive information and resources within the Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 10 minutes may also be triggered by a broken application. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule action.escu.search_type = detection @@ -7357,11 +7313,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "Compromised User Account", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e5ab41bf-745d-4f72-a393-2611151afd8e", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e5ab41bf-745d-4f72-a393-2611151afd8e", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an Ip address failing to authenticate 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could represent a brute force attack againstan Azure AD to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection. +action.notable.param.rule_description = The following analytic detects an IP address with 20 or more failed authentication attempts to an Azure AD tenant within 10 minutes. It leverages Azure AD SignInLogs to identify repeated failed logins from the same IP. This behavior is significant as it may indicate a brute force attack aimed at gaining unauthorized access or escalating privileges. If confirmed malicious, the attacker could potentially compromise user accounts, leading to unauthorized access to sensitive information and resources within the Azure environment. action.notable.param.rule_title = Azure AD High Number Of Failed Authentications From Ip action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7379,14 +7335,14 @@ search = `azure_monitor_aad` category= SignInLogs properties.status.errorCode=5 [ESCU - Azure AD Multi-Factor Authentication Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an attempt to disable multi-factor authentication for an Azure AD user. An adversary who has obtained access to an Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an Azure AD user. It leverages Azure Active Directory AuditLogs to identify the "Disable Strong Authentication" operation. This activity is significant because disabling MFA can allow adversaries to maintain persistence using compromised accounts without raising suspicion. If confirmed malicious, this action could enable attackers to bypass an essential security control, potentially leading to unauthorized access and prolonged undetected presence in the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = The following analytic identifies an attempt to disable multi-factor authentication for an Azure AD user. An adversary who has obtained access to an Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.escu.eli5 = The following analytic detects attempts to disable multi-factor authentication (MFA) for an Azure AD user. It leverages Azure Active Directory AuditLogs to identify the "Disable Strong Authentication" operation. This activity is significant because disabling MFA can allow adversaries to maintain persistence using compromised accounts without raising suspicion. If confirmed malicious, this action could enable attackers to bypass an essential security control, potentially leading to unauthorized access and prolonged undetected presence in the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multi-Factor Authentication Disabled - Rule action.escu.search_type = detection @@ -7404,11 +7360,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multi-Factor Authentication Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "482dd42a-acfa-486b-a0bb-d6fcda27318e", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "482dd42a-acfa-486b-a0bb-d6fcda27318e", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an attempt to disable multi-factor authentication for an Azure AD user. An adversary who has obtained access to an Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.notable.param.rule_description = The following analytic detects attempts to disable multi-factor authentication (MFA) for an Azure AD user. It leverages Azure Active Directory AuditLogs to identify the "Disable Strong Authentication" operation. This activity is significant because disabling MFA can allow adversaries to maintain persistence using compromised accounts without raising suspicion. If confirmed malicious, this action could enable attackers to bypass an essential security control, potentially leading to unauthorized access and prolonged undetected presence in the environment. action.notable.param.rule_title = Azure AD Multi-Factor Authentication Disabled action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7426,14 +7382,14 @@ search = `azure_monitor_aad` category=AuditLogs operationName="Disable Strong Au [ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure. +description = The following analytic detects potential distributed password spraying attacks in an Azure AD environment. It identifies a spike in failed authentication attempts across various user-and-IP combinations from multiple source IPs and countries, using different user agents. This detection leverages Azure AD SignInLogs, focusing on error code 50126 for failed authentications. This activity is significant as it indicates an adversary's attempt to bypass security controls by distributing login attempts. If confirmed malicious, this could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization's infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure. +action.escu.eli5 = The following analytic detects potential distributed password spraying attacks in an Azure AD environment. It identifies a spike in failed authentication attempts across various user-and-IP combinations from multiple source IPs and countries, using different user agents. This detection leverages Azure AD SignInLogs, focusing on error code 50126 for failed authentications. This activity is significant as it indicates an adversary's attempt to bypass security controls by distributing login attempts. If confirmed malicious, this could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization's infrastructure. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. action.escu.known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule action.escu.search_type = detection @@ -7446,7 +7402,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "116e11a9-63ea-41eb-a66a-6a13bdc7d2c7", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "116e11a9-63ea-41eb-a66a-6a13bdc7d2c7", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -7462,14 +7418,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50 [ESCU - Azure AD Multiple AppIDs and UserAgents Authentication Spike - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +description = The following analytic detects unusual authentication activity in Azure AD, specifically when a single user account has over 8 authentication attempts using 3+ unique application IDs and 5+ unique user agents within a short period. It leverages Azure AD audit logs, focusing on authentication events and using statistical thresholds. This behavior is significant as it may indicate an adversary probing for MFA requirements. If confirmed malicious, it suggests a compromised account, potentially leading to further exploitation, lateral movement, and data exfiltration. Early detection is crucial to prevent substantial harm. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +action.escu.eli5 = The following analytic detects unusual authentication activity in Azure AD, specifically when a single user account has over 8 authentication attempts using 3+ unique application IDs and 5+ unique user agents within a short period. It leverages Azure AD audit logs, focusing on authentication events and using statistical thresholds. This behavior is significant as it may indicate an adversary probing for MFA requirements. If confirmed malicious, it suggests a compromised account, potentially leading to further exploitation, lateral movement, and data exfiltration. Early detection is crucial to prevent substantial harm. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple AppIDs and UserAgents Authentication Spike - Rule action.escu.search_type = detection @@ -7487,7 +7443,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple AppIDs and UserAgents Authentication Spike - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5d8bb1f0-f65a-4b4e-af2e-fcdb88276314", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5d8bb1f0-f65a-4b4e-af2e-fcdb88276314", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -7503,14 +7459,14 @@ search = `azure_monitor_aad` category=SignInLogs operationName="Sign-in activit [ESCU - Azure AD Multiple Denied MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +description = The following analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. It leverages Azure Active Directory (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 and additional details indicating "MFA denied; user declined the authentication." This behavior is significant as it may indicate a targeted attack or account compromise attempt, with the user actively declining unauthorized access. If confirmed malicious, it could lead to data exfiltration, lateral movement, or further malicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +action.escu.eli5 = The following analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. It leverages Azure Active Directory (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 and additional details indicating "MFA denied; user declined the authentication." This behavior is significant as it may indicate a targeted attack or account compromise attempt, with the user actively declining unauthorized access. If confirmed malicious, it could lead to data exfiltration, lateral movement, or further malicious activities. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = Multiple denifed MFA requests in a short period of span may also be a sign of authentication errors. Investigate and filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple Denied MFA Requests For User - Rule action.escu.search_type = detection @@ -7528,11 +7484,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple Denied MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d0895c20-de71-4fd2-b56c-3fcdb888eba1", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d0895c20-de71-4fd2-b56c-3fcdb888eba1", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +action.notable.param.rule_description = The following analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. It leverages Azure Active Directory (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 and additional details indicating "MFA denied; user declined the authentication." This behavior is significant as it may indicate a targeted attack or account compromise attempt, with the user actively declining unauthorized access. If confirmed malicious, it could lead to data exfiltration, lateral movement, or further malicious activities. action.notable.param.rule_title = Azure AD Multiple Denied MFA Requests For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7550,14 +7506,14 @@ search = `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity [ESCU - Azure AD Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Azure AD tenant. It leverages Azure AD Sign-in Logs, specifically error code 500121, to detect more than 10 failed MFA attempts within 10 minutes. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication prompts. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise user accounts and potentially escalate their privileges within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Azure AD tenant. It leverages Azure AD Sign-in Logs, specifically error code 500121, to detect more than 10 failed MFA attempts within 10 minutes. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication prompts. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise user accounts and potentially escalate their privileges within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -7575,11 +7531,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "264ea131-ab1f-41b8-90e0-33ad1a1888ea", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "264ea131-ab1f-41b8-90e0-33ad1a1888ea", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.notable.param.rule_description = The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Azure AD tenant. It leverages Azure AD Sign-in Logs, specifically error code 500121, to detect more than 10 failed MFA attempts within 10 minutes. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication prompts. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise user accounts and potentially escalate their privileges within the environment. action.notable.param.rule_title = Azure AD Multiple Failed MFA Requests For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7592,19 +7548,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication" | rename properties.* as * | bucket span=10m _time | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent | where count > 9 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_multiple_failed_mfa_requests_for_user_filter` +search = `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication" | rename properties.* as * | bucket span=10m _time | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent | where count > 10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_multiple_failed_mfa_requests_for_user_filter` [ESCU - Azure AD Multiple Service Principals Created by SP - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection identifies when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span, potentially signaling malicious activity. It monitors the 'Add service principal' operation, focusing on the activity of service principals rather than individual users. By aggregating the creation events over a 10-minute period, the analytic tracks how many distinct OAuth applications are created by each service principal. This is key for SOC teams to pinpoint potential attack staging, where an attacker might use a compromised or malicious service principal to rapidly establish multiple service principals, facilitating network infiltration or expansion. While the default threshold is set to trigger on more than three applications, security teams should adjust this to fit their specific environment's norm +description = The following analytic detects when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span. It leverages Azure AD audit logs, specifically monitoring the 'Add service principal' operation initiated by service principals. This behavior is significant as it may indicate an attacker using a compromised or malicious service principal to rapidly establish multiple service principals, potentially staging an attack. If confirmed malicious, this activity could facilitate network infiltration or expansion, allowing the attacker to gain unauthorized access and persist within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection identifies when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span, potentially signaling malicious activity. It monitors the 'Add service principal' operation, focusing on the activity of service principals rather than individual users. By aggregating the creation events over a 10-minute period, the analytic tracks how many distinct OAuth applications are created by each service principal. This is key for SOC teams to pinpoint potential attack staging, where an attacker might use a compromised or malicious service principal to rapidly establish multiple service principals, facilitating network infiltration or expansion. While the default threshold is set to trigger on more than three applications, security teams should adjust this to fit their specific environment's norm +action.escu.eli5 = The following analytic detects when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span. It leverages Azure AD audit logs, specifically monitoring the 'Add service principal' operation initiated by service principals. This behavior is significant as it may indicate an attacker using a compromised or malicious service principal to rapidly establish multiple service principals, potentially staging an attack. If confirmed malicious, this activity could facilitate network infiltration or expansion, allowing the attacker to gain unauthorized access and persist within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-02-07 -action.escu.modification_date = 2024-02-07 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple Service Principals Created by SP - Rule action.escu.search_type = detection @@ -7622,7 +7578,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple Service Principals Created by SP - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "66cb378f-234d-4fe1-bb4c-e7878ff6b017", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "66cb378f-234d-4fe1-bb4c-e7878ff6b017", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -7638,14 +7594,14 @@ search = `azure_monitor_aad` operationName="Add service principal" properties.i [ESCU - Azure AD Multiple Service Principals Created by User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection focuses on identifying instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD, a potential indicator of malicious activity. By monitoring the 'Add service principal' operation and aggregating the data with a 10-minute bucket span, it tracks the number of distinct OAuth applications created by each user. This analytic is crucial for SOC teams to detect possible staging of attacks, where an adversary might rapidly create multiple service principals as part of their infiltration or expansion strategy within the network. The threshold of three applications is set to flag unusual behavior, but security teams are advised to adjust this value to suit the normal operational patterns of their environment +description = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD. It detects this activity by monitoring the 'Add service principal' operation and aggregating data in 10-minute intervals. This behavior is significant as it may indicate an adversary rapidly creating multiple service principals to stage an attack or expand their foothold within the network. If confirmed malicious, this activity could allow attackers to establish persistence, escalate privileges, or access sensitive information within the Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection focuses on identifying instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD, a potential indicator of malicious activity. By monitoring the 'Add service principal' operation and aggregating the data with a 10-minute bucket span, it tracks the number of distinct OAuth applications created by each user. This analytic is crucial for SOC teams to detect possible staging of attacks, where an adversary might rapidly create multiple service principals as part of their infiltration or expansion strategy within the network. The threshold of three applications is set to flag unusual behavior, but security teams are advised to adjust this value to suit the normal operational patterns of their environment +action.escu.eli5 = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD. It detects this activity by monitoring the 'Add service principal' operation and aggregating data in 10-minute intervals. This behavior is significant as it may indicate an adversary rapidly creating multiple service principals to stage an attack or expand their foothold within the network. If confirmed malicious, this activity could allow attackers to establish persistence, escalate privileges, or access sensitive information within the Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-02-07 -action.escu.modification_date = 2024-02-07 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple Service Principals Created by User - Rule action.escu.search_type = detection @@ -7663,7 +7619,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple Service Principals Created by User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "32880707-f512-414e-bd7f-204c0c85b758", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "32880707-f512-414e-bd7f-204c0c85b758", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -7679,16 +7635,14 @@ search = `azure_monitor_aad` operationName="Add service principal" properties.i [ESCU - Azure AD Multiple Users Failing To Authenticate From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source Ip failing to authenticate with 30 unique valid users within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -Azure AD tenants can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold if needed. +description = The following analytic detects a single source IP failing to authenticate with 30 unique valid users within 5 minutes in Azure Active Directory. It leverages Azure AD SignInLogs with error code 50126, indicating invalid passwords. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or privilege escalation within the Azure AD environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source Ip failing to authenticate with 30 unique valid users within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -Azure AD tenants can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold if needed. +action.escu.eli5 = The following analytic detects a single source IP failing to authenticate with 30 unique valid users within 5 minutes in Azure Active Directory. It leverages Azure AD SignInLogs with error code 50126, indicating invalid passwords. This behavior is significant as it may indicate a Password Spraying attack, where an adversary attempts to gain initial access or elevate privileges by trying common passwords across many accounts. If confirmed malicious, this activity could lead to unauthorized access, data breaches, or privilege escalation within the Azure AD environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Multiple Users Failing To Authenticate From Ip - Rule action.escu.search_type = detection @@ -7706,7 +7660,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Multiple Users Failing To Authenticate From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "94481a6a-8f59-4c86-957f-55a71e3612a6", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "94481a6a-8f59-4c86-957f-55a71e3612a6", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -7722,14 +7676,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.status.errorCode=5 [ESCU - Azure AD New Custom Domain Added - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of a new custom domain within an Azure Active Directory tenant. Adding a custom domain is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +description = The following analytic detects the addition of a new custom domain within an Azure Active Directory (AD) tenant. It leverages Azure AD AuditLogs to identify successful "Add unverified domain" operations. This activity is significant as it may indicate an adversary attempting to establish persistence by setting up identity federation backdoors, allowing them to impersonate users and bypass authentication mechanisms. If confirmed malicious, this could enable attackers to gain unauthorized access, escalate privileges, and maintain long-term access to the Azure AD environment, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of a new custom domain within an Azure Active Directory tenant. Adding a custom domain is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.escu.eli5 = The following analytic detects the addition of a new custom domain within an Azure Active Directory (AD) tenant. It leverages Azure AD AuditLogs to identify successful "Add unverified domain" operations. This activity is significant as it may indicate an adversary attempting to establish persistence by setting up identity federation backdoors, allowing them to impersonate users and bypass authentication mechanisms. If confirmed malicious, this could enable attackers to gain unauthorized access, escalate privileges, and maintain long-term access to the Azure AD environment, posing a severe security risk. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = In most organizations, new customm domains will be updated infrequently. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD New Custom Domain Added - Rule action.escu.search_type = detection @@ -7747,11 +7701,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD New Custom Domain Added - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "30c47f45-dd6a-4720-9963-0bca6c8686ef", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "30c47f45-dd6a-4720-9963-0bca6c8686ef", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of a new custom domain within an Azure Active Directory tenant. Adding a custom domain is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.notable.param.rule_description = The following analytic detects the addition of a new custom domain within an Azure Active Directory (AD) tenant. It leverages Azure AD AuditLogs to identify successful "Add unverified domain" operations. This activity is significant as it may indicate an adversary attempting to establish persistence by setting up identity federation backdoors, allowing them to impersonate users and bypass authentication mechanisms. If confirmed malicious, this could enable attackers to gain unauthorized access, escalate privileges, and maintain long-term access to the Azure AD environment, posing a severe security risk. action.notable.param.rule_title = Azure AD New Custom Domain Added action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7769,14 +7723,14 @@ search = `azure_monitor_aad` operationName="Add unverified domain" properties. [ESCU - Azure AD New Federated Domain Added - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of a new federated domain within an Azure Active Directory tenant. This event could represent the execution of the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +description = The following analytic detects the addition of a new federated domain within an Azure Active Directory tenant. It leverages Azure AD AuditLogs to identify successful "Set domain authentication" operations. This activity is significant as it may indicate the use of the Azure AD identity federation backdoor technique, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, potentially leading to unauthorized access and control over the Azure AD environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of a new federated domain within an Azure Active Directory tenant. This event could represent the execution of the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.escu.eli5 = The following analytic detects the addition of a new federated domain within an Azure Active Directory tenant. It leverages Azure AD AuditLogs to identify successful "Set domain authentication" operations. This activity is significant as it may indicate the use of the Azure AD identity federation backdoor technique, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, potentially leading to unauthorized access and control over the Azure AD environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = In most organizations, domain federation settings will be updated infrequently. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD New Federated Domain Added - Rule action.escu.search_type = detection @@ -7794,11 +7748,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD New Federated Domain Added - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a87cd633-076d-4ab2-9047-977751a3c1a0", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a87cd633-076d-4ab2-9047-977751a3c1a0", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of a new federated domain within an Azure Active Directory tenant. This event could represent the execution of the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.notable.param.rule_description = The following analytic detects the addition of a new federated domain within an Azure Active Directory tenant. It leverages Azure AD AuditLogs to identify successful "Set domain authentication" operations. This activity is significant as it may indicate the use of the Azure AD identity federation backdoor technique, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, potentially leading to unauthorized access and control over the Azure AD environment. action.notable.param.rule_title = Azure AD New Federated Domain Added action.notable.param.security_domain = threat action.notable.param.severity = high @@ -7816,14 +7770,14 @@ search = `azure_monitor_aad` operationName="Set domain authentication" "proper [ESCU - Azure AD New MFA Method Registered - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account in Azure Active Directory. It leverages Azure AD audit logs to identify changes in MFA configurations. This activity is significant because adding a new MFA method can indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges, access sensitive data, or make unauthorized changes. Immediate verification and remediation are required to secure the affected account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +action.escu.eli5 = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account in Azure Active Directory. It leverages Azure AD audit logs to identify changes in MFA configurations. This activity is significant because adding a new MFA method can indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges, access sensitive data, or make unauthorized changes. Immediate verification and remediation are required to secure the affected account. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD New MFA Method Registered - Rule action.escu.search_type = detection @@ -7841,11 +7795,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD New MFA Method Registered - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 50, "impact": 60, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0488e814-eb81-42c3-9f1f-b2244973e3a3", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0488e814-eb81-42c3-9f1f-b2244973e3a3", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +action.notable.param.rule_description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account in Azure Active Directory. It leverages Azure AD audit logs to identify changes in MFA configurations. This activity is significant because adding a new MFA method can indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges, access sensitive data, or make unauthorized changes. Immediate verification and remediation are required to secure the affected account. action.notable.param.rule_title = Azure AD New MFA Method Registered action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7863,14 +7817,14 @@ search = `azure_monitor_aad` operationName="Update user" | rename properties.* [ESCU - Azure AD New MFA Method Registered For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the registration of a new Multi Factor authentication method for an Azure AD account. Adversaries who have obtained unauthorized access to an Azure AD account may register a new MFA method to maintain persistence. +description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs to identify when a user registers new security information. This activity is significant because adversaries who gain unauthorized access to an account may add their own MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security controls, maintain long-term access, and potentially escalate their privileges within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the registration of a new Multi Factor authentication method for an Azure AD account. Adversaries who have obtained unauthorized access to an Azure AD account may register a new MFA method to maintain persistence. +action.escu.eli5 = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs to identify when a user registers new security information. This activity is significant because adversaries who gain unauthorized access to an account may add their own MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security controls, maintain long-term access, and potentially escalate their privileges within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category. action.escu.known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD New MFA Method Registered For User - Rule action.escu.search_type = detection @@ -7888,11 +7842,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD New MFA Method Registered For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2628b087-4189-403f-9044-87403f777a1b", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2628b087-4189-403f-9044-87403f777a1b", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the registration of a new Multi Factor authentication method for an Azure AD account. Adversaries who have obtained unauthorized access to an Azure AD account may register a new MFA method to maintain persistence. +action.notable.param.rule_description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs to identify when a user registers new security information. This activity is significant because adversaries who gain unauthorized access to an account may add their own MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security controls, maintain long-term access, and potentially escalate their privileges within the environment. action.notable.param.rule_title = Azure AD New MFA Method Registered For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7910,14 +7864,14 @@ search = `azure_monitor_aad` category=AuditLogs operationName="User registered [ESCU - Azure AD OAuth Application Consent Granted By User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. +description = The following analytic detects when a user in an Azure AD environment grants consent to an OAuth application. It leverages Azure AD audit logs to identify events where users approve application consents. This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access. If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. +action.escu.eli5 = The following analytic detects when a user in an Azure AD environment grants consent to an OAuth application. It leverages Azure AD audit logs to identify events where users approve application consents. This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access. If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = False positives may occur if users are granting consents as part of legitimate application integrations or setups. It is crucial to review the application and the permissions it requests to ensure they align with organizational policies and security best practices. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD OAuth Application Consent Granted By User - Rule action.escu.search_type = detection @@ -7935,11 +7889,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD OAuth Application Consent Granted By User - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10ec9031-015b-4617-b453-c0c1ab729007", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10ec9031-015b-4617-b453-c0c1ab729007", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. +action.notable.param.rule_description = The following analytic detects when a user in an Azure AD environment grants consent to an OAuth application. It leverages Azure AD audit logs to identify events where users approve application consents. This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access. If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks. action.notable.param.rule_title = Azure AD OAuth Application Consent Granted By User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -7957,14 +7911,14 @@ search = `azure_monitor_aad` operationName="Consent to application" properties.r [ESCU - Azure AD PIM Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +description = The following analytic detects the assignment of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user is added as an eligible member to a PIM role. This activity is significant because PIM roles grant elevated privileges, and their assignment should be closely monitored to prevent unauthorized access. If confirmed malicious, an attacker could exploit this to gain privileged access, potentially leading to unauthorized actions, data breaches, or further compromise of the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +action.escu.eli5 = The following analytic detects the assignment of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user is added as an eligible member to a PIM role. This activity is significant because PIM roles grant elevated privileges, and their assignment should be closely monitored to prevent unauthorized access. If confirmed malicious, an attacker could exploit this to gain privileged access, potentially leading to unauthorized actions, data breaches, or further compromise of the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = As part of legitimate administrative behavior, users may be assigned PIM roles. Filter as needed -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD PIM Role Assigned - Rule action.escu.search_type = detection @@ -7982,11 +7936,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD PIM Role Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "Azure Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fcd6dfeb-191c-46a0-a29c-c306382145ab", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fcd6dfeb-191c-46a0-a29c-c306382145ab", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +action.notable.param.rule_description = The following analytic detects the assignment of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user is added as an eligible member to a PIM role. This activity is significant because PIM roles grant elevated privileges, and their assignment should be closely monitored to prevent unauthorized access. If confirmed malicious, an attacker could exploit this to gain privileged access, potentially leading to unauthorized actions, data breaches, or further compromise of the environment. action.notable.param.rule_title = Azure AD PIM Role Assigned action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8004,14 +7958,14 @@ search = `azure_monitor_aad` operationName="Add eligible member to role in PIM [ESCU - Azure AD PIM Role Assignment Activated - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +description = The following analytic detects the activation of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user activates a PIM role assignment, indicated by the "Add member to role completed (PIM activation)" operation. Monitoring this activity is crucial as PIM roles grant elevated privileges, and unauthorized activation could indicate an adversary attempting to gain privileged access. If confirmed malicious, this could lead to unauthorized administrative actions, data breaches, or further compromise of the Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +action.escu.eli5 = The following analytic detects the activation of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user activates a PIM role assignment, indicated by the "Add member to role completed (PIM activation)" operation. Monitoring this activity is crucial as PIM roles grant elevated privileges, and unauthorized activation could indicate an adversary attempting to gain privileged access. If confirmed malicious, this could lead to unauthorized administrative actions, data breaches, or further compromise of the Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD PIM Role Assignment Activated - Rule action.escu.search_type = detection @@ -8029,11 +7983,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD PIM Role Assignment Activated - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "Azure Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "952e80d0-e343-439b-83f4-808c3e6fbf2e", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "952e80d0-e343-439b-83f4-808c3e6fbf2e", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy. +action.notable.param.rule_description = The following analytic detects the activation of an Azure AD Privileged Identity Management (PIM) role. It leverages Azure Active Directory events to identify when a user activates a PIM role assignment, indicated by the "Add member to role completed (PIM activation)" operation. Monitoring this activity is crucial as PIM roles grant elevated privileges, and unauthorized activation could indicate an adversary attempting to gain privileged access. If confirmed malicious, this could lead to unauthorized administrative actions, data breaches, or further compromise of the Azure environment. action.notable.param.rule_title = Azure AD PIM Role Assignment Activated action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8051,14 +8005,14 @@ search = `azure_monitor_aad` operationName="Add member to role completed (PIM a [ESCU - Azure AD Privileged Authentication Administrator Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. Red teams and adversaries alike may abuse this role to escalate their privileges. +description = The following analytic detects the assignment of the Privileged Authentication Administrator role to an Azure AD user. It leverages Azure Active Directory audit logs to identify when this specific role is assigned. This activity is significant because users in this role can set or reset authentication methods for any user, including those in privileged roles like Global Administrators. If confirmed malicious, an attacker could change credentials and assume the identity and permissions of high-privilege users, potentially leading to unauthorized access to sensitive information and critical configurations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. Red teams and adversaries alike may abuse this role to escalate their privileges. +action.escu.eli5 = The following analytic detects the assignment of the Privileged Authentication Administrator role to an Azure AD user. It leverages Azure Active Directory audit logs to identify when this specific role is assigned. This activity is significant because users in this role can set or reset authentication methods for any user, including those in privileged roles like Global Administrators. If confirmed malicious, an attacker could change credentials and assume the identity and permissions of high-privilege users, potentially leading to unauthorized access to sensitive information and critical configurations. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Administrators may legitimately assign the Privileged Authentication Administrator role as part of administrative tasks. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Privileged Authentication Administrator Role Assigned - Rule action.escu.search_type = detection @@ -8076,11 +8030,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Privileged Authentication Administrator Role Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 100, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a7da845d-6fae-41cf-b823-6c0b8c55814a", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a7da845d-6fae-41cf-b823-6c0b8c55814a", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. Red teams and adversaries alike may abuse this role to escalate their privileges. +action.notable.param.rule_description = The following analytic detects the assignment of the Privileged Authentication Administrator role to an Azure AD user. It leverages Azure Active Directory audit logs to identify when this specific role is assigned. This activity is significant because users in this role can set or reset authentication methods for any user, including those in privileged roles like Global Administrators. If confirmed malicious, an attacker could change credentials and assume the identity and permissions of high-privilege users, potentially leading to unauthorized access to sensitive information and critical configurations. action.notable.param.rule_title = Azure AD Privileged Authentication Administrator Role Assigned action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8098,14 +8052,14 @@ search = `azure_monitor_aad` "operationName"="Add member to role" "properties [ESCU - Azure AD Privileged Graph API Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches. +description = The following analytic detects the assignment of high-risk Graph API permissions in Azure AD, specifically Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. It uses azure_monitor_aad data to scan AuditLogs for 'Update application' operations, identifying when these permissions are assigned. This activity is significant as it grants broad control over Azure AD, including application and directory settings. If confirmed malicious, it could lead to unauthorized modifications and potential security breaches, compromising the integrity and security of the Azure AD environment. Immediate investigation is required. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches. +action.escu.eli5 = The following analytic detects the assignment of high-risk Graph API permissions in Azure AD, specifically Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. It uses azure_monitor_aad data to scan AuditLogs for 'Update application' operations, identifying when these permissions are assigned. This activity is significant as it grants broad control over Azure AD, including application and directory settings. If confirmed malicious, it could lead to unauthorized modifications and potential security breaches, compromising the integrity and security of the Azure AD environment. Immediate investigation is required. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-01-30 -action.escu.modification_date = 2024-01-30 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Privileged Graph API Permission Assigned - Rule action.escu.search_type = detection @@ -8123,11 +8077,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Privileged Graph API Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 60, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5521f8c5-1aa3-473c-9eb7-853701924a06", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5521f8c5-1aa3-473c-9eb7-853701924a06", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches. +action.notable.param.rule_description = The following analytic detects the assignment of high-risk Graph API permissions in Azure AD, specifically Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. It uses azure_monitor_aad data to scan AuditLogs for 'Update application' operations, identifying when these permissions are assigned. This activity is significant as it grants broad control over Azure AD, including application and directory settings. If confirmed malicious, it could lead to unauthorized modifications and potential security breaches, compromising the integrity and security of the Azure AD environment. Immediate investigation is required. action.notable.param.rule_title = Azure AD Privileged Graph API Permission Assigned action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8145,14 +8099,14 @@ search = `azure_monitor_aad` category=AuditLogs operationName="Update applicatio [ESCU - Azure AD Privileged Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment. +description = The following analytic detects the assignment of privileged Azure Active Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring the "Add member to role" operation. This activity is significant as adversaries may assign privileged roles to compromised accounts to maintain persistence within the Azure AD environment. If confirmed malicious, this could allow attackers to escalate privileges, access sensitive information, and maintain long-term control over the Azure AD infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment. +action.escu.eli5 = The following analytic detects the assignment of privileged Azure Active Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring the "Add member to role" operation. This activity is significant as adversaries may assign privileged roles to compromised accounts to maintain persistence within the Azure AD environment. If confirmed malicious, this could allow attackers to escalate privileges, access sensitive information, and maintain long-term control over the Azure AD infrastructure. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Administrators will legitimately assign the privileged roles users as part of administrative tasks. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Privileged Role Assigned - Rule action.escu.search_type = detection @@ -8174,7 +8128,7 @@ action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a28f0bc schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment. +action.notable.param.rule_description = The following analytic detects the assignment of privileged Azure Active Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring the "Add member to role" operation. This activity is significant as adversaries may assign privileged roles to compromised accounts to maintain persistence within the Azure AD environment. If confirmed malicious, this could allow attackers to escalate privileges, access sensitive information, and maintain long-term control over the Azure AD infrastructure. action.notable.param.rule_title = Azure AD Privileged Role Assigned action.notable.param.security_domain = audit action.notable.param.severity = high @@ -8192,14 +8146,14 @@ search = `azure_monitor_aad` "operationName"="Add member to role" | rename pro [ESCU - Azure AD Privileged Role Assigned to Service Principal - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. +description = The following analytic detects the assignment of privileged roles to service principals in Azure Active Directory (AD). It leverages the AuditLogs log category from ingested Azure AD events. This activity is significant because assigning elevated permissions to non-human entities can lead to unauthorized access or malicious activities. If confirmed malicious, attackers could exploit these service principals to gain elevated access to Azure resources, potentially compromising sensitive data and critical infrastructure. Monitoring this behavior helps prevent privilege escalation and ensures the security of Azure environments. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. +action.escu.eli5 = The following analytic detects the assignment of privileged roles to service principals in Azure Active Directory (AD). It leverages the AuditLogs log category from ingested Azure AD events. This activity is significant because assigning elevated permissions to non-human entities can lead to unauthorized access or malicious activities. If confirmed malicious, attackers could exploit these service principals to gain elevated access to Azure resources, potentially compromising sensitive data and critical infrastructure. Monitoring this behavior helps prevent privilege escalation and ensures the security of Azure environments. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Administrators may legitimately assign the privileged roles to Service Principals as part of administrative tasks. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Privileged Role Assigned to Service Principal - Rule action.escu.search_type = detection @@ -8221,7 +8175,7 @@ action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5dfaa3d schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. +action.notable.param.rule_description = The following analytic detects the assignment of privileged roles to service principals in Azure Active Directory (AD). It leverages the AuditLogs log category from ingested Azure AD events. This activity is significant because assigning elevated permissions to non-human entities can lead to unauthorized access or malicious activities. If confirmed malicious, attackers could exploit these service principals to gain elevated access to Azure resources, potentially compromising sensitive data and critical infrastructure. Monitoring this behavior helps prevent privilege escalation and ensures the security of Azure environments. action.notable.param.rule_title = Azure AD Privileged Role Assigned to Service Principal action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8239,14 +8193,14 @@ search = `azure_monitor_aad` operationName="Add member to role" | rename prope [ESCU - Azure AD Service Principal Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities. +description = The following analytic identifies authentication events of service principals in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring these events is significant for SOC teams to distinguish between normal application authentication and potential anomalies, which could indicate compromised credentials or malicious activities. If confirmed malicious, attackers could gain unauthorized access to resources, leading to data breaches or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities. +action.escu.eli5 = The following analytic identifies authentication events of service principals in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring these events is significant for SOC teams to distinguish between normal application authentication and potential anomalies, which could indicate compromised credentials or malicious activities. If confirmed malicious, attackers could gain unauthorized access to resources, leading to data breaches or further exploitation within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = Service Principals will legitimally authenticate remotely to your tenant. Implementing this detection after establishing a baseline enables a more accurate identification of security threats, ensuring proactive and informed responses to safeguard the Azure AD environment. source ips. -action.escu.creation_date = 2024-02-12 -action.escu.modification_date = 2024-02-12 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Service Principal Authentication - Rule action.escu.search_type = detection @@ -8264,11 +8218,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Service Principal Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5a2ec401-60bb-474e-b936-1e66e7aa4060", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5a2ec401-60bb-474e-b936-1e66e7aa4060", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities. +action.notable.param.rule_description = The following analytic identifies authentication events of service principals in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring these events is significant for SOC teams to distinguish between normal application authentication and potential anomalies, which could indicate compromised credentials or malicious activities. If confirmed malicious, attackers could gain unauthorized access to resources, leading to data breaches or further exploitation within the environment. action.notable.param.rule_title = Azure AD Service Principal Authentication action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8286,14 +8240,14 @@ search = `azure_monitor_aad` operationName="Sign-in activity" category=ServiceP [ESCU - Azure AD Service Principal Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the creation of a Service Principal in an Azure AD environment. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may create a Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. +description = The following analytic detects the creation of a Service Principal in an Azure AD environment. It leverages Azure Active Directory events ingested through EventHub, specifically monitoring the "Add service principal" operation. This activity is significant because Service Principals can be used by adversaries to establish persistence and bypass multi-factor authentication and conditional access policies. If confirmed malicious, this could allow attackers to maintain single-factor access to the Azure AD environment, potentially leading to unauthorized access to resources and prolonged undetected activity. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the creation of a Service Principal in an Azure AD environment. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may create a Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. +action.escu.eli5 = The following analytic detects the creation of a Service Principal in an Azure AD environment. It leverages Azure Active Directory events ingested through EventHub, specifically monitoring the "Add service principal" operation. This activity is significant because Service Principals can be used by adversaries to establish persistence and bypass multi-factor authentication and conditional access policies. If confirmed malicious, this could allow attackers to maintain single-factor access to the Azure AD environment, potentially leading to unauthorized access to resources and prolonged undetected activity. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment thorough an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Administrator may legitimately create Service Principal. Filter as needed. -action.escu.creation_date = 2022-08-17 -action.escu.modification_date = 2022-08-17 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Service Principal Created - Rule action.escu.search_type = detection @@ -8311,11 +8265,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Service Principal Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f8ba49e7-ffd3-4b53-8f61-e73974583c5d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f8ba49e7-ffd3-4b53-8f61-e73974583c5d", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the creation of a Service Principal in an Azure AD environment. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may create a Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. +action.notable.param.rule_description = The following analytic detects the creation of a Service Principal in an Azure AD environment. It leverages Azure Active Directory events ingested through EventHub, specifically monitoring the "Add service principal" operation. This activity is significant because Service Principals can be used by adversaries to establish persistence and bypass multi-factor authentication and conditional access policies. If confirmed malicious, this could allow attackers to maintain single-factor access to the Azure AD environment, potentially leading to unauthorized access to resources and prolonged undetected activity. action.notable.param.rule_title = Azure AD Service Principal Created action.notable.param.security_domain = threat action.notable.param.severity = high @@ -8333,14 +8287,14 @@ search = `azure_monitor_aad` operationName="Add service principal" properties.i [ESCU - Azure AD Service Principal New Client Credentials - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of new credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 certificates and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries and red teams alike who have obtained privileged access to Azure AD may add credentials to Service Principals to maintain persistent access to victim accounts and other instances within the Azure environment. By compromising an account who is an Owner of an application with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and logging in as the service principal. +description = The following analytic detects the addition of new credentials to Service Principals and Applications in Azure AD. It leverages Azure AD AuditLogs, specifically monitoring the "Update application*Certificates and secrets management" operation. This activity is significant as it may indicate an adversary attempting to maintain persistent access or escalate privileges within the Azure environment. If confirmed malicious, attackers could use these new credentials to log in as the service principal, potentially compromising sensitive accounts and resources, leading to unauthorized access and control over the Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of new credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 certificates and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries and red teams alike who have obtained privileged access to Azure AD may add credentials to Service Principals to maintain persistent access to victim accounts and other instances within the Azure environment. By compromising an account who is an Owner of an application with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and logging in as the service principal. +action.escu.eli5 = The following analytic detects the addition of new credentials to Service Principals and Applications in Azure AD. It leverages Azure AD AuditLogs, specifically monitoring the "Update application*Certificates and secrets management" operation. This activity is significant as it may indicate an adversary attempting to maintain persistent access or escalate privileges within the Azure environment. If confirmed malicious, attackers could use these new credentials to log in as the service principal, potentially compromising sensitive accounts and resources, leading to unauthorized access and control over the Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Service Principal New Client Credentials - Rule action.escu.search_type = detection @@ -8358,11 +8312,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Service Principal New Client Credentials - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "Azure Active Directory Privilege Escalation", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3adc0d3-9e4b-4b5d-b662-12cec1adff2a", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3adc0d3-9e4b-4b5d-b662-12cec1adff2a", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of new credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 certificates and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries and red teams alike who have obtained privileged access to Azure AD may add credentials to Service Principals to maintain persistent access to victim accounts and other instances within the Azure environment. By compromising an account who is an Owner of an application with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and logging in as the service principal. +action.notable.param.rule_description = The following analytic detects the addition of new credentials to Service Principals and Applications in Azure AD. It leverages Azure AD AuditLogs, specifically monitoring the "Update application*Certificates and secrets management" operation. This activity is significant as it may indicate an adversary attempting to maintain persistent access or escalate privileges within the Azure environment. If confirmed malicious, attackers could use these new credentials to log in as the service principal, potentially compromising sensitive accounts and resources, leading to unauthorized access and control over the Azure environment. action.notable.param.rule_title = Azure AD Service Principal New Client Credentials action.notable.param.security_domain = threat action.notable.param.severity = high @@ -8380,14 +8334,14 @@ search = `azure_monitor_aad` category=AuditLogs operationName="Update applicat [ESCU - Azure AD Service Principal Owner Added - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of a new owner for a Service Principal within an Azure AD tenant. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may add a new owner for an existing Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. Attackers who are looking to escalate their privileges by leveraging a Service Principals permissions may also add a new owner. +description = The following analytic detects the addition of a new owner to a Service Principal within an Azure AD tenant. It leverages Azure Active Directory events from the AuditLog log category to identify this activity. This behavior is significant because Service Principals do not support multi-factor authentication or conditional access policies, making them a target for adversaries seeking persistence or privilege escalation. If confirmed malicious, this activity could allow attackers to maintain access to the Azure AD environment with single-factor authentication, potentially leading to unauthorized access and control over critical resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of a new owner for a Service Principal within an Azure AD tenant. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may add a new owner for an existing Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. Attackers who are looking to escalate their privileges by leveraging a Service Principals permissions may also add a new owner. +action.escu.eli5 = The following analytic detects the addition of a new owner to a Service Principal within an Azure AD tenant. It leverages Azure Active Directory events from the AuditLog log category to identify this activity. This behavior is significant because Service Principals do not support multi-factor authentication or conditional access policies, making them a target for adversaries seeking persistence or privilege escalation. If confirmed malicious, this activity could allow attackers to maintain access to the Azure AD environment with single-factor authentication, potentially leading to unauthorized access and control over critical resources. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = Administrator may legitimately add new owners for Service Principals. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Service Principal Owner Added - Rule action.escu.search_type = detection @@ -8405,11 +8359,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Service Principal Owner Added - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "Azure Active Directory Privilege Escalation", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7ddf2084-6cf3-4a44-be83-474f7b73c701", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7ddf2084-6cf3-4a44-be83-474f7b73c701", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of a new owner for a Service Principal within an Azure AD tenant. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may add a new owner for an existing Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. Attackers who are looking to escalate their privileges by leveraging a Service Principals permissions may also add a new owner. +action.notable.param.rule_description = The following analytic detects the addition of a new owner to a Service Principal within an Azure AD tenant. It leverages Azure Active Directory events from the AuditLog log category to identify this activity. This behavior is significant because Service Principals do not support multi-factor authentication or conditional access policies, making them a target for adversaries seeking persistence or privilege escalation. If confirmed malicious, this activity could allow attackers to maintain access to the Azure AD environment with single-factor authentication, potentially leading to unauthorized access and control over critical resources. action.notable.param.rule_title = Azure AD Service Principal Owner Added action.notable.param.security_domain = audit action.notable.param.severity = high @@ -8427,14 +8381,14 @@ search = `azure_monitor_aad` operationName="Add owner to application" | rename [ESCU - Azure AD Successful Authentication From Different Ips - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an Azure AD account successfully authenticating from more than one unique Ip address in the span of 30 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +description = The following analytic detects an Azure AD account successfully authenticating from multiple unique IP addresses within a 30-minute window. It leverages Azure AD SignInLogs to identify instances where the same user logs in from different IPs in a short time frame. This behavior is significant as it may indicate compromised credentials being used by an adversary, potentially following a phishing attack. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an Azure AD account successfully authenticating from more than one unique Ip address in the span of 30 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.escu.eli5 = The following analytic detects an Azure AD account successfully authenticating from multiple unique IP addresses within a 30-minute window. It leverages Azure AD SignInLogs to identify instances where the same user logs in from different IPs in a short time frame. This behavior is significant as it may indicate compromised credentials being used by an adversary, potentially following a phishing attack. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the network. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Successful Authentication From Different Ips - Rule action.escu.search_type = detection @@ -8452,11 +8406,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Successful Authentication From Different Ips - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover", "Compromised User Account"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "be6d868d-33b6-4aaa-912e-724fb555b11a", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "be6d868d-33b6-4aaa-912e-724fb555b11a", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an Azure AD account successfully authenticating from more than one unique Ip address in the span of 30 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments. +action.notable.param.rule_description = The following analytic detects an Azure AD account successfully authenticating from multiple unique IP addresses within a 30-minute window. It leverages Azure AD SignInLogs to identify instances where the same user logs in from different IPs in a short time frame. This behavior is significant as it may indicate compromised credentials being used by an adversary, potentially following a phishing attack. If confirmed malicious, this activity could allow unauthorized access to corporate resources, leading to data breaches or further exploitation within the network. action.notable.param.rule_title = Azure AD Successful Authentication From Different Ips action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8474,14 +8428,14 @@ search = `azure_monitor_aad` properties.authenticationDetails{}.succeeded=true [ESCU - Azure AD Successful PowerShell Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell commandlets. This behavior is not common for regular, non administrative users. After compromising an account in Azure AD, attackers and red teams alike will perform enumeration and discovery techniques. One method of executing these techniques is leveraging the native PowerShell modules. +description = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell cmdlets. This detection leverages Azure AD SignInLogs to identify successful logins where the appDisplayName is "Microsoft Azure PowerShell." This activity is significant because it is uncommon for regular, non-administrative users to authenticate using PowerShell, and it may indicate enumeration and discovery techniques by an attacker. If confirmed malicious, this activity could allow attackers to perform extensive reconnaissance, potentially leading to privilege escalation or further exploitation within the Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell commandlets. This behavior is not common for regular, non administrative users. After compromising an account in Azure AD, attackers and red teams alike will perform enumeration and discovery techniques. One method of executing these techniques is leveraging the native PowerShell modules. +action.escu.eli5 = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell cmdlets. This detection leverages Azure AD SignInLogs to identify successful logins where the appDisplayName is "Microsoft Azure PowerShell." This activity is significant because it is uncommon for regular, non-administrative users to authenticate using PowerShell, and it may indicate enumeration and discovery techniques by an attacker. If confirmed malicious, this activity could allow attackers to perform extensive reconnaissance, potentially leading to privilege escalation or further exploitation within the Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = Administrative users will likely use PowerShell commandlets to troubleshoot and maintain the environment. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Successful PowerShell Authentication - Rule action.escu.search_type = detection @@ -8499,11 +8453,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Successful PowerShell Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "62f10052-d7b3-4e48-b57b-56f8e3ac7ceb", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "62f10052-d7b3-4e48-b57b-56f8e3ac7ceb", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell commandlets. This behavior is not common for regular, non administrative users. After compromising an account in Azure AD, attackers and red teams alike will perform enumeration and discovery techniques. One method of executing these techniques is leveraging the native PowerShell modules. +action.notable.param.rule_description = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell cmdlets. This detection leverages Azure AD SignInLogs to identify successful logins where the appDisplayName is "Microsoft Azure PowerShell." This activity is significant because it is uncommon for regular, non-administrative users to authenticate using PowerShell, and it may indicate enumeration and discovery techniques by an attacker. If confirmed malicious, this activity could allow attackers to perform extensive reconnaissance, potentially leading to privilege escalation or further exploitation within the Azure environment. action.notable.param.rule_title = Azure AD Successful PowerShell Authentication action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8521,14 +8475,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.authenticationDeta [ESCU - Azure AD Successful Single-Factor Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a successful authentication event against Azure Active Directory for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +description = The following analytic identifies a successful single-factor authentication event against Azure Active Directory. It leverages Azure SignInLogs data, specifically focusing on events where single-factor authentication succeeded. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches, privilege escalation, or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = The following analytic identifies a successful authentication event against Azure Active Directory for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +action.escu.eli5 = The following analytic identifies a successful single-factor authentication event against Azure Active Directory. It leverages Azure SignInLogs data, specifically focusing on events where single-factor authentication succeeded. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches, privilege escalation, or further exploitation within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Successful Single-Factor Authentication - Rule action.escu.search_type = detection @@ -8546,11 +8500,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Successful Single-Factor Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a560e7f6-1711-4353-885b-40be53101fcd", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a560e7f6-1711-4353-885b-40be53101fcd", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies a successful authentication event against Azure Active Directory for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +action.notable.param.rule_description = The following analytic identifies a successful single-factor authentication event against Azure Active Directory. It leverages Azure SignInLogs data, specifically focusing on events where single-factor authentication succeeded. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches, privilege escalation, or further exploitation within the environment. action.notable.param.rule_title = Azure AD Successful Single-Factor Authentication action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8568,14 +8522,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.authenticationRequi [ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to sensitive data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +action.escu.eli5 = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to sensitive data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlogs log category. action.escu.known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed. -action.escu.creation_date = 2023-09-14 -action.escu.modification_date = 2023-09-14 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule action.escu.search_type = detection @@ -8593,11 +8547,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 50, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +action.notable.param.rule_description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to sensitive data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.notable.param.rule_title = Azure AD Tenant Wide Admin Consent Granted action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8615,18 +8569,14 @@ search = `azure_monitor_aad` operationName="Consent to application" | eval new_f [ESCU - Azure AD Unusual Number of Failed Authentications From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source Ip failing to authenticate with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. \ -The detection calculates the standard deviation for source Ip and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `Azure AD Multiple Users Failing To Authenticate From Ip`. +description = The following analytic identifies a single source IP failing to authenticate with multiple valid users, potentially indicating a Password Spraying attack against an Azure Active Directory tenant. It uses Azure SignInLogs data and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual numbers of failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source Ip failing to authenticate with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. \ -The detection calculates the standard deviation for source Ip and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `Azure AD Multiple Users Failing To Authenticate From Ip`. +action.escu.eli5 = The following analytic identifies a single source IP failing to authenticate with multiple valid users, potentially indicating a Password Spraying attack against an Azure Active Directory tenant. It uses Azure SignInLogs data and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual numbers of failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category. action.escu.known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior. -action.escu.creation_date = 2022-07-11 -action.escu.modification_date = 2022-07-11 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD Unusual Number of Failed Authentications From Ip - Rule action.escu.search_type = detection @@ -8644,7 +8594,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD Unusual Number of Failed Authentications From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3d8d3a36-93b8-42d7-8d91-c5f24cec223d", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3d8d3a36-93b8-42d7-8d91-c5f24cec223d", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -8660,14 +8610,14 @@ search = `azure_monitor_aad` category=SignInLogs properties.status.errorCode=5 [ESCU - Azure AD User Consent Blocked for Risky Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +description = The following analytic detects instances where Azure AD has blocked a user's attempt to grant consent to a risky or potentially malicious application. This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +action.escu.eli5 = The following analytic detects instances where Azure AD has blocked a user's attempt to grant consent to a risky or potentially malicious application. This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = UPDATE_KNOWN_FALSE_POSITIVES -action.escu.creation_date = 2023-10-27 -action.escu.modification_date = 2023-10-27 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD User Consent Blocked for Risky Application - Rule action.escu.search_type = detection @@ -8685,11 +8635,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD User Consent Blocked for Risky Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 100, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "06b8ec9a-d3b5-4882-8f16-04b4d10f5eab", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "06b8ec9a-d3b5-4882-8f16-04b4d10f5eab", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +action.notable.param.rule_description = The following analytic detects instances where Azure AD has blocked a user's attempt to grant consent to a risky or potentially malicious application. This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures. action.notable.param.rule_title = Azure AD User Consent Blocked for Risky Application action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8707,14 +8657,14 @@ search = `azure_monitor_aad` operationName="Consent to application" properties.r [ESCU - Azure AD User Consent Denied for OAuth Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +description = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Azure AD environment. This detection leverages Azure AD's audit logs, specifically focusing on user consent actions with error code 65004. Monitoring denied consent actions is significant as it can indicate users recognizing potentially suspicious or untrusted applications. If confirmed malicious, this activity could suggest attempts by unauthorized applications to gain access, potentially leading to data breaches or unauthorized actions within the environment. Understanding these denials helps refine security policies and enhance user awareness. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +action.escu.eli5 = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Azure AD environment. This detection leverages Azure AD's audit logs, specifically focusing on user consent actions with error code 65004. Monitoring denied consent actions is significant as it can indicate users recognizing potentially suspicious or untrusted applications. If confirmed malicious, this activity could suggest attempts by unauthorized applications to gain access, potentially leading to data breaches or unauthorized actions within the environment. Understanding these denials helps refine security policies and enhance user awareness. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. action.escu.known_false_positives = Users may deny consent for legitimate applications by mistake, filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD User Consent Denied for OAuth Application - Rule action.escu.search_type = detection @@ -8732,11 +8682,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD User Consent Denied for OAuth Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb093c30-d860-4858-a56e-cd0895d5b49c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bb093c30-d860-4858-a56e-cd0895d5b49c", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +action.notable.param.rule_description = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Azure AD environment. This detection leverages Azure AD's audit logs, specifically focusing on user consent actions with error code 65004. Monitoring denied consent actions is significant as it can indicate users recognizing potentially suspicious or untrusted applications. If confirmed malicious, this activity could suggest attempts by unauthorized applications to gain access, potentially leading to data breaches or unauthorized actions within the environment. Understanding these denials helps refine security policies and enhance user awareness. action.notable.param.rule_title = Azure AD User Consent Denied for OAuth Application action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8754,14 +8704,14 @@ search = `azure_monitor_aad` operationName="Sign-in activity" properties.status [ESCU - Azure AD User Enabled And Password Reset - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This behavior could represent an adversary who has obtained administrative access and is trying to establish a backdoor identity within an Azure AD tenant. +description = The following analytic detects an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. It uses Azure Active Directory events to identify this sequence of actions. This activity is significant because it may indicate an adversary with administrative access attempting to establish a backdoor identity within the Azure AD tenant. If confirmed malicious, this could allow the attacker to maintain persistent access, escalate privileges, and potentially exfiltrate sensitive information from the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This behavior could represent an adversary who has obtained administrative access and is trying to establish a backdoor identity within an Azure AD tenant. +action.escu.eli5 = The following analytic detects an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. It uses Azure Active Directory events to identify this sequence of actions. This activity is significant because it may indicate an adversary with administrative access attempting to establish a backdoor identity within the Azure AD tenant. If confirmed malicious, this could allow the attacker to maintain persistent access, escalate privileges, and potentially exfiltrate sensitive information from the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = While not common, Administrators may enable accounts and reset their passwords for legitimate reasons. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD User Enabled And Password Reset - Rule action.escu.search_type = detection @@ -8779,11 +8729,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD User Enabled And Password Reset - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1347b9e8-2daa-4a6f-be73-b421d3d9e268", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1347b9e8-2daa-4a6f-be73-b421d3d9e268", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This behavior could represent an adversary who has obtained administrative access and is trying to establish a backdoor identity within an Azure AD tenant. +action.notable.param.rule_description = The following analytic detects an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. It uses Azure Active Directory events to identify this sequence of actions. This activity is significant because it may indicate an adversary with administrative access attempting to establish a backdoor identity within the Azure AD tenant. If confirmed malicious, this could allow the attacker to maintain persistent access, escalate privileges, and potentially exfiltrate sensitive information from the environment. action.notable.param.rule_title = Azure AD User Enabled And Password Reset action.notable.param.security_domain = identity action.notable.param.severity = high @@ -8801,14 +8751,14 @@ search = `azure_monitor_aad` (operationName="Enable account" OR operationName= [ESCU - Azure AD User ImmutableId Attribute Updated - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the modification of the SourceAnchor (also called ImmutableId) attribute for an Azure Active Directory user. Updating this attribute is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +description = The following analytic identifies the modification of the SourceAnchor (ImmutableId) attribute for an Azure Active Directory user. This detection leverages Azure AD audit logs, specifically monitoring the "Update user" operation and changes to the SourceAnchor attribute. This activity is significant as it is a step in setting up an Azure AD identity federation backdoor, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, leading to unauthorized access and potential data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the modification of the SourceAnchor (also called ImmutableId) attribute for an Azure Active Directory user. Updating this attribute is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.escu.eli5 = The following analytic identifies the modification of the SourceAnchor (ImmutableId) attribute for an Azure Active Directory user. This detection leverages Azure AD audit logs, specifically monitoring the "Update user" operation and changes to the SourceAnchor attribute. This activity is significant as it is a step in setting up an Azure AD identity federation backdoor, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, leading to unauthorized access and potential data breaches. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. action.escu.known_false_positives = The SourceAnchor (also called ImmutableId) Azure AD attribute has legitimate uses for directory synchronization. Investigate and filter as needed. -action.escu.creation_date = 2022-09-02 -action.escu.modification_date = 2022-09-02 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure AD User ImmutableId Attribute Updated - Rule action.escu.search_type = detection @@ -8826,11 +8776,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure AD User ImmutableId Attribute Updated - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0c0badad-4536-4a84-a561-5ff760f3c00e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0c0badad-4536-4a84-a561-5ff760f3c00e", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the modification of the SourceAnchor (also called ImmutableId) attribute for an Azure Active Directory user. Updating this attribute is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA. +action.notable.param.rule_description = The following analytic identifies the modification of the SourceAnchor (ImmutableId) attribute for an Azure Active Directory user. This detection leverages Azure AD audit logs, specifically monitoring the "Update user" operation and changes to the SourceAnchor attribute. This activity is significant as it is a step in setting up an Azure AD identity federation backdoor, allowing an adversary to establish persistence. If confirmed malicious, the attacker could impersonate any user, bypassing password and MFA requirements, leading to unauthorized access and potential data breaches. action.notable.param.rule_title = Azure AD User ImmutableId Attribute Updated action.notable.param.security_domain = threat action.notable.param.severity = high @@ -8848,14 +8798,14 @@ search = `azure_monitor_aad` operationName="Update user" properties.targetReso [ESCU - Azure Automation Account Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the creation of a new Azure Automation account within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure using PowerShell and Python. Azure Automation can also be configured to automate tasks on on premise infrastructure using a component called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate Automation resources, runbooks, assets, and configurations from the resources of other accounts. They allow administrators to separate resources into logical environments or delegated responsibilities. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation account with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +description = The following analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the creation of a new Azure Automation account within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure using PowerShell and Python. Azure Automation can also be configured to automate tasks on on premise infrastructure using a component called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate Automation resources, runbooks, assets, and configurations from the resources of other accounts. They allow administrators to separate resources into logical environments or delegated responsibilities. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation account with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +action.escu.eli5 = The following analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. action.escu.known_false_positives = Administrators may legitimately create Azure Automation accounts. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure Automation Account Created - Rule action.escu.search_type = detection @@ -8873,11 +8823,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure Automation Account Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "860902fd-2e76-46b3-b050-ba548dab576c", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "860902fd-2e76-46b3-b050-ba548dab576c", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the creation of a new Azure Automation account within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure using PowerShell and Python. Azure Automation can also be configured to automate tasks on on premise infrastructure using a component called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate Automation resources, runbooks, assets, and configurations from the resources of other accounts. They allow administrators to separate resources into logical environments or delegated responsibilities. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation account with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +action.notable.param.rule_description = The following analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk. action.notable.param.rule_title = Azure Automation Account Created action.notable.param.security_domain = audit action.notable.param.severity = high @@ -8895,14 +8845,14 @@ search = `azure_audit` operationName.localizedValue="Create or Update an Azure [ESCU - Azure Automation Runbook Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the creation of a new Azure Automation Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation Runbook that runs with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +description = The following analytic detects the creation of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when a new Runbook is created or updated. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the creation of a new Azure Automation Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation Runbook that runs with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +action.escu.eli5 = The following analytic detects the creation of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when a new Runbook is created or updated. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. action.escu.known_false_positives = Administrators may legitimately create Azure Automation Runbooks. Filter as needed. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure Automation Runbook Created - Rule action.escu.search_type = detection @@ -8920,11 +8870,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure Automation Runbook Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "178d696d-6dc6-4ee8-9d25-93fee34eaf5b", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "178d696d-6dc6-4ee8-9d25-93fee34eaf5b", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the creation of a new Azure Automation Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation Runbook that runs with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc. +action.notable.param.rule_description = The following analytic detects the creation of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when a new Runbook is created or updated. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment. action.notable.param.rule_title = Azure Automation Runbook Created action.notable.param.security_domain = audit action.notable.param.severity = high @@ -8942,14 +8892,14 @@ search = `azure_audit` operationName.localizedValue="Create or Update an Azure [ESCU - Azure Runbook Webhook Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the creation of a new Automation Runbook Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. One of the ways administrators can configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom unauthenticated URLs that are exposed to the Internet. An adversary who has obtained privileged access to an Azure tenant may create a Webhook to trigger the execution of an Automation Runbook with malicious code that can create users or execute code on a VM. This provides a persistent foothold on the environment. +description = The following analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the creation of a new Automation Runbook Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. One of the ways administrators can configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom unauthenticated URLs that are exposed to the Internet. An adversary who has obtained privileged access to an Azure tenant may create a Webhook to trigger the execution of an Automation Runbook with malicious code that can create users or execute code on a VM. This provides a persistent foothold on the environment. +action.escu.eli5 = The following analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category. action.escu.known_false_positives = Administrators may legitimately create Azure Runbook Webhooks. Filter as needed. -action.escu.creation_date = 2023-12-20 -action.escu.modification_date = 2023-12-20 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Azure Runbook Webhook Created - Rule action.escu.search_type = detection @@ -8967,11 +8917,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Azure Runbook Webhook Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Azure Active Directory Persistence"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e98944a9-92e4-443c-81b8-a322e33ce75a", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e98944a9-92e4-443c-81b8-a322e33ce75a", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the creation of a new Automation Runbook Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. One of the ways administrators can configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom unauthenticated URLs that are exposed to the Internet. An adversary who has obtained privileged access to an Azure tenant may create a Webhook to trigger the execution of an Automation Runbook with malicious code that can create users or execute code on a VM. This provides a persistent foothold on the environment. +action.notable.param.rule_description = The following analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources. action.notable.param.rule_title = Azure Runbook Webhook Created action.notable.param.security_domain = threat action.notable.param.severity = high @@ -8989,14 +8939,14 @@ search = `azure_audit` operationName.localizedValue="Create or Update an Azure [ESCU - Circle CI Disable Security Job - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage. False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection. +description = The following analytic detects the disabling of security jobs in CircleCI pipelines. It leverages CircleCI log data, renaming and extracting fields such as job names, workflow IDs, user information, commit messages, URLs, and branches. The detection identifies mandatory jobs for each workflow and checks if they were executed. This activity is significant because disabling security jobs can allow malicious code to bypass security checks, leading to potential data breaches, system downtime, and reputational damage. If confirmed malicious, this could result in unauthorized code execution and compromised pipeline integrity. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage. False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection. +action.escu.eli5 = The following analytic detects the disabling of security jobs in CircleCI pipelines. It leverages CircleCI log data, renaming and extracting fields such as job names, workflow IDs, user information, commit messages, URLs, and branches. The detection identifies mandatory jobs for each workflow and checks if they were executed. This activity is significant because disabling security jobs can allow malicious code to bypass security checks, leading to potential data breaches, system downtime, and reputational damage. If confirmed malicious, this could result in unauthorized code execution and compromised pipeline integrity. action.escu.how_to_implement = You must index CircleCI logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-02 -action.escu.modification_date = 2021-09-02 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Circle CI Disable Security Job - Rule action.escu.search_type = detection @@ -9014,7 +8964,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Circle CI Disable Security Job - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4a2fdd41-c578-4cd4-9ef7-980e352517f2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4a2fdd41-c578-4cd4-9ef7-980e352517f2", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9030,14 +8980,14 @@ search = `circleci` | rename vcs.committer_name as user vcs.subject as commit_me [ESCU - Circle CI Disable Security Step - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs. The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the disablement of security steps in a CircleCI pipeline. It leverages CircleCI logs, using field renaming, joining, and statistical analysis to identify instances where mandatory security steps are not executed. This activity is significant because disabling security steps can introduce vulnerabilities, unauthorized changes, or malicious code into the pipeline. If confirmed malicious, this could lead to potential attacks, data breaches, or compromised infrastructure. Investigate by reviewing job names, commit details, and user information associated with the disablement, and examine any relevant artifacts and concurrent processes. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs. The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change. +action.escu.eli5 = The following analytic detects the disablement of security steps in a CircleCI pipeline. It leverages CircleCI logs, using field renaming, joining, and statistical analysis to identify instances where mandatory security steps are not executed. This activity is significant because disabling security steps can introduce vulnerabilities, unauthorized changes, or malicious code into the pipeline. If confirmed malicious, this could lead to potential attacks, data breaches, or compromised infrastructure. Investigate by reviewing job names, commit details, and user information associated with the disablement, and examine any relevant artifacts and concurrent processes. action.escu.how_to_implement = You must index CircleCI logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Circle CI Disable Security Step - Rule action.escu.search_type = detection @@ -9055,7 +9005,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Circle CI Disable Security Step - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "72cb9de9-e98b-4ac9-80b2-5331bba6ea97", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "72cb9de9-e98b-4ac9-80b2-5331bba6ea97", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9071,14 +9021,14 @@ search = `circleci` | rename workflows.job_id AS job_id | join job_id [ | search [ESCU - Cloud API Calls From Previously Unseen User Roles - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects cloud API calls executed by user roles that have not previously run these commands. It leverages the Change data model in Splunk to identify commands executed by users with the user_type of AssumedRole and a status of success. This activity is significant because new commands from different user roles can indicate potential malicious activity or unauthorized actions. If confirmed malicious, this behavior could lead to unauthorized access, data breaches, or other damaging outcomes by exploiting new or unmonitored commands within the cloud environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes. +action.escu.eli5 = The following analytic detects cloud API calls executed by user roles that have not previously run these commands. It leverages the Change data model in Splunk to identify commands executed by users with the user_type of AssumedRole and a status of success. This activity is significant because new commands from different user roles can indicate potential malicious activity or unauthorized actions. If confirmed malicious, this behavior could lead to unauthorized access, data breaches, or other damaging outcomes by exploiting new or unmonitored commands within the cloud environment. action.escu.how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud API Calls Per User Role - Initial` to build the initial table of user roles, commands, and times. You must also enable the second baseline search `Previously Seen Cloud API Calls Per User Role - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `cloud_api_calls_from_previously_unseen_user_roles_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_api_calls_from_previously_unseen_user_roles_filter` action.escu.known_false_positives = None. -action.escu.creation_date = 2020-09-04 -action.escu.modification_date = 2020-09-04 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Cloud API Calls From Previously Unseen User Roles - Rule action.escu.search_type = detection @@ -9096,7 +9046,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Cloud API Calls From Previously Unseen User Roles - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Cloud User Activities"], "cis20": ["CIS 10"], "confidence": 60, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2181ad1f-1e73-4d0c-9780-e8880482a08f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2181ad1f-1e73-4d0c-9780-e8880482a08f", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9194,14 +9144,14 @@ search = | tstats earliest(_time) as firstTime latest(_time) as lastTime values( [ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the creation of cloud compute instances using previously unseen image IDs. It leverages cloud infrastructure logs to identify new image IDs that have not been observed before. This activity is significant because it may indicate unauthorized or suspicious activity, such as the deployment of malicious payloads or unauthorized access to sensitive information. If confirmed malicious, this could lead to data breaches, unauthorized access, or further compromise of the cloud environment. Immediate investigation is required to determine the legitimacy of the instance creation and to mitigate potential threats. action.escu.mappings = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack. +action.escu.eli5 = The following analytic detects the creation of cloud compute instances using previously unseen image IDs. It leverages cloud infrastructure logs to identify new image IDs that have not been observed before. This activity is significant because it may indicate unauthorized or suspicious activity, such as the deployment of malicious payloads or unauthorized access to sensitive information. If confirmed malicious, this could lead to data breaches, unauthorized access, or further compromise of the cloud environment. Immediate investigation is required to determine the legitimacy of the instance creation and to mitigate potential threats. action.escu.how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Images - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Images - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_image_filter` macro. action.escu.known_false_positives = After a new image is created, the first systems created with that image will cause this alert to fire. Verify that the image being used was created by a legitimate user. -action.escu.creation_date = 2018-10-12 -action.escu.modification_date = 2018-10-12 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule action.escu.search_type = detection @@ -9219,7 +9169,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Cloud Compute Instance Created With Previously Unseen Image - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Cryptomining"], "cis20": ["CIS 10"], "confidence": 60, "impact": 60, "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc24922d-987c-4645-b288-f8c73ec194c4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc24922d-987c-4645-b288-f8c73ec194c4", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9235,14 +9185,14 @@ search = | tstats count earliest(_time) as firstTime, latest(_time) as lastTime [ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the creation of EC2 instances with previously unseen instance types. It leverages Splunk's tstats command to analyze data from the Change data model, identifying instance types that have not been previously recorded. This activity is significant for a SOC because it may indicate unauthorized or suspicious activity, such as an attacker attempting to create instances for malicious purposes. If confirmed malicious, this could lead to unauthorized access, data exfiltration, system compromise, or service disruption. Immediate investigation is required to determine the legitimacy of the instance creation. action.escu.mappings = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts. +action.escu.eli5 = The following analytic detects the creation of EC2 instances with previously unseen instance types. It leverages Splunk's tstats command to analyze data from the Change data model, identifying instance types that have not been previously recorded. This activity is significant for a SOC because it may indicate unauthorized or suspicious activity, such as an attacker attempting to create instances for malicious purposes. If confirmed malicious, this could lead to unauthorized access, data exfiltration, system compromise, or service disruption. Immediate investigation is required to determine the legitimacy of the instance creation. action.escu.how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Instance Types - Initial` to build the initial table of instance types observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Instance Types - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_instance_type_filter` macro. action.escu.known_false_positives = It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type. -action.escu.creation_date = 2020-09-12 -action.escu.modification_date = 2020-09-12 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule action.escu.search_type = detection @@ -9260,7 +9210,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Cryptomining"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c6ddbf53-9715-49f3-bb4c-fb2e8a309cda", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c6ddbf53-9715-49f3-bb4c-fb2e8a309cda", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9354,7 +9304,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(City) | lookup previously_seen_cloud_provisioning_activity_sources City as City OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCity=min(firstTimeSeen) | where isnull(firstTimeSeenCity) OR firstTimeSeenCity > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | table firstTime, src, City, user, object, command | `cloud_provisioning_activity_from_previously_unseen_city_filter` | `security_content_ctime(firstTime)` +search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(City) | lookup previously_seen_cloud_provisioning_activity_sources City as City OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCity=min(firstTimeSeen) | where isnull(firstTimeSeenCity) OR firstTimeSeenCity > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | `security_content_ctime(firstTime)` | table firstTime, src, City, user, object, command | `cloud_provisioning_activity_from_previously_unseen_city_filter` [ESCU - Cloud Provisioning Activity From Previously Unseen Country - Rule] action.escu = 0 @@ -9396,7 +9346,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(Country) | lookup previously_seen_cloud_provisioning_activity_sources Country as Country OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCountry=min(firstTimeSeen) | where isnull(firstTimeSeenCountry) OR firstTimeSeenCountry > relative_time(now(), "-24h@h") | table firstTime, src, Country, user, object, command | `cloud_provisioning_activity_from_previously_unseen_country_filter` | `security_content_ctime(firstTime)` +search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(Country) | lookup previously_seen_cloud_provisioning_activity_sources Country as Country OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenCountry=min(firstTimeSeen) | where isnull(firstTimeSeenCountry) OR firstTimeSeenCountry > relative_time(now(), "-24h@h") | `security_content_ctime(firstTime)` | table firstTime, src, Country, user, object, command | `cloud_provisioning_activity_from_previously_unseen_country_filter` [ESCU - Cloud Provisioning Activity From Previously Unseen IP Address - Rule] action.escu = 0 @@ -9438,7 +9388,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime, values(All_Changes.object_id) as object_id from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.command | `drop_dm_object_name("All_Changes")` | lookup previously_seen_cloud_provisioning_activity_sources src as src OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenSrc=min(firstTimeSeen) | where isnull(firstTimeSeenSrc) OR firstTimeSeenSrc > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | table firstTime, src, user, object_id, command | `cloud_provisioning_activity_from_previously_unseen_ip_address_filter` | `security_content_ctime(firstTime)` +search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime, values(All_Changes.object_id) as object_id from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.command | `drop_dm_object_name("All_Changes")` | lookup previously_seen_cloud_provisioning_activity_sources src as src OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenSrc=min(firstTimeSeen) | where isnull(firstTimeSeenSrc) OR firstTimeSeenSrc > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | `security_content_ctime(firstTime)` | table firstTime, src, user, object_id, command | `cloud_provisioning_activity_from_previously_unseen_ip_address_filter` [ESCU - Cloud Provisioning Activity From Previously Unseen Region - Rule] action.escu = 0 @@ -9480,25 +9430,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(Region) | lookup previously_seen_cloud_provisioning_activity_sources Region as Region OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenRegion=min(firstTimeSeen) | where isnull(firstTimeSeenRegion) OR firstTimeSeenRegion > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | table firstTime, src, Region, user, object, command | `cloud_provisioning_activity_from_previously_unseen_region_filter` | `security_content_ctime(firstTime)` +search = | tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change where (All_Changes.action=started OR All_Changes.action=created) All_Changes.status=success by All_Changes.src, All_Changes.user, All_Changes.object, All_Changes.command | `drop_dm_object_name("All_Changes")` | iplocation src | where isnotnull(Region) | lookup previously_seen_cloud_provisioning_activity_sources Region as Region OUTPUT firstTimeSeen, enough_data | eventstats max(enough_data) as enough_data | where enough_data=1 | eval firstTimeSeenRegion=min(firstTimeSeen) | where isnull(firstTimeSeenRegion) OR firstTimeSeenRegion > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`) | `security_content_ctime(firstTime)` | table firstTime, src, Region, user, object, command | `cloud_provisioning_activity_from_previously_unseen_region_filter` [ESCU - Cloud Security Groups Modifications by User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies users who are unsually modifying security group in your cloud enriovnment,focusing on actions such as modifications, deletions, or creations performed by users over 30-minute intervals. Analyzing patterns of modifications to security groups can help in identifying anomalous behavior that may indicate a compromised account or an insider threat. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on all user and service accounts that have created/modified/deleted a security group . \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and values of the security objects affected. +description = The following analytic identifies unusual modifications to security groups in your cloud environment by users, focusing on actions such as modifications, deletions, or creations over 30-minute intervals. It leverages cloud infrastructure logs and calculates the standard deviation for each user, using the 3-sigma rule to detect anomalies. This activity is significant as it may indicate a compromised account or insider threat. If confirmed malicious, attackers could alter security group configurations, potentially exposing sensitive resources or disrupting services. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1578.005"], "nist": ["DE.AE"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic identifies users who are unsually modifying security group in your cloud enriovnment,focusing on actions such as modifications, deletions, or creations performed by users over 30-minute intervals. Analyzing patterns of modifications to security groups can help in identifying anomalous behavior that may indicate a compromised account or an insider threat. \ -The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises. \ -This detection will only trigger on all user and service accounts that have created/modified/deleted a security group . \ -The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and values of the security objects affected. +action.escu.eli5 = The following analytic identifies unusual modifications to security groups in your cloud environment by users, focusing on actions such as modifications, deletions, or creations over 30-minute intervals. It leverages cloud infrastructure logs and calculates the standard deviation for each user, using the 3-sigma rule to detect anomalies. This activity is significant as it may indicate a compromised account or insider threat. If confirmed malicious, attackers could alter security group configurations, potentially exposing sensitive resources or disrupting services. action.escu.how_to_implement = This search requries the Cloud infrastructure logs such as AWS Cloudtrail, GCP Pubsub Message logs, Azure Audit logs to be ingested into an accelerated Change datamodel. It is also recommended that users can try different combinations of the `bucket` span time and outlier conditions to better suit with their environment. action.escu.known_false_positives = It is possible that legitimate user/admin may modify a number of security groups -action.escu.creation_date = 2024-02-21 -action.escu.modification_date = 2024-02-21 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Cloud Security Groups Modifications by User - Rule action.escu.search_type = detection @@ -9516,7 +9460,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Cloud Security Groups Modifications by User - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Cloud User Activities"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1578.005"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cfe7cca7-2746-4bdf-b712-b01ed819b9de", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cfe7cca7-2746-4bdf-b712-b01ed819b9de", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9532,14 +9476,14 @@ search = | tstats dc(All_Changes.object) as unique_security_groups values(All_Ch [ESCU - Detect AWS Console Login by New User - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects AWS console login events by new users. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users based on ARN values. This detection is significant because a new user logging into the AWS console could indicate the creation of new accounts or potential unauthorized access. If confirmed malicious, this activity could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1552"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +action.escu.eli5 = The following analytic detects AWS console login events by new users. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users based on ARN values. This detection is significant because a new user logging into the AWS console could indicate the creation of new accounts or potential unauthorized access. If confirmed malicious, this activity could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. action.escu.how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. action.escu.known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. -action.escu.creation_date = 2022-05-10 -action.escu.modification_date = 2022-05-10 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AWS Console Login by New User - Rule action.escu.search_type = detection @@ -9552,7 +9496,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect AWS Console Login by New User - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Suspicious Cloud Authentication Activities"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1552"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc91a8cd-35e7-4bb2-6140-e756cc46fd71", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc91a8cd-35e7-4bb2-6140-e756cc46fd71", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9568,14 +9512,14 @@ search = | tstats earliest(_time) as firstTime latest(_time) as lastTime from da [ESCU - Detect AWS Console Login by User from New City - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +description = The following analytic identifies AWS console login events by users from a new city within the last hour. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen user locations. This activity is significant for a SOC as it may indicate unauthorized access or credential compromise, especially if the login originates from an unusual location. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +action.escu.eli5 = The following analytic identifies AWS console login events by users from a new city within the last hour. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen user locations. This activity is significant for a SOC as it may indicate unauthorized access or credential compromise, especially if the login originates from an unusual location. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment. action.escu.how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_city_filter` macro. action.escu.known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. -action.escu.creation_date = 2022-08-25 -action.escu.modification_date = 2022-08-25 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AWS Console Login by User from New City - Rule action.escu.search_type = detection @@ -9588,7 +9532,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect AWS Console Login by User from New City - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account", "Suspicious AWS Login Activities", "Suspicious Cloud Authentication Activities"], "cis20": ["CIS 10"], "confidence": 60, "impact": 30, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "121b0b11-f8ac-4ed6-a132-3800ca4fc07a", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "121b0b11-f8ac-4ed6-a132-3800ca4fc07a", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9604,14 +9548,14 @@ search = | tstats earliest(_time) as firstTime latest(_time) as lastTime from da [ESCU - Detect AWS Console Login by User from New Country - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +description = The following analytic identifies AWS console login events by users from a new country. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users and their login locations. This activity is significant because logins from new countries can indicate potential unauthorized access or compromised accounts. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the AWS environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +action.escu.eli5 = The following analytic identifies AWS console login events by users from a new country. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users and their login locations. This activity is significant because logins from new countries can indicate potential unauthorized access or compromised accounts. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the AWS environment. action.escu.how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_country_filter` macro. action.escu.known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. -action.escu.creation_date = 2022-08-25 -action.escu.modification_date = 2022-08-25 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AWS Console Login by User from New Country - Rule action.escu.search_type = detection @@ -9624,7 +9568,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect AWS Console Login by User from New Country - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account", "Suspicious AWS Login Activities", "Suspicious Cloud Authentication Activities"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "67bd3def-c41c-4bf6-837b-ae196b4257c6", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "67bd3def-c41c-4bf6-837b-ae196b4257c6", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9640,14 +9584,14 @@ search = | tstats earliest(_time) as firstTime latest(_time) as lastTime from da [ESCU - Detect AWS Console Login by User from New Region - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +description = The following analytic identifies AWS console login attempts by users from a new region. It leverages AWS CloudTrail events and compares current login regions against a baseline of previously seen regions for each user. This activity is significant as it may indicate unauthorized access attempts or compromised credentials. If confirmed malicious, an attacker could gain unauthorized access to AWS resources, potentially leading to data breaches, resource manipulation, or further lateral movement within the cloud environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour +action.escu.eli5 = The following analytic identifies AWS console login attempts by users from a new region. It leverages AWS CloudTrail events and compares current login regions against a baseline of previously seen regions for each user. This activity is significant as it may indicate unauthorized access attempts or compromised credentials. If confirmed malicious, an attacker could gain unauthorized access to AWS resources, potentially leading to data breaches, resource manipulation, or further lateral movement within the cloud environment. action.escu.how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_region_filter` macro. action.escu.known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate. -action.escu.creation_date = 2022-08-25 -action.escu.modification_date = 2022-08-25 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AWS Console Login by User from New Region - Rule action.escu.search_type = detection @@ -9660,7 +9604,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect AWS Console Login by User from New Region - Rule action.correlationsearch.annotations = {"analytic_story": ["AWS Identity and Access Management Account Takeover", "Compromised User Account", "Suspicious AWS Login Activities", "Suspicious Cloud Authentication Activities"], "cis20": ["CIS 10"], "confidence": 60, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9f31aa8e-e37c-46bc-bce1-8b3be646d026", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9f31aa8e-e37c-46bc-bce1-8b3be646d026", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -9806,7 +9750,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventSource=s3.amazonaws.com eventName=PutBucketAcl | rex field=_raw "(?{.+})" | spath input=json_field output=grantees path=requestParameters.AccessControlPolicy.AccessControlList.Grant{} | search grantees=* | mvexpand grantees | spath input=grantees output=uri path=Grantee.URI | spath input=grantees output=permission path=Permission | search uri IN ("http://acs.amazonaws.com/groups/global/AllUsers","http://acs.amazonaws.com/groups/global/AuthenticatedUsers") | search permission IN ("READ","READ_ACP","WRITE","WRITE_ACP","FULL_CONTROL") | rename requestParameters.bucketName AS bucketName | stats count min(_time) as firstTime max(_time) as lastTime by user_arn userIdentity.principalId userAgent uri permission bucketName | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_filter` +search = `cloudtrail` eventSource=s3.amazonaws.com eventName=PutBucketAcl | rex field=_raw "(?{.+})" | spath input=json_field output=grantees path=requestParameters.AccessControlPolicy.AccessControlList.Grant{} | search grantees=* | mvexpand grantees | spath input=grantees output=uri path=Grantee.URI | spath input=grantees output=permission path=Permission | search uri IN ("http://acs.amazonaws.com/groups/global/AllUsers","http://acs.amazonaws.com/groups/global/AuthenticatedUsers") | search permission IN ("READ","READ_ACP","WRITE","WRITE_ACP","FULL_CONTROL") | rename requestParameters.bucketName AS bucketName | stats count min(_time) as firstTime max(_time) as lastTime by user_arn userIdentity.principalId userAgent uri permission bucketName | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_filter` [ESCU - Detect New Open S3 Buckets over AWS CLI - Rule] action.escu = 0 @@ -9853,7 +9797,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `cloudtrail` eventSource="s3.amazonaws.com" (userAgent="[aws-cli*" OR userAgent=aws-cli* ) eventName=PutBucketAcl OR requestParameters.accessControlList.x-amz-grant-read-acp IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-write IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-write-acp IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-full-control IN ("*AuthenticatedUsers","*AllUsers") | rename requestParameters.bucketName AS bucketName | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by userIdentity.userName userIdentity.principalId userAgent bucketName requestParameters.accessControlList.x-amz-grant-read requestParameters.accessControlList.x-amz-grant-read-acp requestParameters.accessControlList.x-amz-grant-write requestParameters.accessControlList.x-amz-grant-write-acp requestParameters.accessControlList.x-amz-grant-full-control | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_over_aws_cli_filter` +search = `cloudtrail` eventSource="s3.amazonaws.com" (userAgent="[aws-cli*" OR userAgent=aws-cli* ) eventName=PutBucketAcl OR requestParameters.accessControlList.x-amz-grant-read-acp IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-write IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-write-acp IN ("*AuthenticatedUsers","*AllUsers") OR requestParameters.accessControlList.x-amz-grant-full-control IN ("*AuthenticatedUsers","*AllUsers") | rename requestParameters.bucketName AS bucketName | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by userIdentity.userName userIdentity.principalId userAgent bucketName requestParameters.accessControlList.x-amz-grant-read requestParameters.accessControlList.x-amz-grant-read-acp requestParameters.accessControlList.x-amz-grant-write requestParameters.accessControlList.x-amz-grant-write-acp requestParameters.accessControlList.x-amz-grant-full-control | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_new_open_s3_buckets_over_aws_cli_filter` [ESCU - Detect S3 access from a new IP - Rule] action.escu = 0 @@ -10063,14 +10007,14 @@ search = `cloudtrail` eventName=DeleteBucket [search `cloudtrail` eventName=Dele [ESCU - GCP Authentication Failed During MFA Challenge - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an authentication attempt event against a Google Cloud Platform tenant that fails during the Multi Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +description = The following analytic detects failed authentication attempts during the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) tenant. It uses Google Workspace login failure events to identify instances where MFA methods were challenged but not successfully completed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials despite MFA protection. If confirmed malicious, this could lead to unauthorized access attempts, potentially compromising sensitive data and resources within the GCP environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an authentication attempt event against a Google Cloud Platform tenant that fails during the Multi Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.escu.eli5 = The following analytic detects failed authentication attempts during the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) tenant. It uses Google Workspace login failure events to identify instances where MFA methods were challenged but not successfully completed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials despite MFA protection. If confirmed malicious, this could lead to unauthorized access attempts, potentially compromising sensitive data and resources within the GCP environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events. action.escu.known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake. -action.escu.creation_date = 2024-01-04 -action.escu.modification_date = 2024-01-04 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Authentication Failed During MFA Challenge - Rule action.escu.search_type = detection @@ -10088,11 +10032,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Authentication Failed During MFA Challenge - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "345f7e1d-a3fe-4158-abd8-e630f9878323", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "345f7e1d-a3fe-4158-abd8-e630f9878323", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an authentication attempt event against a Google Cloud Platform tenant that fails during the Multi Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. +action.notable.param.rule_description = The following analytic detects failed authentication attempts during the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) tenant. It uses Google Workspace login failure events to identify instances where MFA methods were challenged but not successfully completed. This activity is significant as it may indicate an adversary attempting to access an account with compromised credentials despite MFA protection. If confirmed malicious, this could lead to unauthorized access attempts, potentially compromising sensitive data and resources within the GCP environment. action.notable.param.rule_title = GCP Authentication Failed During MFA Challenge action.notable.param.security_domain = identity action.notable.param.severity = high @@ -10193,14 +10137,14 @@ search = `google_gcp_pubsub_message` category=kube-audit |spath input=properties [ESCU - GCP Multi-Factor Authentication Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an attempt to disable multi-factor authentication for a GCP user. An adversary who has obtained access to an GCP tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +description = The following analytic detects an attempt to disable multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin log events, specifically the `UNENROLL_USER_FROM_STRONG_AUTH` command. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised account without raising suspicion. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access, data exfiltration, or further exploitation of the compromised account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an attempt to disable multi-factor authentication for a GCP user. An adversary who has obtained access to an GCP tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.escu.eli5 = The following analytic detects an attempt to disable multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin log events, specifically the `UNENROLL_USER_FROM_STRONG_AUTH` command. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised account without raising suspicion. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access, data exfiltration, or further exploitation of the compromised account. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the Admin log events. action.escu.known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed. -action.escu.creation_date = 2024-01-04 -action.escu.modification_date = 2024-01-04 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Multi-Factor Authentication Disabled - Rule action.escu.search_type = detection @@ -10218,11 +10162,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Multi-Factor Authentication Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b9bc5513-6fc1-4821-85a3-e1d81e451c83", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b9bc5513-6fc1-4821-85a3-e1d81e451c83", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an attempt to disable multi-factor authentication for a GCP user. An adversary who has obtained access to an GCP tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users. +action.notable.param.rule_description = The following analytic detects an attempt to disable multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin log events, specifically the `UNENROLL_USER_FROM_STRONG_AUTH` command. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised account without raising suspicion. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access, data exfiltration, or further exploitation of the compromised account. action.notable.param.rule_title = GCP Multi-Factor Authentication Disabled action.notable.param.security_domain = identity action.notable.param.severity = high @@ -10240,14 +10184,14 @@ search = `gws_reports_admin` command=UNENROLL_USER_FROM_STRONG_AUTH | stats coun [ESCU - GCP Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a Google Cloud Platform tenant. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google CLoud tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +description = The following analytic detects multiple failed multi-factor authentication (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. It triggers when 10 or more MFA prompts fail within a 5-minute window, using Google Workspace login failure events. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise accounts and potentially escalate privileges within the GCP environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a Google Cloud Platform tenant. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google CLoud tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.escu.eli5 = The following analytic detects multiple failed multi-factor authentication (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. It triggers when 10 or more MFA prompts fail within a 5-minute window, using Google Workspace login failure events. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise accounts and potentially escalate privileges within the GCP environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `mfa_prompts` threshold values according to your environment. Specifically, this analytic leverages the User log events. action.escu.known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. -action.escu.creation_date = 2022-10-14 -action.escu.modification_date = 2022-10-14 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -10265,11 +10209,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cbb3cb84-c06f-4393-adcc-5cb6195621f1", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cbb3cb84-c06f-4393-adcc-5cb6195621f1", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a Google Cloud Platform tenant. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google CLoud tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others. +action.notable.param.rule_description = The following analytic detects multiple failed multi-factor authentication (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. It triggers when 10 or more MFA prompts fail within a 5-minute window, using Google Workspace login failure events. This behavior is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this activity could lead to unauthorized access, allowing attackers to compromise accounts and potentially escalate privileges within the GCP environment. action.notable.param.rule_title = GCP Multiple Failed MFA Requests For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -10287,14 +10231,14 @@ search = `gws_reports_login` event.name=login_failure `gws_login_mfa_methods` | [ESCU - GCP Multiple Users Failing To Authenticate From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source Ip failing to authenticate into the Google Workspace user accounts with more than 20 unique valid users within 5 minutes. These user accounts may have other privileges with respect to access to other sensitive resources in the Google Cloud Platform. This behavior could represent an adversary performing a Password Spraying attack against an Google Workspace environment to obtain initial access or elevate privileges. +description = The following analytic detects a single source IP address failing to authenticate into more than 20 unique Google Workspace user accounts within a 5-minute window. It leverages Google Workspace login failure events to identify potential password spraying attacks. This activity is significant as it may indicate an adversary attempting to gain unauthorized access or elevate privileges within the Google Cloud Platform. If confirmed malicious, this behavior could lead to unauthorized access to sensitive resources, data breaches, or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source Ip failing to authenticate into the Google Workspace user accounts with more than 20 unique valid users within 5 minutes. These user accounts may have other privileges with respect to access to other sensitive resources in the Google Cloud Platform. This behavior could represent an adversary performing a Password Spraying attack against an Google Workspace environment to obtain initial access or elevate privileges. +action.escu.eli5 = The following analytic detects a single source IP address failing to authenticate into more than 20 unique Google Workspace user accounts within a 5-minute window. It leverages Google Workspace login failure events to identify potential password spraying attacks. This activity is significant as it may indicate an adversary attempting to gain unauthorized access or elevate privileges within the Google Cloud Platform. If confirmed malicious, this behavior could lead to unauthorized access to sensitive resources, data breaches, or further exploitation within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events. action.escu.known_false_positives = No known false postives for this detection. Please review this alert. -action.escu.creation_date = 2022-10-12 -action.escu.modification_date = 2022-10-12 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Multiple Users Failing To Authenticate From Ip - Rule action.escu.search_type = detection @@ -10312,7 +10256,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Multiple Users Failing To Authenticate From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "da20828e-d6fb-4ee5-afb7-d0ac200923d5", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "da20828e-d6fb-4ee5-afb7-d0ac200923d5", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10328,14 +10272,14 @@ search = `gws_reports_login` event.type = login event.name = login_failure | buc [ESCU - GCP Successful Single-Factor Authentication - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a successful authentication event against Google Cloud Platform for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +description = The following analytic identifies a successful single-factor authentication event against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication (MFA) enabled. It uses Google Workspace login event data to detect instances where MFA is not utilized. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to GCP resources, potentially leading to data breaches, service disruptions, or further exploitation within the cloud environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies a successful authentication event against Google Cloud Platform for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +action.escu.eli5 = The following analytic identifies a successful single-factor authentication event against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication (MFA) enabled. It uses Google Workspace login event data to detect instances where MFA is not utilized. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to GCP resources, potentially leading to data breaches, service disruptions, or further exploitation within the cloud environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events. action.escu.known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed -action.escu.creation_date = 2024-01-04 -action.escu.modification_date = 2024-01-04 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Successful Single-Factor Authentication - Rule action.escu.search_type = detection @@ -10353,11 +10297,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Successful Single-Factor Authentication - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Delivery", "Exploitation", "Installation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "40e17d88-87da-414e-b253-8dc1e4f9555b", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "40e17d88-87da-414e-b253-8dc1e4f9555b", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies a successful authentication event against Google Cloud Platform for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated +action.notable.param.rule_description = The following analytic identifies a successful single-factor authentication event against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication (MFA) enabled. It uses Google Workspace login event data to detect instances where MFA is not utilized. This activity is significant as it may indicate a misconfiguration, policy violation, or potential account takeover attempt. If confirmed malicious, an attacker could gain unauthorized access to GCP resources, potentially leading to data breaches, service disruptions, or further exploitation within the cloud environment. action.notable.param.rule_title = GCP Successful Single-Factor Authentication action.notable.param.security_domain = identity action.notable.param.severity = high @@ -10375,14 +10319,14 @@ search = `gws_reports_login` event.name=login_success NOT `gws_login_mfa_methods [ESCU - GCP Unusual Number of Failed Authentications From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies one source IP failing to authenticate into the Google Workspace with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against a Google Workspace enviroment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `GCP Multiple Users Failing To Authenticate From Ip` +description = The following analytic identifies a single source IP failing to authenticate into Google Workspace with multiple valid users, potentially indicating a Password Spraying attack. It uses Google Workspace login failure events and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies one source IP failing to authenticate into the Google Workspace with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against a Google Workspace enviroment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `GCP Multiple Users Failing To Authenticate From Ip` +action.escu.eli5 = The following analytic identifies a single source IP failing to authenticate into Google Workspace with multiple valid users, potentially indicating a Password Spraying attack. It uses Google Workspace login failure events and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation within the environment. action.escu.how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events. action.escu.known_false_positives = No known false positives for this detection. Please review this alert -action.escu.creation_date = 2022-10-13 -action.escu.modification_date = 2022-10-13 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - GCP Unusual Number of Failed Authentications From Ip - Rule action.escu.search_type = detection @@ -10400,7 +10344,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GCP Unusual Number of Failed Authentications From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["GCP Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bd8097ed-958a-4873-87d9-44f2b4d85705", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bd8097ed-958a-4873-87d9-44f2b4d85705", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10493,14 +10437,14 @@ search = `github` workflow_run.event=push OR workflow_run.event=pull_request | s [ESCU - Github Commit Changes In Master - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a pushed or commit to master or main branch. This is to avoid unwanted modification to master without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +description = The following analytic detects direct commits or pushes to the master or main branch in a GitHub repository. It leverages GitHub logs to identify events where changes are made directly to these critical branches. This activity is significant because direct modifications to the master or main branch bypass the standard review process, potentially introducing unreviewed and harmful changes. If confirmed malicious, this could lead to unauthorized code execution, security vulnerabilities, or compromised project integrity. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a pushed or commit to master or main branch. This is to avoid unwanted modification to master without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +action.escu.eli5 = The following analytic detects direct commits or pushes to the master or main branch in a GitHub repository. It leverages GitHub logs to identify events where changes are made directly to these critical branches. This activity is significant because direct modifications to the master or main branch bypass the standard review process, potentially introducing unreviewed and harmful changes. If confirmed malicious, this could lead to unauthorized code execution, security vulnerabilities, or compromised project integrity. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project. action.escu.known_false_positives = Admin can do changes directly to master branch -action.escu.creation_date = 2021-08-20 -action.escu.modification_date = 2021-08-20 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Github Commit Changes In Master - Rule action.escu.search_type = detection @@ -10518,7 +10462,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Github Commit Changes In Master - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 30, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c9d2bfe2-019f-11ec-a8eb-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c9d2bfe2-019f-11ec-a8eb-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10534,14 +10478,14 @@ search = `github` branches{}.name = main OR branches{}.name = master | stats co [ESCU - Github Commit In Develop - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a pushed or commit to develop branch. This is to avoid unwanted modification to develop without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +description = The following analytic detects commits pushed directly to the 'develop' or 'main' branches in a GitHub repository. It leverages GitHub logs, focusing on commit metadata such as author details, commit messages, and timestamps. This activity is significant as direct commits to these branches can bypass the review process, potentially introducing unvetted changes. If confirmed malicious, this could lead to unauthorized code modifications, introducing vulnerabilities or backdoors into the codebase, and compromising the integrity of the development lifecycle. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a pushed or commit to develop branch. This is to avoid unwanted modification to develop without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch +action.escu.eli5 = The following analytic detects commits pushed directly to the 'develop' or 'main' branches in a GitHub repository. It leverages GitHub logs, focusing on commit metadata such as author details, commit messages, and timestamps. This activity is significant as direct commits to these branches can bypass the review process, potentially introducing unvetted changes. If confirmed malicious, this could lead to unauthorized code modifications, introducing vulnerabilities or backdoors into the codebase, and compromising the integrity of the development lifecycle. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project. action.escu.known_false_positives = admin can do changes directly to develop branch -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Github Commit In Develop - Rule action.escu.search_type = detection @@ -10559,7 +10503,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Github Commit In Develop - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 30, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f3030cb6-0b02-11ec-8f22-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f3030cb6-0b02-11ec-8f22-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10575,14 +10519,14 @@ search = `github` branches{}.name = main OR branches{}.name = develop | stats c [ESCU - GitHub Dependabot Alert - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic is made by first searching for logs that contain the action "create" and renames certain fields for easier analysis. Then, this analytic uses the "stats" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The "phase" field is set to "code" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the "create" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps. +description = The following analytic identifies the creation of GitHub Dependabot alerts, which indicate potential vulnerabilities in the codebase. It detects this activity by searching for logs with the "create" action and analyzing fields such as affected package, severity, and fixed version. This detection is significant for a SOC because it helps identify and address security risks in the codebase proactively. If confirmed malicious, these vulnerabilities could be exploited by attackers to gain unauthorized access or cause breaches, leading to potential data loss or system compromise. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic is made by first searching for logs that contain the action "create" and renames certain fields for easier analysis. Then, this analytic uses the "stats" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The "phase" field is set to "code" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the "create" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps. +action.escu.eli5 = The following analytic identifies the creation of GitHub Dependabot alerts, which indicate potential vulnerabilities in the codebase. It detects this activity by searching for logs with the "create" action and analyzing fields such as affected package, severity, and fixed version. This detection is significant for a SOC because it helps identify and address security risks in the codebase proactively. If confirmed malicious, these vulnerabilities could be exploited by attackers to gain unauthorized access or cause breaches, leading to potential data loss or system compromise. action.escu.how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - GitHub Dependabot Alert - Rule action.escu.search_type = detection @@ -10600,7 +10544,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GitHub Dependabot Alert - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "05032b04-4469-4034-9df7-05f607d75cba", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "05032b04-4469-4034-9df7-05f607d75cba", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10616,14 +10560,14 @@ search = `github` alert.id=* action=create | rename repository.full_name as repo [ESCU - GitHub Pull Request from Unknown User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request." +description = The following analytic detects pull requests from unknown users on GitHub. It uses a Splunk query to identify pull requests where the user ID is not specified and cross-references these with a known users lookup table. This activity is significant because pull requests from unknown users can introduce malicious code or unauthorized changes to repositories. If confirmed malicious, this could lead to unauthorized code changes, data breaches, or other security incidents. Immediate steps include reviewing the author's name, repository, head reference, and commit message, and investigating any related artifacts and processes. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request." +action.escu.eli5 = The following analytic detects pull requests from unknown users on GitHub. It uses a Splunk query to identify pull requests where the user ID is not specified and cross-references these with a known users lookup table. This activity is significant because pull requests from unknown users can introduce malicious code or unauthorized changes to repositories. If confirmed malicious, this could lead to unauthorized code changes, data breaches, or other security incidents. Immediate steps include reviewing the author's name, repository, head reference, and commit message, and investigating any related artifacts and processes. action.escu.how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - GitHub Pull Request from Unknown User - Rule action.escu.search_type = detection @@ -10641,7 +10585,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GitHub Pull Request from Unknown User - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 13"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d7b9100-8878-4404-914e-ca5e551a641e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d7b9100-8878-4404-914e-ca5e551a641e", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10657,14 +10601,14 @@ search = `github` check_suite.pull_requests{}.id=* | stats count by check_suite. [ESCU - Gsuite Drive Share In External Email - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This search is to detect suspicious google drive or google docs files shared outside or externally. This behavior might be a good hunting query to monitor exfitration of data made by an attacker or insider to a targetted machine. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects Google Drive or Google Docs files shared externally from an internal domain. It leverages GSuite Drive logs, extracting and comparing the source and destination email domains to identify external sharing. This activity is significant as it may indicate potential data exfiltration by an attacker or insider. If confirmed malicious, this could lead to unauthorized access to sensitive information, data leakage, and potential compliance violations. Monitoring this behavior helps in early detection and mitigation of data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567.002", "T1567"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect suspicious google drive or google docs files shared outside or externally. This behavior might be a good hunting query to monitor exfitration of data made by an attacker or insider to a targetted machine. +action.escu.eli5 = The following analytic detects Google Drive or Google Docs files shared externally from an internal domain. It leverages GSuite Drive logs, extracting and comparing the source and destination email domains to identify external sharing. This activity is significant as it may indicate potential data exfiltration by an attacker or insider. If confirmed malicious, this could lead to unauthorized access to sensitive information, data leakage, and potential compliance violations. Monitoring this behavior helps in early detection and mitigation of data breaches. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`. action.escu.known_false_positives = network admin or normal user may share files to customer and external team. -action.escu.creation_date = 2021-08-16 -action.escu.modification_date = 2021-08-16 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Gsuite Drive Share In External Email - Rule action.escu.search_type = detection @@ -10682,7 +10626,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Gsuite Drive Share In External Email - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops", "Insider Threat"], "cis20": ["CIS 10"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567.002", "T1567"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f6ee02d6-fea0-11eb-b2c2-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f6ee02d6-fea0-11eb-b2c2-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10698,14 +10642,14 @@ search = `gsuite_drive` NOT (email IN("", "null")) | rex field=parameters.owner [ESCU - GSuite Email Suspicious Attachment - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious attachment file extension in Gsuite email that may related to spear phishing attack. This file type is commonly used by malware to lure user to click on it to execute malicious code to compromised targetted machine. But this search can also catch some normal files related to this file type that maybe send by employee or network admin. +description = The following analytic detects suspicious attachment file extensions in GSuite emails, potentially indicating a spear-phishing attack. It leverages GSuite Gmail logs to identify emails with attachments having file extensions commonly associated with malware, such as .exe, .bat, and .js. This activity is significant as these file types are often used to deliver malicious payloads, posing a risk of compromising targeted machines. If confirmed malicious, this could lead to unauthorized code execution, data breaches, or further network infiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a suspicious attachment file extension in Gsuite email that may related to spear phishing attack. This file type is commonly used by malware to lure user to click on it to execute malicious code to compromised targetted machine. But this search can also catch some normal files related to this file type that maybe send by employee or network admin. +action.escu.eli5 = The following analytic detects suspicious attachment file extensions in GSuite emails, potentially indicating a spear-phishing attack. It leverages GSuite Gmail logs to identify emails with attachments having file extensions commonly associated with malware, such as .exe, .bat, and .js. This activity is significant as these file types are often used to deliver malicious payloads, posing a risk of compromising targeted machines. If confirmed malicious, this could lead to unauthorized code execution, data breaches, or further network infiltration. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. action.escu.known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack. -action.escu.creation_date = 2021-08-16 -action.escu.modification_date = 2021-08-16 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - GSuite Email Suspicious Attachment - Rule action.escu.search_type = detection @@ -10723,7 +10667,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - GSuite Email Suspicious Attachment - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6d663014-fe92-11eb-ab07-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6d663014-fe92-11eb-ab07-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10739,14 +10683,14 @@ search = `gsuite_gmail` "attachment{}.file_extension_type" IN ("pl", "py", "rb", [ESCU - Gsuite Email Suspicious Subject With Attachment - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a gsuite email contains suspicious subject having known file type used in spear phishing. This technique is a common and effective entry vector of attacker to compromise a network by luring the user to click or execute the suspicious attachment send from external email account because of the effective social engineering of subject related to delivery, bank and so on. On the other hand this detection may catch a normal email traffic related to legitimate transaction so better to check the email sender, spelling and etc. avoid click link or opening the attachment if you are not expecting this type of e-mail. +description = The following analytic identifies Gsuite emails with suspicious subjects and attachments commonly used in spear phishing attacks. It leverages Gsuite email logs, focusing on specific keywords in the subject line and known malicious file types in attachments. This activity is significant for a SOC as spear phishing is a prevalent method for initial compromise, often leading to further malicious actions. If confirmed malicious, this activity could result in unauthorized access, data exfiltration, or further malware deployment, posing a significant risk to the organization's security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a gsuite email contains suspicious subject having known file type used in spear phishing. This technique is a common and effective entry vector of attacker to compromise a network by luring the user to click or execute the suspicious attachment send from external email account because of the effective social engineering of subject related to delivery, bank and so on. On the other hand this detection may catch a normal email traffic related to legitimate transaction so better to check the email sender, spelling and etc. avoid click link or opening the attachment if you are not expecting this type of e-mail. +action.escu.eli5 = The following analytic identifies Gsuite emails with suspicious subjects and attachments commonly used in spear phishing attacks. It leverages Gsuite email logs, focusing on specific keywords in the subject line and known malicious file types in attachments. This activity is significant for a SOC as spear phishing is a prevalent method for initial compromise, often leading to further malicious actions. If confirmed malicious, this activity could result in unauthorized access, data exfiltration, or further malware deployment, posing a significant risk to the organization's security. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. action.escu.known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search. -action.escu.creation_date = 2021-08-19 -action.escu.modification_date = 2021-08-19 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Gsuite Email Suspicious Subject With Attachment - Rule action.escu.search_type = detection @@ -10764,7 +10708,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Gsuite Email Suspicious Subject With Attachment - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ef3971e-00f2-11ec-b54f-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8ef3971e-00f2-11ec-b54f-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10780,14 +10724,14 @@ search = `gsuite_gmail` num_message_attachments > 0 subject IN ("*dhl*", "* ups [ESCU - Gsuite Email With Known Abuse Web Service Link - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytics is to detect a gmail containing a link that are known to be abused by malware or attacker like pastebin, telegram and discord to deliver malicious payload. This event can encounter some normal email traffic within organization and external email that normally using this application and services. +description = The following analytic detects emails in Gsuite containing links to known abuse web services such as Pastebin, Telegram, and Discord. It leverages Gsuite Gmail logs to identify emails with these specific domains in their links. This activity is significant because these services are commonly used by attackers to deliver malicious payloads. If confirmed malicious, this could lead to the delivery of malware, phishing attacks, or other harmful activities, potentially compromising sensitive information or systems within the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytics is to detect a gmail containing a link that are known to be abused by malware or attacker like pastebin, telegram and discord to deliver malicious payload. This event can encounter some normal email traffic within organization and external email that normally using this application and services. +action.escu.eli5 = The following analytic detects emails in Gsuite containing links to known abuse web services such as Pastebin, Telegram, and Discord. It leverages Gsuite Gmail logs to identify emails with these specific domains in their links. This activity is significant because these services are commonly used by attackers to deliver malicious payloads. If confirmed malicious, this could lead to the delivery of malware, phishing attacks, or other harmful activities, potentially compromising sensitive information or systems within the organization. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. action.escu.known_false_positives = normal email contains this link that are known application within the organization or network can be catched by this detection. -action.escu.creation_date = 2021-08-23 -action.escu.modification_date = 2021-08-23 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Gsuite Email With Known Abuse Web Service Link - Rule action.escu.search_type = detection @@ -10805,7 +10749,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Gsuite Email With Known Abuse Web Service Link - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8630aa22-042b-11ec-af39-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8630aa22-042b-11ec-af39-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10821,14 +10765,14 @@ search = `gsuite_gmail` "link_domain{}" IN ("*pastebin.com*", "*discord*", "*tel [ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious outbound e-mail from internal email to external email domain. This can be a good hunting query to monitor insider or outbound email traffic for not common domain e-mail. The idea is to parse the domain of destination email check if there is a minimum outbound traffic < 20 with attachment. +description = The following analytic detects outbound emails with attachments sent from an internal email domain to an external domain. It leverages Gsuite Gmail logs, parsing the source and destination email domains, and flags emails with fewer than 20 outbound instances. This activity is significant as it may indicate potential data exfiltration or insider threats. If confirmed malicious, an attacker could use this method to exfiltrate sensitive information, leading to data breaches and compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a suspicious outbound e-mail from internal email to external email domain. This can be a good hunting query to monitor insider or outbound email traffic for not common domain e-mail. The idea is to parse the domain of destination email check if there is a minimum outbound traffic < 20 with attachment. +action.escu.eli5 = The following analytic detects outbound emails with attachments sent from an internal email domain to an external domain. It leverages Gsuite Gmail logs, parsing the source and destination email domains, and flags emails with fewer than 20 outbound instances. This activity is significant as it may indicate potential data exfiltration or insider threats. If confirmed malicious, an attacker could use this method to exfiltrate sensitive information, leading to data breaches and compliance violations. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. action.escu.known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack. -action.escu.creation_date = 2024-03-25 -action.escu.modification_date = 2024-03-25 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule action.escu.search_type = detection @@ -10841,7 +10785,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops", "Insider Threat"], "cis20": ["CIS 10"], "confidence": 30, "impact": 30, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc4dc3a8-ff54-11eb-8bf7-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc4dc3a8-ff54-11eb-8bf7-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10893,14 +10837,14 @@ search = `gsuite_calendar` |bin span=5m _time |rename parameters.* as * |search [ESCU - Gsuite Suspicious Shared File Name - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a shared file in google drive with suspicious file name that are commonly used by spear phishing campaign. This technique is very popular to lure the user by running a malicious document or click a malicious link within the shared file that will redirected to malicious website. This detection can also catch some normal email communication between organization and its external customer. +description = The following analytic detects shared files in Google Drive with suspicious filenames commonly used in spear phishing campaigns. It leverages GSuite Drive logs to identify documents with titles that include keywords like "dhl," "ups," "invoice," and "shipment." This activity is significant because such filenames are often used to lure users into opening malicious documents or clicking harmful links. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further compromise of the user's system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a shared file in google drive with suspicious file name that are commonly used by spear phishing campaign. This technique is very popular to lure the user by running a malicious document or click a malicious link within the shared file that will redirected to malicious website. This detection can also catch some normal email communication between organization and its external customer. +action.escu.eli5 = The following analytic detects shared files in Google Drive with suspicious filenames commonly used in spear phishing campaigns. It leverages GSuite Drive logs to identify documents with titles that include keywords like "dhl," "ups," "invoice," and "shipment." This activity is significant because such filenames are often used to lure users into opening malicious documents or clicking harmful links. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further compromise of the user's system. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`. action.escu.known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search -action.escu.creation_date = 2021-08-23 -action.escu.modification_date = 2021-08-23 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Gsuite Suspicious Shared File Name - Rule action.escu.search_type = detection @@ -10918,7 +10862,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Gsuite Suspicious Shared File Name - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07eed200-03f5-11ec-98fb-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07eed200-03f5-11ec-98fb-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10934,14 +10878,14 @@ search = `gsuite_drive` parameters.owner_is_team_drive=false "parameters.doc_tit [ESCU - High Number of Login Failures from a single source - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. Specifically, it identifies scenarios where there are more than 10 unsuccessful login attempts within a short time frame. The detection leverages Office365 management activity logs, specifically the AzureActiveDirectoryStsLogon records from the AzureActiveDirectory workload. It aggregates these logs in 5-minute intervals to count the number of failed login attempts and associates them with the originating source IP address. Multiple failed login attempts from a single source can be indicative of brute-force attacks, password spraying, or other malicious authentication attempts. Identifying and responding to these patterns promptly can prevent unauthorized access and potential breaches. If this detection represents a true positive, an attacker might be attempting to gain unauthorized access to an Office365 account. Successful compromise could lead to unauthorized access to sensitive data, potential lateral movement within the organization, or further malicious activities using the compromised account. +description = The following analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. It leverages Office365 management activity logs, specifically AzureActiveDirectoryStsLogon records, aggregating these logs in 5-minute intervals to count failed login attempts. This activity is significant as it may indicate brute-force attacks or password spraying, which are critical to monitor. If confirmed malicious, an attacker could gain unauthorized access to Office365 accounts, leading to potential data breaches, lateral movement within the organization, or further malicious activities using the compromised account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.001", "T1110"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. Specifically, it identifies scenarios where there are more than 10 unsuccessful login attempts within a short time frame. The detection leverages Office365 management activity logs, specifically the AzureActiveDirectoryStsLogon records from the AzureActiveDirectory workload. It aggregates these logs in 5-minute intervals to count the number of failed login attempts and associates them with the originating source IP address. Multiple failed login attempts from a single source can be indicative of brute-force attacks, password spraying, or other malicious authentication attempts. Identifying and responding to these patterns promptly can prevent unauthorized access and potential breaches. If this detection represents a true positive, an attacker might be attempting to gain unauthorized access to an Office365 account. Successful compromise could lead to unauthorized access to sensitive data, potential lateral movement within the organization, or further malicious activities using the compromised account. +action.escu.eli5 = The following analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. It leverages Office365 management activity logs, specifically AzureActiveDirectoryStsLogon records, aggregating these logs in 5-minute intervals to count failed login attempts. This activity is significant as it may indicate brute-force attacks or password spraying, which are critical to monitor. If confirmed malicious, an attacker could gain unauthorized access to Office365 accounts, leading to potential data breaches, lateral movement within the organization, or further malicious activities using the compromised account. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. Adjust the threshold value to suit the specific environment, as environments with naturally higher login failures might generate false positives at a lower threshold. action.escu.known_false_positives = An Ip address with more than 10 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application. -action.escu.creation_date = 2020-12-16 -action.escu.modification_date = 2020-12-16 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - High Number of Login Failures from a single source - Rule action.escu.search_type = detection @@ -10959,7 +10903,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - High Number of Login Failures from a single source - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.001", "T1110"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7f398cfb-918d-41f4-8db8-2e2474e02222", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7f398cfb-918d-41f4-8db8-2e2474e02222", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -10975,14 +10919,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation=User [ESCU - Kubernetes Abuse of Secret by Unusual Location - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by country. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests by country. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by country. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests by country. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-06 -action.escu.modification_date = 2023-12-06 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Abuse of Secret by Unusual Location - Rule action.escu.search_type = detection @@ -11000,7 +10944,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Abuse of Secret by Unusual Location - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "40a064c1-4ec1-4381-9e35-61192ba8ef82", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "40a064c1-4ec1-4381-9e35-61192ba8ef82", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11011,19 +10955,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=secrets verb=get | iplocation sourceIPs{} | fillnull | search NOT `kube_allowed_locations` | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb City Country | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_location_filter` +search = `kube_audit` objectRef.resource=secrets verb=get | iplocation sourceIPs{} | fillnull | search NOT `kube_allowed_locations` | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb City Country | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_location_filter` [ESCU - Kubernetes Abuse of Secret by Unusual User Agent - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user agent. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user agents. This activity is significant for a SOC because Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of critical information. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user agent. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user agents. This activity is significant for a SOC because Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of critical information. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-06 -action.escu.modification_date = 2023-12-06 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Abuse of Secret by Unusual User Agent - Rule action.escu.search_type = detection @@ -11041,7 +10985,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Abuse of Secret by Unusual User Agent - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "096ab390-05ca-462c-884e-343acd5b9240", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "096ab390-05ca-462c-884e-343acd5b9240", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11052,19 +10996,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_agents` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_agent_filter` +search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_agents` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_agent_filter` [ESCU - Kubernetes Abuse of Secret by Unusual User Group - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user group. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests and user groups. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user group. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests and user groups. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys. If confirmed malicious, this behavior could indicate an attacker attempting to exfiltrate or misuse these secrets, potentially leading to unauthorized access to sensitive systems or data. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-06 -action.escu.modification_date = 2023-12-06 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Abuse of Secret by Unusual User Group - Rule action.escu.search_type = detection @@ -11082,7 +11026,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Abuse of Secret by Unusual User Group - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b6f45bbc-4ea9-4068-b3bc-0477f6997ae2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b6f45bbc-4ea9-4068-b3bc-0477f6997ae2", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11093,19 +11037,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_groups` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_group_filter` +search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_groups` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_group_filter` [ESCU - Kubernetes Abuse of Secret by Unusual User Name - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user name. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user names. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of sensitive information. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user name. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user names. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of sensitive information. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-06 -action.escu.modification_date = 2023-12-06 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Abuse of Secret by Unusual User Name - Rule action.escu.search_type = detection @@ -11123,7 +11067,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Abuse of Secret by Unusual User Name - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "df6e9cae-5257-4a34-8f3a-df49fa0f5c46", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "df6e9cae-5257-4a34-8f3a-df49fa0f5c46", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11134,19 +11078,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_names` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_name_filter` +search = `kube_audit` objectRef.resource=secrets verb=get | search NOT `kube_allowed_user_names` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_abuse_of_secret_by_unusual_user_name_filter` [ESCU - Kubernetes Access Scanning - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities. The analytic detects this behavior by monitoring Kubernetes audit logs for patterns indicative of scanning, such as repeated failed access attempts or unusual API requests. This behavior is worth identifying for a SOC as it could indicate an attackers preliminary step in an attack, aiming to gather information about the system to find potential vulnerabilities. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities by monitoring Kubernetes audit logs for repeated failed access attempts or unusual API requests. This activity is significant for a SOC as it may indicate an attacker's preliminary reconnaissance to gather information about the system. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities. The analytic detects this behavior by monitoring Kubernetes audit logs for patterns indicative of scanning, such as repeated failed access attempts or unusual API requests. This behavior is worth identifying for a SOC as it could indicate an attackers preliminary step in an attack, aiming to gather information about the system to find potential vulnerabilities. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities by monitoring Kubernetes audit logs for repeated failed access attempts or unusual API requests. This activity is significant for a SOC as it may indicate an attacker's preliminary reconnaissance to gather information about the system. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, posing a severe security risk. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-07 -action.escu.modification_date = 2023-12-07 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Access Scanning - Rule action.escu.search_type = detection @@ -11164,7 +11108,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Access Scanning - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2f4abe6d-5991-464d-8216-f90f42999764", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2f4abe6d-5991-464d-8216-f90f42999764", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11175,23 +11119,21 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} | stats count values(userAgent) as userAgent values(user.username) as user.username values(user.groups{}) as user.groups{} values(verb) as verb values(requestURI) as requestURI values(responseStatus.code) as responseStatus.code values(responseStatus.message) as responseStatus.message values(responseStatus.reason) as responseStatus.reason values(responseStatus.status) as responseStatus.status by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_access_scanning_filter` +search = `kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} | stats count values(userAgent) as userAgent values(user.username) as user.username values(user.groups{}) as user.groups{} values(verb) as verb values(requestURI) as requestURI values(responseStatus.code) as responseStatus.code values(responseStatus.message) as responseStatus.message values(responseStatus.reason) as responseStatus.reason values(responseStatus.status) as responseStatus.status by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_access_scanning_filter` [ESCU - Kubernetes Anomalous Inbound Network Activity from Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This detection detects inbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly.This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for destination (receiving) workload process pairs over the last 1 hour, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high inbound network activity. Anomalies in inbound network traffic may suggest that the container is receiving unexpected or unauthorized data, potentially indicative of a breach, a vulnerability exploitation attempt, an attempt to overload the service, or propagation of malware. Successful compromise of a containerised application resulting in the ability to upload data, can result in installation of command and control software or other malware, data integrity damage, container escape, and further compromise of the environment. Additionally this kind of activity may result in resource contention, performance degradation and disruption to the normal operation of the environment. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies anomalous inbound network traffic volumes from processes within containerized workloads. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days. This activity is significant as it may indicate unauthorized data reception, potential breaches, vulnerability exploitation, or malware propagation. If confirmed malicious, it could lead to command and control installation, data integrity damage, container escape, and further environment compromise. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection detects inbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly.This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for destination (receiving) workload process pairs over the last 1 hour, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high inbound network activity. Anomalies in inbound network traffic may suggest that the container is receiving unexpected or unauthorized data, potentially indicative of a breach, a vulnerability exploitation attempt, an attempt to overload the service, or propagation of malware. Successful compromise of a containerised application resulting in the ability to upload data, can result in installation of command and control software or other malware, data integrity damage, container escape, and further compromise of the environment. Additionally this kind of activity may result in resource contention, performance degradation and disruption to the normal operation of the environment. +action.escu.eli5 = The following analytic identifies anomalous inbound network traffic volumes from processes within containerized workloads. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days. This activity is significant as it may indicate unauthorized data reception, potential breaches, vulnerability exploitation, or malware propagation. If confirmed malicious, it could lead to command and control installation, data integrity damage, container escape, and further environment compromise. action.escu.how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-10 -action.escu.modification_date = 2024-01-10 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Anomalous Inbound Network Activity from Process - Rule action.escu.search_type = detection @@ -11209,7 +11151,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Anomalous Inbound Network Activity from Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10442d8b-0701-4c25-911d-d67b906e713c", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10442d8b-0701-4c25-911d-d67b906e713c", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11220,15 +11162,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name dest.workload.name dest.process.name span=10s | eval key='dest.workload.name' + ":" + 'dest.process.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by dest.workload.name dest.process.name | eval key='dest.workload.name' + ":" + 'dest.process.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name dest.workload.name dest.process.name | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_inbound_network_activity_from_process_filter` +search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name dest.workload.name dest.process.name span=10s | eval key='dest.workload.name' + ":" + 'dest.process.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by dest.workload.name dest.process.name | eval key='dest.workload.name' + ":" + 'dest.process.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name dest.workload.name dest.process.name | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_inbound_network_activity_from_process_filter` [ESCU - Kubernetes Anomalous Inbound Outbound Network IO - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, financial losses, and reputational damage. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies high inbound or outbound network I/O anomalies in Kubernetes containers. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. A lookup table with average and standard deviation values for network I/O is used to detect anomalies persisting over a 1-hour period. This activity is significant as it may indicate data exfiltration, command and control communication, or unauthorized data transfers. If confirmed malicious, it could lead to data breaches, service outages, financial losses, and reputational damage. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, financial losses, and reputational damage. +action.escu.eli5 = The following analytic identifies high inbound or outbound network I/O anomalies in Kubernetes containers. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. A lookup table with average and standard deviation values for network I/O is used to detect anomalies persisting over a 1-hour period. This activity is significant as it may indicate data exfiltration, command and control communication, or unauthorized data transfers. If confirmed malicious, it could lead to data breaches, service outages, financial losses, and reputational damage. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -11242,8 +11184,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-19 -action.escu.modification_date = 2023-12-19 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Anomalous Inbound Outbound Network IO - Rule action.escu.search_type = detection @@ -11261,7 +11203,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Anomalous Inbound Outbound Network IO - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4f3b0c97-657e-4547-a89a-9a50c656e3cd", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4f3b0c97-657e-4547-a89a-9a50c656e3cd", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11272,15 +11214,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace('k8s.pod.name', "-\w{5}$$|-[abcdef0-9]{8,10}-\w{5}$$", "") | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by k8s.cluster.name k8s.node.name k8s.pod.name service _time | eval key = 'k8s.cluster.name' + ":" + 'service' | lookup k8s_container_network_io_baseline key | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service | rename service as k8s.service | where count > 5 | rename k8s.node.name as host | `kubernetes_anomalous_inbound_outbound_network_traffic_io_filter` +search = | mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace('k8s.pod.name', "-\w{5}$$|-[abcdef0-9]{8,10}-\w{5}$$", "") | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by k8s.cluster.name k8s.node.name k8s.pod.name service _time | eval key = 'k8s.cluster.name' + ":" + 'service' | lookup k8s_container_network_io_baseline key | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service | rename service as k8s.service | where count > 5 | rename k8s.node.name as host | `kubernetes_anomalous_inbound_outbound_network_io_filter` [ESCU - Kubernetes Anomalous Inbound to Outbound Network IO Ratio - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies significant changes in network communication behavior within Kubernetes containers by examining the inbound to outbound network IO ratios. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. Anomalies are detected using a lookup table containing average and standard deviation values for network IO, triggering an event if the anomaly persists for over an hour. This activity is significant as it may indicate data exfiltration, command and control communication, or compromised container behavior. If confirmed malicious, it could lead to data breaches, service outages, and unauthorized access within the Kubernetes cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster. +action.escu.eli5 = The following analytic identifies significant changes in network communication behavior within Kubernetes containers by examining the inbound to outbound network IO ratios. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. Anomalies are detected using a lookup table containing average and standard deviation values for network IO, triggering an event if the anomaly persists for over an hour. This activity is significant as it may indicate data exfiltration, command and control communication, or compromised container behavior. If confirmed malicious, it could lead to data breaches, service outages, and unauthorized access within the Kubernetes cluster. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -11294,8 +11236,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-19 -action.escu.modification_date = 2023-12-19 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Anomalous Inbound to Outbound Network IO Ratio - Rule action.escu.search_type = detection @@ -11313,7 +11255,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Anomalous Inbound to Outbound Network IO Ratio - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d8f6e3f-39df-46d8-a9d4-96173edc501f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9d8f6e3f-39df-46d8-a9d4-96173edc501f", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11324,23 +11266,21 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace('k8s.pod.name', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") | eval key = 'k8s.cluster.name' + ":" + 'service' | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by key service k8s.cluster.name k8s.pod.name k8s.node.name _time | eval inbound:outbound = inbound_network_io/outbound_network_io | eval outbound:inbound = outbound_network_io/inbound_network_io | fields - *network_io | lookup k8s_container_network_io_ratio_baseline key | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> ratio higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service | rename service as k8s.service | where count > 5 | rename k8s.node.name as host | `kubernetes_anomalous_inbound_to_outbound_network_io_ratio_filter` +search = | mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s | eval service = replace('k8s.pod.name', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") | eval key = 'k8s.cluster.name' + ":" + 'service' | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by key service k8s.cluster.name k8s.pod.name k8s.node.name _time | eval inbound:outbound = inbound_network_io/outbound_network_io | eval outbound:inbound = outbound_network_io/inbound_network_io | fields - *network_io | lookup k8s_container_network_io_ratio_baseline key | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> ratio higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service | rename service as k8s.service | where count > 5 | rename k8s.node.name as host | `kubernetes_anomalous_inbound_to_outbound_network_io_ratio_filter` [ESCU - Kubernetes Anomalous Outbound Network Activity from Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This detection detects outbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for source (transmitting) workload process pairs over the last 1 hout, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high outbound network activity. Anonymously high outbound network traffic from a process running in a container is a potential indication of data exfiltration, or an indication that the process has been modified. Anomalously high outbound network activity from a process running within a container suggests the potential compromise, which may lead to unauthorized data exfiltration, communication with malicious entities, or the propagation of malware to external systems. The compromised container could also serve as a pivot point for further attacks within the containerized environment. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies anomalously high outbound network activity from processes running within containerized workloads in a Kubernetes environment. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average metrics over the past 30 days. This activity is significant as it may indicate data exfiltration, process modification, or container compromise. If confirmed malicious, it could lead to unauthorized data exfiltration, communication with malicious entities, or further attacks within the containerized environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection detects outbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for source (transmitting) workload process pairs over the last 1 hout, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high outbound network activity. Anonymously high outbound network traffic from a process running in a container is a potential indication of data exfiltration, or an indication that the process has been modified. Anomalously high outbound network activity from a process running within a container suggests the potential compromise, which may lead to unauthorized data exfiltration, communication with malicious entities, or the propagation of malware to external systems. The compromised container could also serve as a pivot point for further attacks within the containerized environment. +action.escu.eli5 = The following analytic identifies anomalously high outbound network activity from processes running within containerized workloads in a Kubernetes environment. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average metrics over the past 30 days. This activity is significant as it may indicate data exfiltration, process modification, or container compromise. If confirmed malicious, it could lead to unauthorized data exfiltration, communication with malicious entities, or further attacks within the containerized environment. action.escu.how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-10 -action.escu.modification_date = 2024-01-10 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Anomalous Outbound Network Activity from Process - Rule action.escu.search_type = detection @@ -11358,7 +11298,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Anomalous Outbound Network Activity from Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dd6afee6-e0a3-4028-a089-f47dd2842c22", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dd6afee6-e0a3-4028-a089-f47dd2842c22", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11369,23 +11309,21 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name source.process.name span=10s | eval key='source.workload.name' + ":" + 'source.process.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name source.process.name | eval key='source.workload.name' + ":" + 'source.process.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name source.workload.name source.process.name | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_outbound_network_activity_from_process_filter` +search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name source.process.name span=10s | eval key='source.workload.name' + ":" + 'source.process.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name source.process.name | eval key='source.workload.name' + ":" + 'source.process.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name source.workload.name source.process.name | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_outbound_network_activity_from_process_filter` [ESCU - Kubernetes Anomalous Traffic on Network Edge - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This detection detects network traffic volume anomalies between workloads in a microservices hosted application, or between a workload and the outside world if the workload is shown as (unknown). This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics between workloads over the last 1 hour, with the average of those metrics over the last 30 days in order to detect any anonymously high inbound or outbound network activity. Unexpected spikes in network traffic may signify unauthorized data transfers, or abnormal behavior within the microservices ecosystem. Such activity might signify data exfiltration, unauthorized lateral movement, within the microservices environment. If a bad actor is responsible for this traffic they could compromise additional services or extract sensitive data, potentially leading to data breaches. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies anomalous network traffic volumes between Kubernetes workloads or between a workload and external sources. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days to identify significant deviations. This activity is significant as unexpected spikes may indicate unauthorized data transfers or lateral movement. If confirmed malicious, it could lead to data exfiltration or compromise of additional services, potentially resulting in data breaches. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection detects network traffic volume anomalies between workloads in a microservices hosted application, or between a workload and the outside world if the workload is shown as (unknown). This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics between workloads over the last 1 hour, with the average of those metrics over the last 30 days in order to detect any anonymously high inbound or outbound network activity. Unexpected spikes in network traffic may signify unauthorized data transfers, or abnormal behavior within the microservices ecosystem. Such activity might signify data exfiltration, unauthorized lateral movement, within the microservices environment. If a bad actor is responsible for this traffic they could compromise additional services or extract sensitive data, potentially leading to data breaches. +action.escu.eli5 = The following analytic identifies anomalous network traffic volumes between Kubernetes workloads or between a workload and external sources. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares recent network metrics (tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets) over the last hour with the average over the past 30 days to identify significant deviations. This activity is significant as unexpected spikes may indicate unauthorized data transfers or lateral movement. If confirmed malicious, it could lead to data exfiltration or compromise of additional services, potentially resulting in data breaches. action.escu.how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-10 -action.escu.modification_date = 2024-01-10 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Anomalous Traffic on Network Edge - Rule action.escu.search_type = detection @@ -11403,7 +11341,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Anomalous Traffic on Network Edge - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "886c7e51-2ea1-425d-8705-faaca5a64cc6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "886c7e51-2ea1-425d-8705-faaca5a64cc6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11414,19 +11352,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name span=10s | eval key='source.workload.name' + ":" + 'dest.workload.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval key='source.workload.name' + ":" + 'dest.workload.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name source.workload.name dest.workload.name | rename service as k8s.service | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_traffic_on_network_edge_filter` +search = | mstats avg(tcp.*) as tcp.* avg(udp.*) as udp.* where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name span=10s | eval key='source.workload.name' + ":" + 'dest.workload.name' | join type=left key [ mstats avg(tcp.*) as avg_tcp.* avg(udp.*) as avg_udp.* stdev(tcp.*) as stdev_tcp.* avg(udp.*) as stdev_udp.* where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval key='source.workload.name' + ":" + 'dest.workload.name' ] | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 3 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | fillnull | eval anomalies = split(replace(anomalies, ",\s$$$$", "") ,", ") | where anomalies!="" | stats count(anomalies) as count values(anomalies) as anomalies by k8s.cluster.name source.workload.name dest.workload.name | rename service as k8s.service | where count > 5 | rename k8s.cluster.name as host | `kubernetes_anomalous_traffic_on_network_edge_filter` [ESCU - Kubernetes AWS detect suspicious kubectl calls - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring for API calls from users who have not provided any token or password in their request. This is a significant behavior to identify for a SOC as it indicates a severe misconfiguration that allows unfettered access to a cluster with no traceability to a user or service. The impact of such an attack could be substantial, potentially granting an attacker access to sensitive data or control over the cluster. This detection rule is crucial for maintaining the security and integrity of your Kubernetes infrastructure. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring API calls from users who have not provided any token or password in their request, using data from `kube_audit` logs. This activity is significant for a SOC as it indicates a severe misconfiguration, allowing unfettered access to the cluster with no traceability. If confirmed malicious, an attacker could gain access to sensitive data or control over the cluster, posing a substantial security risk. action.escu.mappings = {"cis20": ["CIS 10"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring for API calls from users who have not provided any token or password in their request. This is a significant behavior to identify for a SOC as it indicates a severe misconfiguration that allows unfettered access to a cluster with no traceability to a user or service. The impact of such an attack could be substantial, potentially granting an attacker access to sensitive data or control over the cluster. This detection rule is crucial for maintaining the security and integrity of your Kubernetes infrastructure. +action.escu.eli5 = The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring API calls from users who have not provided any token or password in their request, using data from `kube_audit` logs. This activity is significant for a SOC as it indicates a severe misconfiguration, allowing unfettered access to the cluster with no traceability. If confirmed malicious, an attacker could gain access to sensitive data or control over the cluster, posing a substantial security risk. action.escu.how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs. action.escu.known_false_positives = Kubectl calls are not malicious by nature. However source IP, verb and Object can reveal potential malicious activity, specially anonymous suspicious IPs and sensitive objects such as configmaps or secrets -action.escu.creation_date = 2023-12-19 -action.escu.modification_date = 2023-12-19 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes AWS detect suspicious kubectl calls - Rule action.escu.search_type = detection @@ -11444,7 +11382,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes AWS detect suspicious kubectl calls - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "042a3d32-8318-4763-9679-09db2644a8f2", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "042a3d32-8318-4763-9679-09db2644a8f2", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11460,14 +11398,14 @@ search = `kube_audit` user.username="system:anonymous" user.groups{} IN ("system [ESCU - Kubernetes Create or Update Privileged Pod - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of privileged pods in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation of pods with root privileges. This behavior is worth identifying for a SOC as it could potentially allow an attacker to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +description = The following analytic detects the creation or update of privileged pods in Kubernetes. It identifies this activity by monitoring Kubernetes Audit logs for pod configurations that include root privileges. This behavior is significant for a SOC as it could indicate an attempt to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, data breaches, and service disruptions, posing a severe threat to the environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of privileged pods in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation of pods with root privileges. This behavior is worth identifying for a SOC as it could potentially allow an attacker to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +action.escu.eli5 = The following analytic detects the creation or update of privileged pods in Kubernetes. It identifies this activity by monitoring Kubernetes Audit logs for pod configurations that include root privileges. This behavior is significant for a SOC as it could indicate an attempt to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, data breaches, and service disruptions, posing a severe threat to the environment. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-14 -action.escu.modification_date = 2023-12-14 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Create or Update Privileged Pod - Rule action.escu.search_type = detection @@ -11485,7 +11423,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Create or Update Privileged Pod - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3c6bd734-334d-4818-ae7c-5234313fc5da", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3c6bd734-334d-4818-ae7c-5234313fc5da", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11496,19 +11434,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"privileged\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_create_or_update_privileged_pod_filter` +search = `kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"privileged\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_create_or_update_privileged_pod_filter` [ESCU - Kubernetes Cron Job Creation - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a Kubernetes cron job, a task scheduled to run automatically at specified intervals. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a cron job. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute malicious tasks repeatedly and automatically, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +description = The following analytic detects the creation of a Kubernetes cron job, which is a task scheduled to run automatically at specified intervals. It identifies this activity by monitoring Kubernetes Audit logs for the creation events of cron jobs. This behavior is significant for a SOC as it could allow an attacker to execute malicious tasks repeatedly and automatically, posing a threat to the Kubernetes infrastructure. If confirmed malicious, this activity could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.007"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of a Kubernetes cron job, a task scheduled to run automatically at specified intervals. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a cron job. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute malicious tasks repeatedly and automatically, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +action.escu.eli5 = The following analytic detects the creation of a Kubernetes cron job, which is a task scheduled to run automatically at specified intervals. It identifies this activity by monitoring Kubernetes Audit logs for the creation events of cron jobs. This behavior is significant for a SOC as it could allow an attacker to execute malicious tasks repeatedly and automatically, posing a threat to the Kubernetes infrastructure. If confirmed malicious, this activity could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-14 -action.escu.modification_date = 2023-12-14 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Cron Job Creation - Rule action.escu.search_type = detection @@ -11526,7 +11464,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Cron Job Creation - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1053.007"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5984dbe8-572f-47d7-9251-3dff6c3f0c0d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5984dbe8-572f-47d7-9251-3dff6c3f0c0d", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11537,19 +11475,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` verb=create "objectRef.resource"=cronjobs | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.schedule requestObject.spec.jobTemplate.spec.template.spec.containers{}.image responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_cron_job_creation_filter` +search = `kube_audit` verb=create "objectRef.resource"=cronjobs | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.schedule requestObject.spec.jobTemplate.spec.template.spec.containers{}.image responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_cron_job_creation_filter` [ESCU - Kubernetes DaemonSet Deployed - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. A DaemonSet ensures the presence of a specific pod on every node in the cluster, making it an ideal avenue for persistent access. This behavior is identified by monitoring Kubernetes Audit logs for the creation of a DaemonSet. The identified behavior is worth noting for a SOC as it could potentially allow an attacker to maintain persistent access to the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +description = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. This behavior is identified by monitoring Kubernetes Audit logs for the creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, making them a potential vector for persistent access. This activity is significant for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes infrastructure. If confirmed malicious, it could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. A DaemonSet ensures the presence of a specific pod on every node in the cluster, making it an ideal avenue for persistent access. This behavior is identified by monitoring Kubernetes Audit logs for the creation of a DaemonSet. The identified behavior is worth noting for a SOC as it could potentially allow an attacker to maintain persistent access to the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information. +action.escu.eli5 = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. This behavior is identified by monitoring Kubernetes Audit logs for the creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, making them a potential vector for persistent access. This activity is significant for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes infrastructure. If confirmed malicious, it could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-14 -action.escu.modification_date = 2023-12-14 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes DaemonSet Deployed - Rule action.escu.search_type = detection @@ -11567,7 +11505,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes DaemonSet Deployed - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bf39c3a3-b191-4d42-8738-9d9797bd0c3a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bf39c3a3-b191-4d42-8738-9d9797bd0c3a", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11578,19 +11516,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` "objectRef.resource"=daemonsets verb=create | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_daemonset_deployed_filter` +search = `kube_audit` "objectRef.resource"=daemonsets verb=create | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_daemonset_deployed_filter` [ESCU - Kubernetes Falco Shell Spawned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects instances where a shell is spawned within a Kubernetes container, a behavior often indicative of an attacker gaining unauthorized access. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment, flagging when a shell is spawned in a container. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +description = The following analytic detects instances where a shell is spawned within a Kubernetes container. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment and flags when a shell is spawned. This activity is significant for a SOC as it may indicate unauthorized access, allowing an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges. If confirmed malicious, this could lead to data breaches, service disruptions, or unauthorized access to sensitive information, severely impacting the Kubernetes infrastructure's integrity and security. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects instances where a shell is spawned within a Kubernetes container, a behavior often indicative of an attacker gaining unauthorized access. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment, flagging when a shell is spawned in a container. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +action.escu.eli5 = The following analytic detects instances where a shell is spawned within a Kubernetes container. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment and flags when a shell is spawned. This activity is significant for a SOC as it may indicate unauthorized access, allowing an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges. If confirmed malicious, this could lead to data breaches, service disruptions, or unauthorized access to sensitive information, severely impacting the Kubernetes infrastructure's integrity and security. action.escu.how_to_implement = The detection is based on data that originates from Falco, a cloud native runtime security tool. Falco is designed to detect anomalous activity in your applications and is a crucial component of this detection rule. To implement this detection rule, you need to install and configure Falco in your Kubernetes environment. Once Falco is set up, it will monitor the system calls in your Kubernetes infrastructure and generate logs for any suspicious activity. These logs are then ingested by Splunk for analysis. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-13 -action.escu.modification_date = 2023-12-13 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Falco Shell Spawned - Rule action.escu.search_type = detection @@ -11608,7 +11546,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Falco Shell Spawned - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d2feef92-d54a-4a19-8306-b47c6ceba5b2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d2feef92-d54a-4a19-8306-b47c6ceba5b2", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11619,23 +11557,21 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_container_falco` "A shell was spawned in a container" | fillnull | stats count by container_image container_image_tag container_name parent proc_exepath process user | `kubernetes_falco_shell_spawned_filter` +search = `kube_container_falco` "A shell was spawned in a container" | fillnull | stats count by container_image container_image_tag container_name parent proc_exepath process user | `kubernetes_falco_shell_spawned_filter` [ESCU - Kubernetes newly seen TCP edge - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic detects TCP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies newly seen TCP communication between source and destination workload pairs within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares network activity over the last hour with the past 30 days to spot new inter-workload communications. This is significant as new connections can indicate changes in application behavior or potential security threats. If malicious, unauthorized connections could lead to data breaches, privilege escalation, lateral movement, or disruption of critical services, compromising the application's integrity, availability, and confidentiality. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects TCP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +action.escu.eli5 = The following analytic identifies newly seen TCP communication between source and destination workload pairs within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. The detection compares network activity over the last hour with the past 30 days to spot new inter-workload communications. This is significant as new connections can indicate changes in application behavior or potential security threats. If malicious, unauthorized connections could lead to data breaches, privilege escalation, lateral movement, or disruption of critical services, compromising the application's integrity, availability, and confidentiality. action.escu.how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-10 -action.escu.modification_date = 2024-01-10 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes newly seen TCP edge - Rule action.escu.search_type = detection @@ -11653,7 +11589,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes newly seen TCP edge - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "13f081d6-7052-428a-bbb0-892c79ca7c65", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "13f081d6-7052-428a-bbb0-892c79ca7c65", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11664,23 +11600,21 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" | append [ mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval current="false" ] | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host | `kubernetes_newly_seen_tcp_edge_filter` +search = | mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" | append [ mstats count(tcp.packets) as tcp.packets_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval current="false" ] | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host | `kubernetes_newly_seen_tcp_edge_filter` [ESCU - Kubernetes newly seen UDP edge - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic detects UDP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects UDP communication between a newly seen source and destination workload pair within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. This detection compares network activity over the last hour with the past 30 days to identify new inter-workload communication. Such changes in network behavior can indicate potential security threats or anomalies. If confirmed malicious, unauthorized connections may enable attackers to infiltrate the application ecosystem, leading to data breaches, privilege escalation, lateral movement, or disruption of critical services. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects UDP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk. +action.escu.eli5 = The following analytic detects UDP communication between a newly seen source and destination workload pair within a Kubernetes cluster. It leverages Network Performance Monitoring metrics collected via an OTEL collector and pulled from Splunk Observability Cloud. This detection compares network activity over the last hour with the past 30 days to identify new inter-workload communication. Such changes in network behavior can indicate potential security threats or anomalies. If confirmed malicious, unauthorized connections may enable attackers to infiltrate the application ecosystem, leading to data breaches, privilege escalation, lateral movement, or disruption of critical services. action.escu.how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head. Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default: \ * Name sim_npm_metrics_to_metrics_index \ -* Org ID \ -* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \ * Metric Resolution 10000 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-10 -action.escu.modification_date = 2024-01-10 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes newly seen UDP edge - Rule action.escu.search_type = detection @@ -11698,7 +11632,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes newly seen UDP edge - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49b7daca-4e3c-4899-ba15-9a175e056fa9", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49b7daca-4e3c-4899-ba15-9a175e056fa9", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11709,7 +11643,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats count(udp.packets) as udp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" | append [ mstats count(udp.packets) as udp.packets_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval current="false" ] | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host | `kubernetes_newly_seen_udp_edge_filter` +search = | mstats count(udp.packets) as udp.packets_count where `kubernetes_metrics` AND earliest=-1h by k8s.cluster.name source.workload.name dest.workload.name | eval current="True" | append [ mstats count(udp.packets) as udp.packets_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by source.workload.name dest.workload.name | eval current="false" ] | eventstats values(current) as current by source.workload.name dest.workload.name | search current="true" current!="false" | rename k8s.cluster.name as host | `kubernetes_newly_seen_udp_edge_filter` [ESCU - Kubernetes Nginx Ingress LFI - Rule] action.escu = 0 @@ -11808,14 +11742,14 @@ search = `kubernetes_container_controller` | rex field=_raw "^(?\S+ [ESCU - Kubernetes Node Port Creation - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a Kubernetes node port service, an action that exposes a service to the external network. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a Node Port service. This behavior is worth identifying for a SOC as it could potentially allow an attacker to access internal services, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +description = The following analytic detects the creation of a Kubernetes NodePort service, which exposes a service to the external network. It identifies this activity by monitoring Kubernetes Audit logs for the creation of NodePort services. This behavior is significant for a SOC as it could allow an attacker to access internal services, posing a threat to the Kubernetes infrastructure's integrity and security. If confirmed malicious, this activity could lead to data breaches, service disruptions, or unauthorized access to sensitive information. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of a Kubernetes node port service, an action that exposes a service to the external network. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a Node Port service. This behavior is worth identifying for a SOC as it could potentially allow an attacker to access internal services, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information. +action.escu.eli5 = The following analytic detects the creation of a Kubernetes NodePort service, which exposes a service to the external network. It identifies this activity by monitoring Kubernetes Audit logs for the creation of NodePort services. This behavior is significant for a SOC as it could allow an attacker to access internal services, posing a threat to the Kubernetes infrastructure's integrity and security. If confirmed malicious, this activity could lead to data breaches, service disruptions, or unauthorized access to sensitive information. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-13 -action.escu.modification_date = 2023-12-13 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Node Port Creation - Rule action.escu.search_type = detection @@ -11833,7 +11767,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Node Port Creation - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d7fc865e-b8a1-4029-a960-cf4403b821b6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d7fc865e-b8a1-4029-a960-cf4403b821b6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11844,19 +11778,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` "objectRef.resource"=services verb=create requestObject.spec.type=NodePort | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.type responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_node_port_creation_filter` +search = `kube_audit` "objectRef.resource"=services verb=create requestObject.spec.type=NodePort | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind requestObject.spec.type responseStatus.code sourceIPs{} stage user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_node_port_creation_filter` [ESCU - Kubernetes Pod Created in Default Namespace - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of pods in the default, kube-system, or kube-public namespaces. It identifies this behavior by monitoring Kubernetes audit logs for pod creation events in these namespaces. This behavior is worth identifying for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Only administrators should typically create pods in the kube-system namespace, and the default and kube-public namespaces should not be used in production. The impact of the attack could be significant, as it may indicate a successful cluster breach and ongoing malicious activity. +description = The following analytic detects the creation of Kubernetes pods in the default, kube-system, or kube-public namespaces. It leverages Kubernetes audit logs to identify pod creation events within these specific namespaces. This activity is significant for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Unauthorized pod creation in these namespaces can suggest a successful cluster breach, potentially leading to privilege escalation, persistent access, or further malicious activities within the cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of pods in the default, kube-system, or kube-public namespaces. It identifies this behavior by monitoring Kubernetes audit logs for pod creation events in these namespaces. This behavior is worth identifying for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Only administrators should typically create pods in the kube-system namespace, and the default and kube-public namespaces should not be used in production. The impact of the attack could be significant, as it may indicate a successful cluster breach and ongoing malicious activity. +action.escu.eli5 = The following analytic detects the creation of Kubernetes pods in the default, kube-system, or kube-public namespaces. It leverages Kubernetes audit logs to identify pod creation events within these specific namespaces. This activity is significant for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Unauthorized pod creation in these namespaces can suggest a successful cluster breach, potentially leading to privilege escalation, persistent access, or further malicious activities within the cluster. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-19 -action.escu.modification_date = 2023-12-19 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Pod Created in Default Namespace - Rule action.escu.search_type = detection @@ -11874,7 +11808,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Pod Created in Default Namespace - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3d6b1a81-367b-42d5-a925-6ef90b6b9f1e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3d6b1a81-367b-42d5-a925-6ef90b6b9f1e", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11885,19 +11819,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=pods verb=create objectRef.namespace IN ("default", "kube-system", "kube-public") | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_pod_created_in_default_namespace_filter` +search = `kube_audit` objectRef.resource=pods verb=create objectRef.namespace IN ("default", "kube-system", "kube-public") | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_pod_created_in_default_namespace_filter` [ESCU - Kubernetes Pod With Host Network Attachment - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a pod with host network attachment in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation or update of pods with host network configuration. This behavior is worth identifying for a SOC as it could potentially allow an attacker to listen to all network traffic on the node and other compute on the network namespace, capturing secrets passed in arguments or connections to escalate their privileges. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +description = The following analytic detects the creation or update of a Kubernetes pod with host network attachment. It leverages Kubernetes Audit logs to identify pods configured with host network settings. This activity is significant for a SOC as it could allow an attacker to monitor all network traffic on the node, potentially capturing sensitive information and escalating privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, and service disruptions, severely impacting the security and integrity of the Kubernetes environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of a pod with host network attachment in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation or update of pods with host network configuration. This behavior is worth identifying for a SOC as it could potentially allow an attacker to listen to all network traffic on the node and other compute on the network namespace, capturing secrets passed in arguments or connections to escalate their privileges. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions. +action.escu.eli5 = The following analytic detects the creation or update of a Kubernetes pod with host network attachment. It leverages Kubernetes Audit logs to identify pods configured with host network settings. This activity is significant for a SOC as it could allow an attacker to monitor all network traffic on the node, potentially capturing sensitive information and escalating privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, and service disruptions, severely impacting the security and integrity of the Kubernetes environment. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-14 -action.escu.modification_date = 2023-12-14 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Pod With Host Network Attachment - Rule action.escu.search_type = detection @@ -11915,7 +11849,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Pod With Host Network Attachment - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cce357cf-43a4-494a-814b-67cea90fe990", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cce357cf-43a4-494a-814b-67cea90fe990", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11926,15 +11860,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"hostNetwork\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_pod_with_host_network_attachment_filter` +search = `kube_audit` objectRef.resource=pods verb=create OR verb=update requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration=*\"hostNetwork\":true* | fillnull | stats count values(user.groups{}) as user_groups by kind objectRef.name objectRef.namespace objectRef.resource requestObject.kind responseStatus.code sourceIPs{} stage user.username userAgent verb requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_pod_with_host_network_attachment_filter` [ESCU - Kubernetes Previously Unseen Container Image Name - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies containerised workloads that have been created using a previously unseen image. This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies the creation of containerized workloads using previously unseen images in a Kubernetes cluster. It leverages process metrics from an OTEL collector and Kubernetes cluster receiver, pulled from Splunk Observability Cloud. The detection compares container image names seen in the last hour with those from the previous 30 days. This activity is significant as unfamiliar container images may introduce vulnerabilities, malware, or misconfigurations, posing threats to the cluster's integrity. If confirmed malicious, compromised images can lead to data breaches, service disruptions, unauthorized access, and potential lateral movement within the cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies containerised workloads that have been created using a previously unseen image. This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster +action.escu.eli5 = The following analytic identifies the creation of containerized workloads using previously unseen images in a Kubernetes cluster. It leverages process metrics from an OTEL collector and Kubernetes cluster receiver, pulled from Splunk Observability Cloud. The detection compares container image names seen in the last hour with those from the previous 30 days. This activity is significant as unfamiliar container images may introduce vulnerabilities, malware, or misconfigurations, posing threats to the cluster's integrity. If confirmed malicious, compromised images can lead to data breaches, service disruptions, unauthorized access, and potential lateral movement within the cluster. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -11948,8 +11882,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Previously Unseen Container Image Name - Rule action.escu.search_type = detection @@ -11967,7 +11901,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Previously Unseen Container Image Name - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fea515a4-b1d8-4cd6-80d6-e0d71397b891", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fea515a4-b1d8-4cd6-80d6-e0d71397b891", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -11978,15 +11912,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-24h by host.name k8s.cluster.name k8s.node.name container.image.name | eval current="True" | append [mstats count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name container.image.name | eval current="false" ] | stats values(current) as current by host.name k8s.cluster.name k8s.node.name container.image.name | search current="true" AND current!="false" | rename host.name as host | `kubernetes_previously_unseen_container_image_name_filter` +search = | mstats count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-24h by host.name k8s.cluster.name k8s.node.name container.image.name | eval current="True" | append [mstats count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name container.image.name | eval current="false" ] | stats values(current) as current by host.name k8s.cluster.name k8s.node.name container.image.name | search current="true" AND current!="false" | rename host.name as host | `kubernetes_previously_unseen_container_image_name_filter` [ESCU - Kubernetes Previously Unseen Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and anomalies that could be related to unauthorized activity. New processes may be introduced in an attempt to compromise the node or gain control of the Kubernetes cluster. By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk. The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects previously unseen processes within the Kubernetes environment on master or worker nodes. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud. This detection compares processes observed in the last hour against those seen in the previous 30 days. Identifying new processes is crucial as they may indicate unauthorized activity or attempts to compromise the node. If confirmed malicious, these processes could lead to data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware, posing significant risks to the Kubernetes cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and anomalies that could be related to unauthorized activity. New processes may be introduced in an attempt to compromise the node or gain control of the Kubernetes cluster. By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk. The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity. +action.escu.eli5 = The following analytic detects previously unseen processes within the Kubernetes environment on master or worker nodes. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud. This detection compares processes observed in the last hour against those seen in the previous 30 days. Identifying new processes is crucial as they may indicate unauthorized activity or attempts to compromise the node. If confirmed malicious, these processes could lead to data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware, posing significant risks to the Kubernetes cluster. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12000,8 +11934,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Previously Unseen Process - Rule action.escu.search_type = detection @@ -12019,7 +11953,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Previously Unseen Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c8119b2f-d7f7-40be-940a-1c582870e8e2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c8119b2f-d7f7-40be-940a-1c582870e8e2", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12030,15 +11964,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name | eval current="True" | append [mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name ] | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.executable.name | where count=1 and current="True" | rename host.name as host | `kubernetes_previously_unseen_process_filter` +search = | mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name | eval current="True" | append [mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name ] | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.executable.name | where count=1 and current="True" | rename host.name as host | `kubernetes_previously_unseen_process_filter` [ESCU - Kubernetes Process Running From New Path - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software. If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies processes running from newly seen paths within a Kubernetes environment. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud using the Splunk Infrastructure Monitoring Add-on. This detection compares processes observed in the last hour with those seen over the previous 30 days. This activity is significant as it may indicate unauthorized changes, compromised nodes, or the introduction of malicious software. If confirmed malicious, it could lead to unauthorized process execution, control over critical resources, data exfiltration, privilege escalation, or malware introduction within the Kubernetes cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software. If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster. +action.escu.eli5 = The following analytic identifies processes running from newly seen paths within a Kubernetes environment. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, and data is pulled from Splunk Observability Cloud using the Splunk Infrastructure Monitoring Add-on. This detection compares processes observed in the last hour with those seen over the previous 30 days. This activity is significant as it may indicate unauthorized changes, compromised nodes, or the introduction of malicious software. If confirmed malicious, it could lead to unauthorized process execution, control over critical resources, data exfiltration, privilege escalation, or malware introduction within the Kubernetes cluster. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12052,8 +11986,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Process Running From New Path - Rule action.escu.search_type = detection @@ -12071,7 +12005,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Process Running From New Path - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "454076fb-0e9e-4adf-b93a-da132621c5e6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "454076fb-0e9e-4adf-b93a-da132621c5e6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12082,15 +12016,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name | eval current="True" | append [ mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name ] | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name process.executable.path | where count=1 and current="True" | rename host.name as host | `kubernetes_process_running_from_new_path_filter` +search = | mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name | eval current="True" | append [ mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name ] | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name process.executable.path | where count=1 and current="True" | rename host.name as host | `kubernetes_process_running_from_new_path_filter` [ESCU - Kubernetes Process with Anomalous Resource Utilisation - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies high resource utilization anomalies in Kubernetes processes. It leverages process metrics from an OTEL collector and hostmetrics receiver, fetched via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values to spot anomalies. This activity is significant as high resource utilization can indicate security threats like cryptojacking, unauthorized data exfiltration, or compromised containers. If confirmed malicious, such anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. +action.escu.eli5 = The following analytic identifies high resource utilization anomalies in Kubernetes processes. It leverages process metrics from an OTEL collector and hostmetrics receiver, fetched via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values to spot anomalies. This activity is significant as high resource utilization can indicate security threats like cryptojacking, unauthorized data exfiltration, or compromised containers. If confirmed malicious, such anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12104,8 +12038,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Process with Anomalous Resource Utilisation - Rule action.escu.search_type = detection @@ -12123,7 +12057,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Process with Anomalous Resource Utilisation - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "25ca9594-7a0d-4a95-a5e5-3228d7398ec8", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "25ca9594-7a0d-4a95-a5e5-3228d7398ec8", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12134,15 +12068,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s | eval key = 'k8s.cluster.name' + ":" + 'host.name' + ":" + 'process.executable.name' | lookup k8s_process_resource_baseline key | fillnull | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by host.name k8s.cluster.name k8s.node.name process.executable.name | sort - count | where count > 5 | rename host.name as host | `kubernetes_process_with_anomalous_resource_utilisation_filter` +search = | mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s | eval key = 'k8s.cluster.name' + ":" + 'host.name' + ":" + 'process.executable.name' | lookup k8s_process_resource_baseline key | fillnull | eval anomalies = "" | foreach stdev_* [ eval anomalies =if( '<>' > ('avg_<>' + 4 * 'stdev_<>'), anomalies + "<> higher than average by " + tostring(round(('<>' - 'avg_<>')/'stdev_<>' ,2)) + " Standard Deviations. <>=" + tostring('<>') + " avg_<>=" + tostring('avg_<>') + " 'stdev_<>'=" + tostring('stdev_<>') + ", " , anomalies) ] | eval anomalies = replace(anomalies, ",\s$", "") | where anomalies!="" | stats count values(anomalies) as anomalies by host.name k8s.cluster.name k8s.node.name process.executable.name | sort - count | where count > 5 | rename host.name as host | `kubernetes_process_with_anomalous_resource_utilisation_filter` [ESCU - Kubernetes Process with Resource Ratio Anomalies - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios. This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load. Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects anomalous changes in resource utilization ratios for processes running on a Kubernetes node. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, analyzed through Splunk Observability Cloud. The detection uses a lookup table containing average and standard deviation values for various resource ratios (e.g., CPU:memory, CPU:disk operations). Significant deviations from these baselines may indicate compromised processes, malicious activity, or misconfigurations. If confirmed malicious, this could signify a security breach, allowing attackers to manipulate workloads, potentially leading to data exfiltration or service disruption. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios. This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load. Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container. +action.escu.eli5 = The following analytic detects anomalous changes in resource utilization ratios for processes running on a Kubernetes node. It leverages process metrics collected via an OTEL collector and hostmetrics receiver, analyzed through Splunk Observability Cloud. The detection uses a lookup table containing average and standard deviation values for various resource ratios (e.g., CPU:memory, CPU:disk operations). Significant deviations from these baselines may indicate compromised processes, malicious activity, or misconfigurations. If confirmed malicious, this could signify a security breach, allowing attackers to manipulate workloads, potentially leading to data exfiltration or service disruption. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12156,8 +12090,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Process with Resource Ratio Anomalies - Rule action.escu.search_type = detection @@ -12175,7 +12109,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Process with Resource Ratio Anomalies - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0d42b295-0f1f-4183-b75e-377975f47c65", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0d42b295-0f1f-4183-b75e-377975f47c65", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12238,14 +12172,14 @@ search = `kube_objects_events` object.message IN ("Pulling image *kube-hunter*", [ESCU - Kubernetes Scanning by Unauthenticated IP Address - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection rule is designed to identify potential scanning activities within a Kubernetes environment. Scanning is a common preliminary step in an attack, where the attacker tries to gather information about the system to find potential vulnerabilities. In the context of Kubernetes, scanning could involve activities like unauthorized access attempts, probing public APIs, or trying to exploit known vulnerabilities. This rule triggers an alert when such suspicious activities are detected, helping to ensure the security of your Kubernetes infrastructure. +description = The following analytic identifies potential scanning activities within a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) from the same source IP. This activity is significant as it may indicate an attacker probing for vulnerabilities or attempting to exploit known issues. If confirmed malicious, such scanning could lead to unauthorized access, data breaches, or further exploitation of the Kubernetes infrastructure, compromising the security and integrity of the environment. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection rule is designed to identify potential scanning activities within a Kubernetes environment. Scanning is a common preliminary step in an attack, where the attacker tries to gather information about the system to find potential vulnerabilities. In the context of Kubernetes, scanning could involve activities like unauthorized access attempts, probing public APIs, or trying to exploit known vulnerabilities. This rule triggers an alert when such suspicious activities are detected, helping to ensure the security of your Kubernetes infrastructure. +action.escu.eli5 = The following analytic identifies potential scanning activities within a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) from the same source IP. This activity is significant as it may indicate an attacker probing for vulnerabilities or attempting to exploit known issues. If confirmed malicious, such scanning could lead to unauthorized access, data breaches, or further exploitation of the Kubernetes infrastructure, compromising the security and integrity of the environment. action.escu.how_to_implement = You must ingest Kubernetes audit logs. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-07 -action.escu.modification_date = 2023-12-07 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Scanning by Unauthenticated IP Address - Rule action.escu.search_type = detection @@ -12263,7 +12197,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Scanning by Unauthenticated IP Address - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f9cadf4e-df22-4f4e-a08f-9d3344c2165d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f9cadf4e-df22-4f4e-a08f-9d3344c2165d", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12274,15 +12208,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} | stats count values(userAgent) as userAgent values(user.username) as user.username values(user.groups{}) as user.groups{} values(verb) as verb values(requestURI) as requestURI values(responseStatus.code) as responseStatus.code values(responseStatus.message) as responseStatus.message values(responseStatus.reason) as responseStatus.reason values(responseStatus.status) as responseStatus.status by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_scanning_by_unauthenticated_ip_address_filter` +search = `kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403 | iplocation sourceIPs{} | stats count values(userAgent) as userAgent values(user.username) as user.username values(user.groups{}) as user.groups{} values(verb) as verb values(requestURI) as requestURI values(responseStatus.code) as responseStatus.code values(responseStatus.message) as responseStatus.message values(responseStatus.reason) as responseStatus.reason values(responseStatus.status) as responseStatus.status by sourceIPs{} Country City | where count > 5 | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_scanning_by_unauthenticated_ip_address_filter` [ESCU - Kubernetes Shell Running on Worker Node - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It leverages process metrics from an OTEL collector hostmetrics receiver, specifically process.cpu.utilization and process.memory.utilization, pulled from Splunk Observability Cloud. This activity is significant as unauthorized shell processes can indicate potential security threats, providing attackers an entry point to compromise the node and the entire Kubernetes cluster. If confirmed malicious, this activity could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks, severely compromising the cluster's security and integrity. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data. +action.escu.eli5 = The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It leverages process metrics from an OTEL collector hostmetrics receiver, specifically process.cpu.utilization and process.memory.utilization, pulled from Splunk Observability Cloud. This activity is significant as unauthorized shell processes can indicate potential security threats, providing attackers an entry point to compromise the node and the entire Kubernetes cluster. If confirmed malicious, this activity could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks, severely compromising the cluster's security and integrity. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12296,8 +12230,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Shell Running on Worker Node - Rule action.escu.search_type = detection @@ -12315,7 +12249,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Shell Running on Worker Node - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "efebf0c4-dcf4-496f-85a2-5ab7ad8fa876", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "efebf0c4-dcf4-496f-85a2-5ab7ad8fa876", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12326,15 +12260,15 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 OR process.memory.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host | `kubernetes_shell_running_on_worker_node_filter` +search = | mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 OR process.memory.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host | `kubernetes_shell_running_on_worker_node_filter` [ESCU - Kubernetes Shell Running on Worker Node with CPU Activity - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node, specifically when shell processes are consuming CPU resources. It leverages process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability Cloud via the Splunk Infrastructure Monitoring Add-on, focusing on process.cpu.utilization and process.memory.utilization. This activity is significant as unauthorized shell processes can indicate a security threat, potentially compromising the node and the entire Kubernetes cluster. If confirmed malicious, attackers could gain full control over the host's resources, leading to data theft, service disruption, privilege escalation, and further attacks within the cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach. +action.escu.eli5 = The following analytic identifies shell activity within the Kubernetes privilege scope on a worker node, specifically when shell processes are consuming CPU resources. It leverages process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability Cloud via the Splunk Infrastructure Monitoring Add-on, focusing on process.cpu.utilization and process.memory.utilization. This activity is significant as unauthorized shell processes can indicate a security threat, potentially compromising the node and the entire Kubernetes cluster. If confirmed malicious, attackers could gain full control over the host's resources, leading to data theft, service disruption, privilege escalation, and further attacks within the cluster. action.escu.how_to_implement = To implement this detection, follow these steps: \ * Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster. \ * Enable the hostmetrics/process receiver in the OTEL configuration. \ @@ -12348,8 +12282,8 @@ action.escu.how_to_implement = To implement this detection, follow these steps: * Leave all other settings at their default values. \ * Run the Search Baseline Of Kubernetes Container Network IO Ratio action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-18 -action.escu.modification_date = 2023-12-18 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Shell Running on Worker Node with CPU Activity - Rule action.escu.search_type = detection @@ -12367,7 +12301,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Kubernetes Shell Running on Worker Node with CPU Activity - Rule action.correlationsearch.annotations = {"analytic_story": ["Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring"], "cis20": ["CIS 13"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc1448e3-cc7a-4518-bc9f-2fa48f61a22b", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc1448e3-cc7a-4518-bc9f-2fa48f61a22b", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12378,19 +12312,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host | `kubernetes_shell_running_on_worker_node_with_cpu_activity_filter` +search = | mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s | search process.cpu.utilization>0 | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name | rename host.name as host | `kubernetes_shell_running_on_worker_node_with_cpu_activity_filter` [ESCU - Kubernetes Suspicious Image Pulling - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects instances of suspicious image pulling in Kubernetes. It identifies this behavior by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to deploy malicious software or infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects suspicious image pulling in Kubernetes environments. It identifies this activity by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is significant for a SOC as it may indicate an attacker attempting to deploy malicious software or infiltrate the system. If confirmed malicious, the impact could be severe, potentially leading to unauthorized access to sensitive systems or data, and enabling further malicious activities within the cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects instances of suspicious image pulling in Kubernetes. It identifies this behavior by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to deploy malicious software or infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects suspicious image pulling in Kubernetes environments. It identifies this activity by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is significant for a SOC as it may indicate an attacker attempting to deploy malicious software or infiltrate the system. If confirmed malicious, the impact could be severe, potentially leading to unauthorized access to sensitive systems or data, and enabling further malicious activities within the cluster. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-07 -action.escu.modification_date = 2023-12-07 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Suspicious Image Pulling - Rule action.escu.search_type = detection @@ -12408,7 +12342,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Suspicious Image Pulling - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d3a17b3-0a6d-4ae0-9421-46623a69c122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d3a17b3-0a6d-4ae0-9421-46623a69c122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12419,19 +12353,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` requestObject.message="Pulling image*" | search NOT `kube_allowed_images` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_suspicious_image_pulling_filter` +search = `kube_audit` requestObject.message="Pulling image*" | search NOT `kube_allowed_images` | fillnull | stats count by objectRef.name objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_suspicious_image_pulling_filter` [ESCU - Kubernetes Unauthorized Access - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects unauthorized access to Kubernetes by monitoring Kubernetes audit logs. It identifies anomalies in access patterns by segmenting and analyzing the source of requests. Unauthorized access is worth identifying for a SOC as it could indicate an attacker attempting to infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +description = The following analytic detects unauthorized access attempts to Kubernetes by analyzing Kubernetes audit logs. It identifies anomalies in access patterns by examining the source of requests and their response statuses. This activity is significant for a SOC as it may indicate an attacker attempting to infiltrate the Kubernetes environment. If confirmed malicious, such access could lead to unauthorized control over Kubernetes resources, potentially compromising sensitive systems or data within the cluster. action.escu.mappings = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects unauthorized access to Kubernetes by monitoring Kubernetes audit logs. It identifies anomalies in access patterns by segmenting and analyzing the source of requests. Unauthorized access is worth identifying for a SOC as it could indicate an attacker attempting to infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data. +action.escu.eli5 = The following analytic detects unauthorized access attempts to Kubernetes by analyzing Kubernetes audit logs. It identifies anomalies in access patterns by examining the source of requests and their response statuses. This activity is significant for a SOC as it may indicate an attacker attempting to infiltrate the Kubernetes environment. If confirmed malicious, such access could lead to unauthorized control over Kubernetes resources, potentially compromising sensitive systems or data within the cluster. action.escu.how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-12-07 -action.escu.modification_date = 2023-12-07 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Kubernetes Unauthorized Access - Rule action.escu.search_type = detection @@ -12449,7 +12383,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Kubernetes Unauthorized Access - Rule action.correlationsearch.annotations = {"analytic_story": ["Kubernetes Security"], "cis20": ["CIS 13"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9b5f1832-e8b9-453f-93df-07a3d6a72a45", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9b5f1832-e8b9-453f-93df-07a3d6a72a45", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -12460,19 +12394,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `kube_audit` verb=create responseStatus.reason=Forbidden | fillnull | stats count by objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code responseStatus.message sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_unauthorized_access_filter` +search = `kube_audit` verb=create responseStatus.reason=Forbidden | fillnull | stats count by objectRef.namespace objectRef.resource requestReceivedTimestamp requestURI responseStatus.code responseStatus.message sourceIPs{} stage user.groups{} user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username as user | `kubernetes_unauthorized_access_filter` [ESCU - O365 Add App Role Assignment Grant User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, providing an additional layer of security for your environment. +description = The following analytic detects the addition of an application role assignment grant to a user in Office 365. It leverages data from the `o365_management_activity` dataset, specifically monitoring the "Add app role assignment grant to user" operation. This activity is significant as it can indicate unauthorized privilege escalation or the assignment of sensitive roles to users. If confirmed malicious, this could allow an attacker to gain elevated permissions, potentially leading to unauthorized access to critical resources and data within the Office 365 environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, providing an additional layer of security for your environment. +action.escu.eli5 = The following analytic detects the addition of an application role assignment grant to a user in Office 365. It leverages data from the `o365_management_activity` dataset, specifically monitoring the "Add app role assignment grant to user" operation. This activity is significant as it can indicate unauthorized privilege escalation or the assignment of sensitive roles to users. If confirmed malicious, this could allow an attacker to gain elevated permissions, potentially leading to unauthorized access to critical resources and data within the Office 365 environment. action.escu.how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = The creation of a new Federation is not necessarily malicious, however this events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider. -action.escu.creation_date = 2023-07-11 -action.escu.modification_date = 2023-07-11 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Add App Role Assignment Grant User - Rule action.escu.search_type = detection @@ -12490,11 +12424,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Add App Role Assignment Grant User - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Federated Credential Abuse", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 30, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b2c81cc6-6040-11eb-ae93-0242ac130002", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b2c81cc6-6040-11eb-ae93-0242ac130002", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, providing an additional layer of security for your environment. +action.notable.param.rule_description = The following analytic detects the addition of an application role assignment grant to a user in Office 365. It leverages data from the `o365_management_activity` dataset, specifically monitoring the "Add app role assignment grant to user" operation. This activity is significant as it can indicate unauthorized privilege escalation or the assignment of sensitive roles to users. If confirmed malicious, this could allow an attacker to gain elevated permissions, potentially leading to unauthorized access to critical resources and data within the Office 365 environment. action.notable.param.rule_title = O365 Add App Role Assignment Grant User action.notable.param.security_domain = threat action.notable.param.severity = high @@ -12512,14 +12446,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Add [ESCU - O365 Added Service Principal - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization. +description = The following analytic detects the addition of new service principal accounts in O365 tenants. It leverages data from the `o365_management_activity` dataset, specifically monitoring for operations related to adding or creating service principals. This activity is significant because attackers can exploit service principals to gain unauthorized access and perform malicious actions within an organization's environment. If confirmed malicious, this could allow attackers to interact with APIs, access resources, and execute operations on behalf of the organization, potentially leading to data breaches or further compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization. +action.escu.eli5 = The following analytic detects the addition of new service principal accounts in O365 tenants. It leverages data from the `o365_management_activity` dataset, specifically monitoring for operations related to adding or creating service principals. This activity is significant because attackers can exploit service principals to gain unauthorized access and perform malicious actions within an organization's environment. If confirmed malicious, this could allow attackers to interact with APIs, access resources, and execute operations on behalf of the organization, potentially leading to data breaches or further compromise. action.escu.how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = The creation of a new Federation is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider. -action.escu.creation_date = 2023-08-02 -action.escu.modification_date = 2023-08-02 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Added Service Principal - Rule action.escu.search_type = detection @@ -12537,11 +12471,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Added Service Principal - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Federated Credential Abuse", "NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1668812a-6047-11eb-ae93-0242ac130002", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1668812a-6047-11eb-ae93-0242ac130002", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization. +action.notable.param.rule_description = The following analytic detects the addition of new service principal accounts in O365 tenants. It leverages data from the `o365_management_activity` dataset, specifically monitoring for operations related to adding or creating service principals. This activity is significant because attackers can exploit service principals to gain unauthorized access and perform malicious actions within an organization's environment. If confirmed malicious, this could allow attackers to interact with APIs, access resources, and execute operations on behalf of the organization, potentially leading to data breaches or further compromise. action.notable.param.rule_title = O365 Added Service Principal action.notable.param.security_domain = threat action.notable.param.severity = high @@ -12559,14 +12493,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="*Ad [ESCU - O365 Admin Consent Bypassed by Service Principal - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions. +description = The following analytic identifies instances where a service principal in Office 365 Azure Active Directory assigns app roles without standard admin consent. It leverages `o365_management_activity` logs, specifically focusing on the 'Add app role assignment to service principal' operation. This activity is significant for SOCs as it may indicate a bypass of critical administrative controls, potentially leading to unauthorized access or privilege escalation. If confirmed malicious, this could allow an attacker to misuse automated processes to assign sensitive permissions, compromising the security of the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions. +action.escu.eli5 = The following analytic identifies instances where a service principal in Office 365 Azure Active Directory assigns app roles without standard admin consent. It leverages `o365_management_activity` logs, specifically focusing on the 'Add app role assignment to service principal' operation. This activity is significant for SOCs as it may indicate a bypass of critical administrative controls, potentially leading to unauthorized access or privilege escalation. If confirmed malicious, this could allow an attacker to misuse automated processes to assign sensitive permissions, compromising the security of the environment. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed. -action.escu.creation_date = 2024-02-09 -action.escu.modification_date = 2024-02-09 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Admin Consent Bypassed by Service Principal - Rule action.escu.search_type = detection @@ -12584,11 +12518,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Admin Consent Bypassed by Service Principal - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a1b22eb-50ce-4e26-a691-97ff52349569", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8a1b22eb-50ce-4e26-a691-97ff52349569", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions. +action.notable.param.rule_description = The following analytic identifies instances where a service principal in Office 365 Azure Active Directory assigns app roles without standard admin consent. It leverages `o365_management_activity` logs, specifically focusing on the 'Add app role assignment to service principal' operation. This activity is significant for SOCs as it may indicate a bypass of critical administrative controls, potentially leading to unauthorized access or privilege escalation. If confirmed malicious, this could allow an attacker to misuse automated processes to assign sensitive permissions, compromising the security of the environment. action.notable.param.rule_title = O365 Admin Consent Bypassed by Service Principal action.notable.param.security_domain = identity action.notable.param.severity = high @@ -12606,14 +12540,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Add [ESCU - O365 Advanced Audit Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail. +description = The following analytic detects instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It uses O365 audit logs, focusing on events related to audit license changes in AzureActiveDirectory workloads. This activity is significant because the O365 advanced audit provides critical logging and insights into user and administrator activities. Disabling it can blind security teams to potential malicious actions. If confirmed malicious, attackers could operate within the user's mailbox or account with reduced risk of detection, leading to unauthorized data access, data exfiltration, or account compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail. +action.escu.eli5 = The following analytic detects instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It uses O365 audit logs, focusing on events related to audit license changes in AzureActiveDirectory workloads. This activity is significant because the O365 advanced audit provides critical logging and insights into user and administrator activities. Disabling it can blind security teams to potential malicious actions. If confirmed malicious, attackers could operate within the user's mailbox or account with reduced risk of detection, leading to unauthorized data access, data exfiltration, or account compromise. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Administrators might temporarily disable the advanced audit for troubleshooting, performance reasons, or other administrative tasks. Filter as needed. -action.escu.creation_date = 2023-09-19 -action.escu.modification_date = 2023-09-19 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Advanced Audit Disabled - Rule action.escu.search_type = detection @@ -12631,11 +12565,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Advanced Audit Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 80, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49862dd4-9cb2-4c48-a542-8c8a588d9361", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49862dd4-9cb2-4c48-a542-8c8a588d9361", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail. +action.notable.param.rule_description = The following analytic detects instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It uses O365 audit logs, focusing on events related to audit license changes in AzureActiveDirectory workloads. This activity is significant because the O365 advanced audit provides critical logging and insights into user and administrator activities. Disabling it can blind security teams to potential malicious actions. If confirmed malicious, attackers could operate within the user's mailbox or account with reduced risk of detection, leading to unauthorized data access, data exfiltration, or account compromise. action.notable.param.rule_title = O365 Advanced Audit Disabled action.notable.param.security_domain = identity action.notable.param.severity = high @@ -12653,14 +12587,14 @@ search = `o365_management_activity` Operation="Change user license." | eval pro [ESCU - O365 Application Registration Owner Added - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations +description = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload. This activity is significant because assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. If confirmed malicious, an attacker could modify the application's settings, permissions, and behavior, leading to unauthorized data access, privilege escalation, or the introduction of malicious behavior within the application's operations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations +action.escu.eli5 = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload. This activity is significant because assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. If confirmed malicious, an attacker could modify the application's settings, permissions, and behavior, leading to unauthorized data access, privilege escalation, or the introduction of malicious behavior within the application's operations. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Application owners may be added for legitimate reasons, filter as needed. -action.escu.creation_date = 2023-09-07 -action.escu.modification_date = 2023-09-07 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Application Registration Owner Added - Rule action.escu.search_type = detection @@ -12678,11 +12612,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Application Registration Owner Added - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 50, "impact": 60, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c068d53f-6aaa-4558-8011-3734df878266", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c068d53f-6aaa-4558-8011-3734df878266", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations +action.notable.param.rule_description = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload. This activity is significant because assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. If confirmed malicious, an attacker could modify the application's settings, permissions, and behavior, leading to unauthorized data access, privilege escalation, or the introduction of malicious behavior within the application's operations. action.notable.param.rule_title = O365 Application Registration Owner Added action.notable.param.security_domain = identity action.notable.param.severity = high @@ -12700,14 +12634,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Add [ESCU - O365 ApplicationImpersonation Role Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization. +description = The following analytic detects the assignment of the ApplicationImpersonation role in Office 365 to a user or application. It uses the Office 365 Management Activity API to monitor Azure Active Directory audit logs for role assignment events. This activity is significant because the ApplicationImpersonation role allows impersonation of any user, enabling access to and modification of their mailbox. If confirmed malicious, an attacker could gain unauthorized access to sensitive information, manipulate mailbox data, and perform actions as a legitimate user, posing a severe security risk to the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization. +action.escu.eli5 = The following analytic detects the assignment of the ApplicationImpersonation role in Office 365 to a user or application. It uses the Office 365 Management Activity API to monitor Azure Active Directory audit logs for role assignment events. This activity is significant because the ApplicationImpersonation role allows impersonation of any user, enabling access to and modification of their mailbox. If confirmed malicious, an attacker could gain unauthorized access to sensitive information, manipulate mailbox data, and perform actions as a legitimate user, posing a severe security risk to the organization. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = While infrequent, the ApplicationImpersonation role may be granted for leigimate reasons, filter as needed. -action.escu.creation_date = 2023-10-17 -action.escu.modification_date = 2023-10-17 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 ApplicationImpersonation Role Assigned - Rule action.escu.search_type = detection @@ -12725,11 +12659,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 ApplicationImpersonation Role Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Collection Techniques", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49cdce75-f814-4d56-a7a4-c64ec3a481f2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "49cdce75-f814-4d56-a7a4-c64ec3a481f2", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization. +action.notable.param.rule_description = The following analytic detects the assignment of the ApplicationImpersonation role in Office 365 to a user or application. It uses the Office 365 Management Activity API to monitor Azure Active Directory audit logs for role assignment events. This activity is significant because the ApplicationImpersonation role allows impersonation of any user, enabling access to and modification of their mailbox. If confirmed malicious, an attacker could gain unauthorized access to sensitive information, manipulate mailbox data, and perform actions as a legitimate user, posing a severe security risk to the organization. action.notable.param.rule_title = O365 ApplicationImpersonation Role Assigned action.notable.param.security_domain = threat action.notable.param.severity = high @@ -12747,14 +12681,14 @@ search = `o365_management_activity` Workload=Exchange Operation="New-ManagementR [ESCU - O365 Block User Consent For Risky Apps Disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization. +description = The following analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats, allowing users to grant consent to malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization. +action.escu.eli5 = The following analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats, allowing users to grant consent to malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization. -action.escu.creation_date = 2023-10-26 -action.escu.modification_date = 2023-10-26 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Block User Consent For Risky Apps Disabled - Rule action.escu.search_type = detection @@ -12772,11 +12706,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Block User Consent For Risky Apps Disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "12a23592-e3da-4344-8545-205d3290647c", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "12a23592-e3da-4344-8545-205d3290647c", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization. +action.notable.param.rule_description = The following analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats, allowing users to grant consent to malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization. action.notable.param.rule_title = O365 Block User Consent For Risky Apps Disabled action.notable.param.security_domain = audit action.notable.param.severity = high @@ -12794,14 +12728,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Upd [ESCU - O365 Bypass MFA via Trusted IP - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications. +description = The following analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. It leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. This activity is significant because adding trusted IPs can weaken the security posture by bypassing MFA, which is a critical security control. If confirmed malicious, this could lead to unauthorized access, compromising sensitive information and systems. Immediate investigation is required to validate the legitimacy of the IP addition. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications. +action.escu.eli5 = The following analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. It leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. This activity is significant because adding trusted IPs can weaken the security posture by bypassing MFA, which is a critical security control. If confirmed malicious, this could lead to unauthorized access, compromising sensitive information and systems. Immediate investigation is required to validate the legitimacy of the IP addition. action.escu.how_to_implement = You must install Splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = Unless it is a special case, it is uncommon to continually update Trusted IPs to MFA configuration. -action.escu.creation_date = 2022-02-03 -action.escu.modification_date = 2022-02-03 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Bypass MFA via Trusted IP - Rule action.escu.search_type = detection @@ -12819,11 +12753,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Bypass MFA via Trusted IP - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c783dd98-c703-4252-9e8a-f19d9f66949e", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c783dd98-c703-4252-9e8a-f19d9f66949e", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications. +action.notable.param.rule_description = The following analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. It leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. This activity is significant because adding trusted IPs can weaken the security posture by bypassing MFA, which is a critical security control. If confirmed malicious, this could lead to unauthorized access, compromising sensitive information and systems. Immediate investigation is required to validate the legitimacy of the IP addition. action.notable.param.rule_title = O365 Bypass MFA via Trusted IP action.notable.param.security_domain = threat action.notable.param.severity = high @@ -12841,14 +12775,14 @@ search = `o365_management_activity` Operation="Set Company Information." Modifie [ESCU - O365 Compliance Content Search Exported - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations. +description = The following analytic identifies when the results of a content search within the Office 365 Security and Compliance Center are exported. It uses the SearchExported operation from the SecurityComplianceCenter workload in the o365_management_activity data source. This activity is significant because exporting search results can involve sensitive or critical organizational data, potentially leading to data exfiltration. If confirmed malicious, an attacker could gain access to and exfiltrate sensitive information, posing a severe risk to the organization's data security and compliance posture. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations. +action.escu.eli5 = The following analytic identifies when the results of a content search within the Office 365 Security and Compliance Center are exported. It uses the SearchExported operation from the SecurityComplianceCenter workload in the o365_management_activity data source. This activity is significant because exporting search results can involve sensitive or critical organizational data, potentially leading to data exfiltration. If confirmed malicious, an attacker could gain access to and exfiltrate sensitive information, posing a severe risk to the organization's data security and compliance posture. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Compliance content searche exports may be executed for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-04-01 -action.escu.modification_date = 2024-04-01 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Compliance Content Search Exported - Rule action.escu.search_type = detection @@ -12866,11 +12800,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Compliance Content Search Exported - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 70, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2ce9f31d-ab4f-4179-b2b7-c77a9652e1d8", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2ce9f31d-ab4f-4179-b2b7-c77a9652e1d8", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations. +action.notable.param.rule_description = The following analytic identifies when the results of a content search within the Office 365 Security and Compliance Center are exported. It uses the SearchExported operation from the SecurityComplianceCenter workload in the o365_management_activity data source. This activity is significant because exporting search results can involve sensitive or critical organizational data, potentially leading to data exfiltration. If confirmed malicious, an attacker could gain access to and exfiltrate sensitive information, posing a severe risk to the organization's data security and compliance posture. action.notable.param.rule_title = O365 Compliance Content Search Exported action.notable.param.security_domain = identity action.notable.param.severity = high @@ -12888,14 +12822,14 @@ search = `o365_management_activity` Workload=SecurityComplianceCenter Operatio [ESCU - O365 Compliance Content Search Started - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations. +description = The following analytic detects when a content search is initiated within the Office 365 Security and Compliance Center. It leverages the SearchCreated operation from the o365_management_activity logs under the SecurityComplianceCenter workload. This activity is significant as it may indicate an attempt to access sensitive organizational data, including emails and documents. If confirmed malicious, this could lead to unauthorized data access, potential data exfiltration, and compliance violations. Monitoring this behavior helps ensure the integrity and security of organizational data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations. +action.escu.eli5 = The following analytic detects when a content search is initiated within the Office 365 Security and Compliance Center. It leverages the SearchCreated operation from the o365_management_activity logs under the SecurityComplianceCenter workload. This activity is significant as it may indicate an attempt to access sensitive organizational data, including emails and documents. If confirmed malicious, this could lead to unauthorized data access, potential data exfiltration, and compliance violations. Monitoring this behavior helps ensure the integrity and security of organizational data. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Compliance content searches may be executed for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-04-01 -action.escu.modification_date = 2024-04-01 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Compliance Content Search Started - Rule action.escu.search_type = detection @@ -12913,11 +12847,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Compliance Content Search Started - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 70, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4cabbc7-c19a-4e41-8be5-98daeaccbb50", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4cabbc7-c19a-4e41-8be5-98daeaccbb50", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations. +action.notable.param.rule_description = The following analytic detects when a content search is initiated within the Office 365 Security and Compliance Center. It leverages the SearchCreated operation from the o365_management_activity logs under the SecurityComplianceCenter workload. This activity is significant as it may indicate an attempt to access sensitive organizational data, including emails and documents. If confirmed malicious, this could lead to unauthorized data access, potential data exfiltration, and compliance violations. Monitoring this behavior helps ensure the integrity and security of organizational data. action.notable.param.rule_title = O365 Compliance Content Search Started action.notable.param.security_domain = audit action.notable.param.severity = high @@ -12935,14 +12869,14 @@ search = `o365_management_activity` Workload=SecurityComplianceCenter Operation [ESCU - O365 Concurrent Sessions From Different Ips - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. +description = The following analytic identifies user sessions in Office 365 accessed from multiple IP addresses, indicating potential adversary-in-the-middle (AiTM) phishing attacks. It detects this activity by analyzing Azure Active Directory logs for 'UserLoggedIn' operations and flags sessions with more than one associated IP address. This behavior is significant as it suggests unauthorized concurrent access, which is uncommon in normal usage. If confirmed malicious, the impact could include data theft, account takeover, and the launching of internal phishing campaigns, posing severe risks to organizational security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. +action.escu.eli5 = The following analytic identifies user sessions in Office 365 accessed from multiple IP addresses, indicating potential adversary-in-the-middle (AiTM) phishing attacks. It detects this activity by analyzing Azure Active Directory logs for 'UserLoggedIn' operations and flags sessions with more than one associated IP address. This behavior is significant as it suggests unauthorized concurrent access, which is uncommon in normal usage. If confirmed malicious, the impact could include data theft, account takeover, and the launching of internal phishing campaigns, posing severe risks to organizational security. action.escu.how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = Unknown -action.escu.creation_date = 2023-12-04 -action.escu.modification_date = 2023-12-04 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Concurrent Sessions From Different Ips - Rule action.escu.search_type = detection @@ -12960,11 +12894,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Concurrent Sessions From Different Ips - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "58e034de-1f87-4812-9dc3-a4f68c7db930", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "58e034de-1f87-4812-9dc3-a4f68c7db930", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. +action.notable.param.rule_description = The following analytic identifies user sessions in Office 365 accessed from multiple IP addresses, indicating potential adversary-in-the-middle (AiTM) phishing attacks. It detects this activity by analyzing Azure Active Directory logs for 'UserLoggedIn' operations and flags sessions with more than one associated IP address. This behavior is significant as it suggests unauthorized concurrent access, which is uncommon in normal usage. If confirmed malicious, the impact could include data theft, account takeover, and the launching of internal phishing campaigns, posing severe risks to organizational security. action.notable.param.rule_title = O365 Concurrent Sessions From Different Ips action.notable.param.security_domain = threat action.notable.param.severity = high @@ -12982,14 +12916,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation=Us [ESCU - O365 Disable MFA - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. +description = The following analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to MFA settings. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. If confirmed malicious, this activity could indicate an attacker attempting to maintain persistence or an insider threat, significantly increasing the risk of unauthorized access. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. +action.escu.eli5 = The following analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to MFA settings. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. If confirmed malicious, this activity could indicate an attacker attempting to maintain persistence or an insider threat, significantly increasing the risk of unauthorized access. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = Unless it is a special case, it is uncommon to disable MFA or Strong Authentication -action.escu.creation_date = 2022-02-03 -action.escu.modification_date = 2022-02-03 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Disable MFA - Rule action.escu.search_type = detection @@ -13007,11 +12941,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Disable MFA - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c783dd98-c703-4252-9e8a-f19d9f5c949e", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c783dd98-c703-4252-9e8a-f19d9f5c949e", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. +action.notable.param.rule_description = The following analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to MFA settings. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. If confirmed malicious, this activity could indicate an attacker attempting to maintain persistence or an insider threat, significantly increasing the risk of unauthorized access. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account. action.notable.param.rule_title = O365 Disable MFA action.notable.param.security_domain = threat action.notable.param.severity = high @@ -13029,14 +12963,14 @@ search = `o365_management_activity` Operation="Disable Strong Authentication." | [ESCU - O365 Elevated Mailbox Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls. +description = The following analytic identifies the assignment of elevated mailbox permissions in an Office 365 environment via the Add-MailboxPermission operation. It leverages logs from the Exchange workload in the o365_management_activity data source, focusing on permissions such as FullAccess, ChangePermission, or ChangeOwner. This activity is significant as it indicates potential unauthorized access or control over mailboxes, which could lead to data exfiltration or privilege escalation. If confirmed malicious, attackers could gain extensive access to sensitive email data and potentially manipulate mailbox settings, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Change"] -action.escu.eli5 = This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls. +action.escu.eli5 = The following analytic identifies the assignment of elevated mailbox permissions in an Office 365 environment via the Add-MailboxPermission operation. It leverages logs from the Exchange workload in the o365_management_activity data source, focusing on permissions such as FullAccess, ChangePermission, or ChangeOwner. This activity is significant as it indicates potential unauthorized access or control over mailboxes, which could lead to data exfiltration or privilege escalation. If confirmed malicious, attackers could gain extensive access to sensitive email data and potentially manipulate mailbox settings, posing a severe security risk. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = FullAccess mailbox delegation may be assigned for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-03-31 -action.escu.modification_date = 2024-03-31 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Elevated Mailbox Permission Assigned - Rule action.escu.search_type = detection @@ -13054,11 +12988,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Elevated Mailbox Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 70, "impact": 60, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2246c142-a678-45f8-8546-aaed7e0efd30", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2246c142-a678-45f8-8546-aaed7e0efd30", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls. +action.notable.param.rule_description = The following analytic identifies the assignment of elevated mailbox permissions in an Office 365 environment via the Add-MailboxPermission operation. It leverages logs from the Exchange workload in the o365_management_activity data source, focusing on permissions such as FullAccess, ChangePermission, or ChangeOwner. This activity is significant as it indicates potential unauthorized access or control over mailboxes, which could lead to data exfiltration or privilege escalation. If confirmed malicious, attackers could gain extensive access to sensitive email data and potentially manipulate mailbox settings, posing a severe security risk. action.notable.param.rule_title = O365 Elevated Mailbox Permission Assigned action.notable.param.security_domain = audit action.notable.param.severity = high @@ -13158,14 +13092,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory LogonError=*Ss [ESCU - O365 File Permissioned Application Consent Granted by User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted. +description = The following analytic identifies instances where a user in the Office 365 environment grants consent to an application requesting file permissions for OneDrive or SharePoint. It leverages O365 audit logs, focusing on OAuth application consent events. This activity is significant because granting such permissions can allow applications to access, modify, or delete files, posing a risk if the application is malicious or overly permissive. If confirmed malicious, this could lead to data breaches, data loss, or unauthorized data manipulation, necessitating immediate investigation to validate the application's legitimacy and assess potential risks. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted. +action.escu.eli5 = The following analytic identifies instances where a user in the Office 365 environment grants consent to an application requesting file permissions for OneDrive or SharePoint. It leverages O365 audit logs, focusing on OAuth application consent events. This activity is significant because granting such permissions can allow applications to access, modify, or delete files, posing a risk if the application is malicious or overly permissive. If confirmed malicious, this could lead to data breaches, data loss, or unauthorized data manipulation, necessitating immediate investigation to validate the application's legitimacy and assess potential risks. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = OAuth applications that require file permissions may be legitimate, investigate and filter as needed. -action.escu.creation_date = 2023-10-18 -action.escu.modification_date = 2023-10-18 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 File Permissioned Application Consent Granted by User - Rule action.escu.search_type = detection @@ -13183,11 +13117,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 File Permissioned Application Consent Granted by User - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6c382336-22b8-4023-9b80-1689e799f21f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6c382336-22b8-4023-9b80-1689e799f21f", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted. +action.notable.param.rule_description = The following analytic identifies instances where a user in the Office 365 environment grants consent to an application requesting file permissions for OneDrive or SharePoint. It leverages O365 audit logs, focusing on OAuth application consent events. This activity is significant because granting such permissions can allow applications to access, modify, or delete files, posing a risk if the application is malicious or overly permissive. If confirmed malicious, this could lead to data breaches, data loss, or unauthorized data manipulation, necessitating immediate investigation to validate the application's legitimacy and assess potential risks. action.notable.param.rule_title = O365 File Permissioned Application Consent Granted by User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13205,14 +13139,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Con [ESCU - O365 FullAccessAsApp Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss. +description = The following analytic detects the assignment of the 'full_access_as_app' permission to an application registration in Office 365 Exchange Online. This detection leverages Office 365 management activity logs and filters Azure Active Directory workload events to identify when the specific permission, identified by GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is granted. This activity is significant because it provides extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. If confirmed malicious, this could lead to unauthorized data access, exfiltration, or account compromise. Immediate investigation is required. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss. +action.escu.eli5 = The following analytic detects the assignment of the 'full_access_as_app' permission to an application registration in Office 365 Exchange Online. This detection leverages Office 365 management activity logs and filters Azure Active Directory workload events to identify when the specific permission, identified by GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is granted. This activity is significant because it provides extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. If confirmed malicious, this could lead to unauthorized data access, exfiltration, or account compromise. Immediate investigation is required. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed. -action.escu.creation_date = 2024-01-29 -action.escu.modification_date = 2024-01-29 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 FullAccessAsApp Permission Assigned - Rule action.escu.search_type = detection @@ -13230,11 +13164,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 FullAccessAsApp Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01a510b3-a6ac-4d50-8812-7e8a3cde3d79", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01a510b3-a6ac-4d50-8812-7e8a3cde3d79", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss. +action.notable.param.rule_description = The following analytic detects the assignment of the 'full_access_as_app' permission to an application registration in Office 365 Exchange Online. This detection leverages Office 365 management activity logs and filters Azure Active Directory workload events to identify when the specific permission, identified by GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is granted. This activity is significant because it provides extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. If confirmed malicious, this could lead to unauthorized data access, exfiltration, or account compromise. Immediate investigation is required. action.notable.param.rule_title = O365 FullAccessAsApp Permission Assigned action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13252,14 +13186,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Upd [ESCU - O365 High Number Of Failed Authentications for User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data. +description = The following analytic identifies an O365 account experiencing more than 20 failed authentication attempts within 5 minutes. It uses O365 Unified Audit Logs, specifically "UserLoginFailed" events, to monitor and flag accounts exceeding this threshold. This activity is significant as it may indicate a brute force attack or password guessing attempt. If confirmed malicious, an attacker could gain unauthorized access to the O365 environment, potentially compromising sensitive emails, documents, and other data. Prompt investigation and action are crucial to prevent unauthorized access and data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data. +action.escu.eli5 = The following analytic identifies an O365 account experiencing more than 20 failed authentication attempts within 5 minutes. It uses O365 Unified Audit Logs, specifically "UserLoginFailed" events, to monitor and flag accounts exceeding this threshold. This activity is significant as it may indicate a brute force attack or password guessing attempt. If confirmed malicious, an attacker could gain unauthorized access to the O365 environment, potentially compromising sensitive emails, documents, and other data. Prompt investigation and action are crucial to prevent unauthorized access and data breaches. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Although unusual, users who have lost their passwords may trigger this detection. Filter as needed. -action.escu.creation_date = 2023-10-10 -action.escu.modification_date = 2023-10-10 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 High Number Of Failed Authentications for User - Rule action.escu.search_type = detection @@ -13277,11 +13211,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 High Number Of Failed Authentications for User - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "31641378-2fa9-42b1-948e-25e281cb98f7", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "31641378-2fa9-42b1-948e-25e281cb98f7", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data. +action.notable.param.rule_description = The following analytic identifies an O365 account experiencing more than 20 failed authentication attempts within 5 minutes. It uses O365 Unified Audit Logs, specifically "UserLoginFailed" events, to monitor and flag accounts exceeding this threshold. This activity is significant as it may indicate a brute force attack or password guessing attempt. If confirmed malicious, an attacker could gain unauthorized access to the O365 environment, potentially compromising sensitive emails, documents, and other data. Prompt investigation and action are crucial to prevent unauthorized access and data breaches. action.notable.param.rule_title = O365 High Number Of Failed Authentications for User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13299,14 +13233,14 @@ search = `o365_management_activity` Operation=UserLoginFailed record_type=Azur [ESCU - O365 High Privilege Role Granted - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment. +description = The following analytic detects when high-privilege roles such as "Exchange Administrator," "SharePoint Administrator," or "Global Administrator" are granted within Office 365. It leverages O365 audit logs to identify events where these roles are assigned to any user or service account. This activity is significant for SOCs as these roles provide extensive permissions, allowing broad access and control over critical resources and data. If confirmed malicious, this could enable attackers to gain significant control over O365 resources, access, modify, or delete critical data, and compromise the overall security and functionality of the O365 environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment. +action.escu.eli5 = The following analytic detects when high-privilege roles such as "Exchange Administrator," "SharePoint Administrator," or "Global Administrator" are granted within Office 365. It leverages O365 audit logs to identify events where these roles are assigned to any user or service account. This activity is significant for SOCs as these roles provide extensive permissions, allowing broad access and control over critical resources and data. If confirmed malicious, this could enable attackers to gain significant control over O365 resources, access, modify, or delete critical data, and compromise the overall security and functionality of the O365 environment. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Privilege roles may be assigned for legitimate purposes, filter as needed. -action.escu.creation_date = 2023-10-20 -action.escu.modification_date = 2023-10-20 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 High Privilege Role Granted - Rule action.escu.search_type = detection @@ -13324,11 +13258,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 High Privilege Role Granted - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e78a1037-4548-4072-bb1b-ad99ae416426", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e78a1037-4548-4072-bb1b-ad99ae416426", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment. +action.notable.param.rule_description = The following analytic detects when high-privilege roles such as "Exchange Administrator," "SharePoint Administrator," or "Global Administrator" are granted within Office 365. It leverages O365 audit logs to identify events where these roles are assigned to any user or service account. This activity is significant for SOCs as these roles provide extensive permissions, allowing broad access and control over critical resources and data. If confirmed malicious, this could enable attackers to gain significant control over O365 resources, access, modify, or delete critical data, and compromise the overall security and functionality of the O365 environment. action.notable.param.rule_title = O365 High Privilege Role Granted action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13346,14 +13280,14 @@ search = `o365_management_activity` Operation="Add member to role." Workload=Azu [ESCU - O365 Mail Permissioned Application Consent Granted by User - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities. +description = The following analytic identifies instances where a user grants consent to an application requesting mail-related permissions within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to application permissions and user consent actions. This activity is significant as it can indicate potential security risks, such as data exfiltration or spear phishing, if malicious applications gain access. If confirmed malicious, this could lead to unauthorized data access, email forwarding, or sending malicious emails from the compromised account. Validating the legitimacy of the application and consent context is crucial to prevent data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities. +action.escu.eli5 = The following analytic identifies instances where a user grants consent to an application requesting mail-related permissions within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to application permissions and user consent actions. This activity is significant as it can indicate potential security risks, such as data exfiltration or spear phishing, if malicious applications gain access. If confirmed malicious, this could lead to unauthorized data access, email forwarding, or sending malicious emails from the compromised account. Validating the legitimacy of the application and consent context is crucial to prevent data breaches. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. -action.escu.creation_date = 2023-10-12 -action.escu.modification_date = 2023-10-12 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mail Permissioned Application Consent Granted by User - Rule action.escu.search_type = detection @@ -13371,11 +13305,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mail Permissioned Application Consent Granted by User - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 50, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fddad083-cdf5-419d-83c6-baa85e329595", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fddad083-cdf5-419d-83c6-baa85e329595", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities. +action.notable.param.rule_description = The following analytic identifies instances where a user grants consent to an application requesting mail-related permissions within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to application permissions and user consent actions. This activity is significant as it can indicate potential security risks, such as data exfiltration or spear phishing, if malicious applications gain access. If confirmed malicious, this could lead to unauthorized data access, email forwarding, or sending malicious emails from the compromised account. Validating the legitimacy of the application and consent context is crucial to prevent data breaches. action.notable.param.rule_title = O365 Mail Permissioned Application Consent Granted by User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13393,14 +13327,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Con [ESCU - O365 Mailbox Email Forwarding Enabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox. +description = The following analytic identifies instances where email forwarding has been enabled on mailboxes within an Office 365 environment. It detects this activity by monitoring the Set-Mailbox operation within the o365_management_activity logs, specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress parameters. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox. +action.escu.eli5 = The following analytic identifies instances where email forwarding has been enabled on mailboxes within an Office 365 environment. It detects this activity by monitoring the Set-Mailbox operation within the o365_management_activity logs, specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress parameters. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Email forwarding may be configured for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-03-26 -action.escu.modification_date = 2024-03-26 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mailbox Email Forwarding Enabled - Rule action.escu.search_type = detection @@ -13418,11 +13352,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mailbox Email Forwarding Enabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b6bc75c-05d1-4101-9fc3-97e706168f24", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b6bc75c-05d1-4101-9fc3-97e706168f24", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox. +action.notable.param.rule_description = The following analytic identifies instances where email forwarding has been enabled on mailboxes within an Office 365 environment. It detects this activity by monitoring the Set-Mailbox operation within the o365_management_activity logs, specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress parameters. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.notable.param.rule_title = O365 Mailbox Email Forwarding Enabled action.notable.param.security_domain = threat action.notable.param.severity = high @@ -13440,14 +13374,14 @@ search = `o365_management_activity` Operation=Set-Mailbox | eval match1=mvfind( [ESCU - O365 Mailbox Folder Read Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders. +description = The following analytic identifies instances where read permissions are assigned to mailbox folders within an Office 365 environment. It leverages the `o365_management_activity` data source, specifically monitoring the `ModifyFolderPermissions` and `AddFolderPermissions` operations, while excluding Calendar, Contacts, and PersonMetadata objects. This activity is significant as unauthorized read permissions can lead to data exposure and potential information leakage. If confirmed malicious, an attacker could gain unauthorized access to sensitive emails, leading to data breaches and compromising the confidentiality of organizational communications. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders. +action.escu.eli5 = The following analytic identifies instances where read permissions are assigned to mailbox folders within an Office 365 environment. It leverages the `o365_management_activity` data source, specifically monitoring the `ModifyFolderPermissions` and `AddFolderPermissions` operations, while excluding Calendar, Contacts, and PersonMetadata objects. This activity is significant as unauthorized read permissions can lead to data exposure and potential information leakage. If confirmed malicious, an attacker could gain unauthorized access to sensitive emails, leading to data breaches and compromising the confidentiality of organizational communications. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-03-29 -action.escu.modification_date = 2024-03-29 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mailbox Folder Read Permission Assigned - Rule action.escu.search_type = detection @@ -13465,11 +13399,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mailbox Folder Read Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1435475e-2128-4417-a34f-59770733b0d5", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1435475e-2128-4417-a34f-59770733b0d5", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders. +action.notable.param.rule_description = The following analytic identifies instances where read permissions are assigned to mailbox folders within an Office 365 environment. It leverages the `o365_management_activity` data source, specifically monitoring the `ModifyFolderPermissions` and `AddFolderPermissions` operations, while excluding Calendar, Contacts, and PersonMetadata objects. This activity is significant as unauthorized read permissions can lead to data exposure and potential information leakage. If confirmed malicious, an attacker could gain unauthorized access to sensitive emails, leading to data breaches and compromising the confidentiality of organizational communications. action.notable.param.rule_title = O365 Mailbox Folder Read Permission Assigned action.notable.param.security_domain = audit action.notable.param.severity = high @@ -13487,14 +13421,14 @@ search = `o365_management_activity` Workload=Exchange (Operation=ModifyFolderPer [ESCU - O365 Mailbox Folder Read Permission Granted - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents. +description = The following analytic identifies instances where read permissions are granted to mailbox folders within an Office 365 environment. It detects this activity by monitoring the `o365_management_activity` data source for the `Set-MailboxFolderPermission` and `Add-MailboxFolderPermission` operations. This behavior is significant as it may indicate unauthorized access or changes to mailbox folder permissions, potentially exposing sensitive email content. If confirmed malicious, an attacker could gain unauthorized access to read email communications, leading to data breaches or information leakage. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents. +action.escu.eli5 = The following analytic identifies instances where read permissions are granted to mailbox folders within an Office 365 environment. It detects this activity by monitoring the `o365_management_activity` data source for the `Set-MailboxFolderPermission` and `Add-MailboxFolderPermission` operations. This behavior is significant as it may indicate unauthorized access or changes to mailbox folder permissions, potentially exposing sensitive email content. If confirmed malicious, an attacker could gain unauthorized access to read email communications, leading to data breaches or information leakage. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed. -action.escu.creation_date = 2024-03-28 -action.escu.modification_date = 2024-03-28 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mailbox Folder Read Permission Granted - Rule action.escu.search_type = detection @@ -13512,11 +13446,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mailbox Folder Read Permission Granted - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cd15c0a8-470e-4b12-9517-046e4927db30", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cd15c0a8-470e-4b12-9517-046e4927db30", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents. +action.notable.param.rule_description = The following analytic identifies instances where read permissions are granted to mailbox folders within an Office 365 environment. It detects this activity by monitoring the `o365_management_activity` data source for the `Set-MailboxFolderPermission` and `Add-MailboxFolderPermission` operations. This behavior is significant as it may indicate unauthorized access or changes to mailbox folder permissions, potentially exposing sensitive email content. If confirmed malicious, an attacker could gain unauthorized access to read email communications, leading to data breaches or information leakage. action.notable.param.rule_title = O365 Mailbox Folder Read Permission Granted action.notable.param.security_domain = audit action.notable.param.severity = high @@ -13534,14 +13468,14 @@ search = `o365_management_activity` Workload=Exchange (Operation="Set-MailboxFo [ESCU - O365 Mailbox Inbox Folder Shared with All Users - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox. +description = The following analytic detects instances where the inbox folder of an Office 365 mailbox is shared with all users within the tenant. It leverages Office 365 management activity events to identify when the 'Inbox' folder permissions are modified to include 'Everyone' with read rights. This activity is significant as it represents a potential security risk, allowing unauthorized access to sensitive emails. If confirmed malicious, this could lead to data breaches, exfiltration of confidential information, and further compromise through spear-phishing or other malicious activities based on the accessed email content. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox. +action.escu.eli5 = The following analytic detects instances where the inbox folder of an Office 365 mailbox is shared with all users within the tenant. It leverages Office 365 management activity events to identify when the 'Inbox' folder permissions are modified to include 'Everyone' with read rights. This activity is significant as it represents a potential security risk, allowing unauthorized access to sensitive emails. If confirmed malicious, this could lead to data breaches, exfiltration of confidential information, and further compromise through spear-phishing or other malicious activities based on the accessed email content. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Administrators might temporarily share a mailbox with all users for legitimate reasons, such as troubleshooting, migrations, or other administrative tasks. Some organizations use shared mailboxes for teams or departments where multiple users need access to the same mailbox. Filter as needed. -action.escu.creation_date = 2023-09-07 -action.escu.modification_date = 2023-09-07 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mailbox Inbox Folder Shared with All Users - Rule action.escu.search_type = detection @@ -13559,11 +13493,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mailbox Inbox Folder Shared with All Users - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "21421896-a692-4594-9888-5faeb8a53106", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "21421896-a692-4594-9888-5faeb8a53106", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox. +action.notable.param.rule_description = The following analytic detects instances where the inbox folder of an Office 365 mailbox is shared with all users within the tenant. It leverages Office 365 management activity events to identify when the 'Inbox' folder permissions are modified to include 'Everyone' with read rights. This activity is significant as it represents a potential security risk, allowing unauthorized access to sensitive emails. If confirmed malicious, this could lead to data breaches, exfiltration of confidential information, and further compromise through spear-phishing or other malicious activities based on the accessed email content. action.notable.param.rule_title = O365 Mailbox Inbox Folder Shared with All Users action.notable.param.security_domain = access action.notable.param.severity = high @@ -13581,14 +13515,14 @@ search = `o365_management_activity` Operation=ModifyFolderPermissions Workload=E [ESCU - O365 Mailbox Read Access Granted to Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such access and that any inadvertent or malicious assignments are promptly identified. If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. +description = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. This activity is significant because the Mail.Read permission allows applications to access and read all emails within a user's mailbox, which often contain sensitive or confidential information. If confirmed malicious, this could lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1114.002", "T1114", "T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such access and that any inadvertent or malicious assignments are promptly identified. If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. +action.escu.eli5 = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. This activity is significant because the Mail.Read permission allows applications to access and read all emails within a user's mailbox, which often contain sensitive or confidential information. If confirmed malicious, this could lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = There are legitimate scenarios in wich an Application registrations requires Mailbox read access. Filter as needed. -action.escu.creation_date = 2023-09-01 -action.escu.modification_date = 2023-09-01 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Mailbox Read Access Granted to Application - Rule action.escu.search_type = detection @@ -13606,11 +13540,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Mailbox Read Access Granted to Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 50, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1114.002", "T1114", "T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "27ab61c5-f08a-438a-b4d3-325e666490b3", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "27ab61c5-f08a-438a-b4d3-325e666490b3", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such access and that any inadvertent or malicious assignments are promptly identified. If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. +action.notable.param.rule_description = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. This activity is significant because the Mail.Read permission allows applications to access and read all emails within a user's mailbox, which often contain sensitive or confidential information. If confirmed malicious, this could lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails. action.notable.param.rule_title = O365 Mailbox Read Access Granted to Application action.notable.param.security_domain = access action.notable.param.severity = high @@ -13628,14 +13562,14 @@ search = `o365_management_activity` Operation="Update application." | eval json_ [ESCU - O365 Multi-Source Failed Authentications Spike - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects potential distributed password spraying attacks within an Office 365 environment. It identifies a significant increase in failed authentication attempts characterized by diverse user-and-IP address combinations, originating from multiple source IP addresses, and utilizing various user agents. These patterns may indicate an adversary's attempt to circumvent security controls by employing a spectrum of IP addresses to test commonly used passwords against a wide range of user accounts. The detection examines UserLoginFailed events from O365 Management Activity logs, with a particular focus on events with ErrorNumber 50126, which indicates a failed authentication due to incorrect credentials. By aggregating data over a five-minute interval, the analytic calculates the distinct counts of user-and-IP combinations and unique users and source IPs. It then applies a set of thresholds to these metrics to identify abnormal activities that could suggest a coordinated attack. The predefined thresholds within the analytic (such as unique IPs, unique users, etc.) serve as initial benchmarks and should be tailored to align with the organization's typical user behavior and risk tolerance. Early detection of such distributed activities is crucial for security operations centers (SOCs) to intercept unauthorized access attempts, avert account takeovers, and reduce the risk of subsequent malevolent actions within the organization's systems. A true positive alert from this analytic would indicate an ongoing distributed password spraying campaign targeting the organization's Office 365 tenant. If such an attack is successful, it could lead to unauthorized access, especially to accounts with administrative privileges, resulting in data breaches, privilege escalation, persistent threats, and lateral movement within the organization's digital environment. +description = The following analytic identifies a spike in failed authentication attempts within an Office 365 environment, indicative of a potential distributed password spraying attack. It leverages UserLoginFailed events from O365 Management Activity logs, focusing on ErrorNumber 50126. This detection is significant as it highlights attempts to bypass security controls using multiple IP addresses and user agents. If confirmed malicious, this activity could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization. Early detection is crucial to prevent account takeovers and mitigate subsequent threats. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects potential distributed password spraying attacks within an Office 365 environment. It identifies a significant increase in failed authentication attempts characterized by diverse user-and-IP address combinations, originating from multiple source IP addresses, and utilizing various user agents. These patterns may indicate an adversary's attempt to circumvent security controls by employing a spectrum of IP addresses to test commonly used passwords against a wide range of user accounts. The detection examines UserLoginFailed events from O365 Management Activity logs, with a particular focus on events with ErrorNumber 50126, which indicates a failed authentication due to incorrect credentials. By aggregating data over a five-minute interval, the analytic calculates the distinct counts of user-and-IP combinations and unique users and source IPs. It then applies a set of thresholds to these metrics to identify abnormal activities that could suggest a coordinated attack. The predefined thresholds within the analytic (such as unique IPs, unique users, etc.) serve as initial benchmarks and should be tailored to align with the organization's typical user behavior and risk tolerance. Early detection of such distributed activities is crucial for security operations centers (SOCs) to intercept unauthorized access attempts, avert account takeovers, and reduce the risk of subsequent malevolent actions within the organization's systems. A true positive alert from this analytic would indicate an ongoing distributed password spraying campaign targeting the organization's Office 365 tenant. If such an attack is successful, it could lead to unauthorized access, especially to accounts with administrative privileges, resulting in data breaches, privilege escalation, persistent threats, and lateral movement within the organization's digital environment. +action.escu.eli5 = The following analytic identifies a spike in failed authentication attempts within an Office 365 environment, indicative of a potential distributed password spraying attack. It leverages UserLoginFailed events from O365 Management Activity logs, focusing on ErrorNumber 50126. This detection is significant as it highlights attempts to bypass security controls using multiple IP addresses and user agents. If confirmed malicious, this activity could lead to unauthorized access, data breaches, privilege escalation, and lateral movement within the organization. Early detection is crucial to prevent account takeovers and mitigate subsequent threats. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. action.escu.known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. -action.escu.creation_date = 2023-11-09 -action.escu.modification_date = 2023-11-09 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multi-Source Failed Authentications Spike - Rule action.escu.search_type = detection @@ -13648,7 +13582,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multi-Source Failed Authentications Spike - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ea4e2c41-dbfb-4f5f-a7b6-9ac1b7f104aa", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ea4e2c41-dbfb-4f5f-a7b6-9ac1b7f104aa", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -13664,14 +13598,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation=Use [ESCU - O365 Multiple AppIDs and UserAgents Authentication Spike - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is crafted to identify unusual and potentially malicious authentication activity within an O365 environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of O365 audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +description = The following analytic identifies unusual authentication activity in an O365 environment, where a single user account experiences more than 8 authentication attempts using 3 or more unique application IDs and over 5 unique user agents within a short timeframe. It leverages O365 audit logs, focusing on authentication events and applying statistical thresholds. This behavior is significant as it may indicate an adversary probing for multi-factor authentication weaknesses. If confirmed malicious, it suggests a compromised account, potentially leading to unauthorized access, privilege escalation, and data exfiltration. Early detection is crucial to prevent further exploitation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This analytic is crafted to identify unusual and potentially malicious authentication activity within an O365 environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of O365 audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +action.escu.eli5 = The following analytic identifies unusual authentication activity in an O365 environment, where a single user account experiences more than 8 authentication attempts using 3 or more unique application IDs and over 5 unique user agents within a short timeframe. It leverages O365 audit logs, focusing on authentication events and applying statistical thresholds. This behavior is significant as it may indicate an adversary probing for multi-factor authentication weaknesses. If confirmed malicious, it suggests a compromised account, potentially leading to unauthorized access, privilege escalation, and data exfiltration. Early detection is crucial to prevent further exploitation. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. -action.escu.creation_date = 2023-10-24 -action.escu.modification_date = 2023-10-24 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple AppIDs and UserAgents Authentication Spike - Rule action.escu.search_type = detection @@ -13689,7 +13623,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple AppIDs and UserAgents Authentication Spike - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "66adc486-224d-45c1-8e4d-9e7eeaba988f", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "66adc486-224d-45c1-8e4d-9e7eeaba988f", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -13705,14 +13639,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory (Operation=Us [ESCU - O365 Multiple Failed MFA Requests For User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach. +description = The following analytic identifies potential "MFA fatigue" attacks targeting Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. It leverages O365 management activity logs, focusing on Azure Active Directory events with the UserLoginFailed operation, a Success ResultStatus, and an ErrorNumber of 500121. This activity is significant as attackers may exploit MFA fatigue to gain unauthorized access by overwhelming users with repeated MFA requests. If confirmed malicious, this could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation is crucial. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach. +action.escu.eli5 = The following analytic identifies potential "MFA fatigue" attacks targeting Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. It leverages O365 management activity logs, focusing on Azure Active Directory events with the UserLoginFailed operation, a Success ResultStatus, and an ErrorNumber of 500121. This activity is significant as attackers may exploit MFA fatigue to gain unauthorized access by overwhelming users with repeated MFA requests. If confirmed malicious, this could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation is crucial. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. -action.escu.creation_date = 2023-10-19 -action.escu.modification_date = 2023-10-19 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple Failed MFA Requests For User - Rule action.escu.search_type = detection @@ -13730,11 +13664,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple Failed MFA Requests For User - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fd22124e-dbac-4744-a8ce-be10d8ec3e26", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fd22124e-dbac-4744-a8ce-be10d8ec3e26", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach. +action.notable.param.rule_description = The following analytic identifies potential "MFA fatigue" attacks targeting Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. It leverages O365 management activity logs, focusing on Azure Active Directory events with the UserLoginFailed operation, a Success ResultStatus, and an ErrorNumber of 500121. This activity is significant as attackers may exploit MFA fatigue to gain unauthorized access by overwhelming users with repeated MFA requests. If confirmed malicious, this could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation is crucial. action.notable.param.rule_title = O365 Multiple Failed MFA Requests For User action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13752,14 +13686,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation=Use [ESCU - O365 Multiple Mailboxes Accessed via API - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold - set here to flag over five unique mailboxes accessed within 10 minutes - to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency. +description = The following analytic detects when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) within a short timeframe. It leverages 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. This activity is significant as it may indicate unauthorized mass email access, potentially signaling data exfiltration or account compromise. If confirmed malicious, attackers could gain access to sensitive information, leading to data breaches and further exploitation of compromised accounts. The threshold is set to flag over five unique mailboxes accessed within 10 minutes, but should be tailored to your environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Web"] -action.escu.eli5 = The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold - set here to flag over five unique mailboxes accessed within 10 minutes - to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency. +action.escu.eli5 = The following analytic detects when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) within a short timeframe. It leverages 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. This activity is significant as it may indicate unauthorized mass email access, potentially signaling data exfiltration or account compromise. If confirmed malicious, attackers could gain access to sensitive information, leading to data breaches and further exploitation of compromised accounts. The threshold is set to flag over five unique mailboxes accessed within 10 minutes, but should be tailored to your environment. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Legitimate applications may access multiple mailboxes via an API. You can filter by the ClientAppId or the CLientIpAddress fields. -action.escu.creation_date = 2024-02-01 -action.escu.modification_date = 2024-02-01 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple Mailboxes Accessed via API - Rule action.escu.search_type = detection @@ -13777,11 +13711,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple Mailboxes Accessed via API - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7cd853e9-d370-412f-965d-a2bcff2a2908", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7cd853e9-d370-412f-965d-a2bcff2a2908", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold - set here to flag over five unique mailboxes accessed within 10 minutes - to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency. +action.notable.param.rule_description = The following analytic detects when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) within a short timeframe. It leverages 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. This activity is significant as it may indicate unauthorized mass email access, potentially signaling data exfiltration or account compromise. If confirmed malicious, attackers could gain access to sensitive information, leading to data breaches and further exploitation of compromised accounts. The threshold is set to flag over five unique mailboxes accessed within 10 minutes, but should be tailored to your environment. action.notable.param.rule_title = O365 Multiple Mailboxes Accessed via API action.notable.param.security_domain = threat action.notable.param.severity = high @@ -13799,14 +13733,14 @@ search = `o365_management_activity` Workload=Exchange Operation=MailItemsAccess [ESCU - O365 Multiple Service Principals Created by SP - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection aims to identify instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe, using O365 logs from the Unified Audit Log. The focus is on tracking the 'Add service principal' operation within the Office 365 Azure Active Directory environment. The query effectively buckets events in 10-minute intervals, specifically scrutinizing the actions of service principals. By quantifying the number of distinct OAuth applications each service principal establishes, the analytic provides critical insights for SOC teams into potentially anomalous or malicious activities. These activities could include a compromised or malicious service principal being used to create multiple service principals, which might be indicative of an attempt to expand control or access within the network. Security teams are advised to adapt the threshold of three applications to align with their typical operational baseline +description = The following analytic identifies instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in the Office 365 Azure Active Directory environment. This activity is significant as it may indicate a compromised or malicious service principal attempting to expand control or access within the network. If confirmed malicious, this could lead to unauthorized access and potential lateral movement within the environment, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection aims to identify instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe, using O365 logs from the Unified Audit Log. The focus is on tracking the 'Add service principal' operation within the Office 365 Azure Active Directory environment. The query effectively buckets events in 10-minute intervals, specifically scrutinizing the actions of service principals. By quantifying the number of distinct OAuth applications each service principal establishes, the analytic provides critical insights for SOC teams into potentially anomalous or malicious activities. These activities could include a compromised or malicious service principal being used to create multiple service principals, which might be indicative of an attempt to expand control or access within the network. Security teams are advised to adapt the threshold of three applications to align with their typical operational baseline +action.escu.eli5 = The following analytic identifies instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in the Office 365 Azure Active Directory environment. This activity is significant as it may indicate a compromised or malicious service principal attempting to expand control or access within the network. If confirmed malicious, this could lead to unauthorized access and potential lateral movement within the environment, posing a significant security risk. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-02-07 -action.escu.modification_date = 2024-02-07 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple Service Principals Created by SP - Rule action.escu.search_type = detection @@ -13824,7 +13758,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple Service Principals Created by SP - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ef4c3f20-d1ad-4ad1-a3f4-d5f391c005fe", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ef4c3f20-d1ad-4ad1-a3f4-d5f391c005fe", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -13840,14 +13774,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Add [ESCU - O365 Multiple Service Principals Created by User - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection is tailored to spot occurrences where a single user, rather than a service principal, creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. Utilizing O365 logs from the Unified Audit Log, it focuses on the 'Add service principal' operation in Azure Active Directory. The query segments events into 10-minute intervals, exclusively monitoring user activities. It calculates the number of distinct OAuth applications initiated by each user, providing SOC teams with essential data for identifying potential security threats. Such activity could suggest that a user account is either compromised or engaged in unauthorized activities, potentially setting the stage for broader network infiltration or privilege escalation. It's important for security teams to adjust the threshold of three applications to fit their operational context. +description = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in Azure Active Directory. This activity is significant as it may indicate a compromised user account or unauthorized actions, potentially leading to broader network infiltration or privilege escalation. If confirmed malicious, this behavior could allow attackers to gain persistent access, escalate privileges, or exfiltrate sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This detection is tailored to spot occurrences where a single user, rather than a service principal, creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. Utilizing O365 logs from the Unified Audit Log, it focuses on the 'Add service principal' operation in Azure Active Directory. The query segments events into 10-minute intervals, exclusively monitoring user activities. It calculates the number of distinct OAuth applications initiated by each user, providing SOC teams with essential data for identifying potential security threats. Such activity could suggest that a user account is either compromised or engaged in unauthorized activities, potentially setting the stage for broader network infiltration or privilege escalation. It's important for security teams to adjust the threshold of three applications to fit their operational context. +action.escu.eli5 = The following analytic identifies instances where a single user creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. It leverages O365 logs from the Unified Audit Log, focusing on the 'Add service principal' operation in Azure Active Directory. This activity is significant as it may indicate a compromised user account or unauthorized actions, potentially leading to broader network infiltration or privilege escalation. If confirmed malicious, this behavior could allow attackers to gain persistent access, escalate privileges, or exfiltrate sensitive information. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-02-07 -action.escu.modification_date = 2024-02-07 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple Service Principals Created by User - Rule action.escu.search_type = detection @@ -13865,7 +13799,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple Service Principals Created by User - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a34e65d0-54de-4b02-9db8-5a04522067f6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a34e65d0-54de-4b02-9db8-5a04522067f6", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -13881,14 +13815,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Ad [ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication. +description = The following analytic identifies instances where more than 10 unique user accounts fail to authenticate from a single IP address within a 5-minute window. This detection leverages O365 audit logs, specifically Azure Active Directory login failures (AzureActiveDirectoryStsLogon). Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to breach security by targeting multiple accounts, potentially leading to unauthorized access. Immediate action is required to block or monitor the suspicious IP and notify affected users to enhance their security measures. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication. +action.escu.eli5 = The following analytic identifies instances where more than 10 unique user accounts fail to authenticate from a single IP address within a 5-minute window. This detection leverages O365 audit logs, specifically Azure Active Directory login failures (AzureActiveDirectoryStsLogon). Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to breach security by targeting multiple accounts, potentially leading to unauthorized access. Immediate action is required to block or monitor the suspicious IP and notify affected users to enhance their security measures. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior. -action.escu.creation_date = 2024-03-19 -action.escu.modification_date = 2024-03-19 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule action.escu.search_type = detection @@ -13906,11 +13840,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation", "Weaponization"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8d486e2e-3235-4cfe-ac35-0d042e24ecb4", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8d486e2e-3235-4cfe-ac35-0d042e24ecb4", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication. +action.notable.param.rule_description = The following analytic identifies instances where more than 10 unique user accounts fail to authenticate from a single IP address within a 5-minute window. This detection leverages O365 audit logs, specifically Azure Active Directory login failures (AzureActiveDirectoryStsLogon). Such activity is significant as it may indicate brute-force attacks or password spraying attempts. If confirmed malicious, this behavior suggests an external entity is attempting to breach security by targeting multiple accounts, potentially leading to unauthorized access. Immediate action is required to block or monitor the suspicious IP and notify affected users to enhance their security measures. action.notable.param.rule_title = O365 Multiple Users Failing To Authenticate From Ip action.notable.param.security_domain = identity action.notable.param.severity = high @@ -13928,14 +13862,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation=Use [ESCU - O365 New Email Forwarding Rule Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior. +description = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters like ForwardTo, ForwardAsAttachmentTo, and RedirectTo. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior. +action.escu.eli5 = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters like ForwardTo, ForwardAsAttachmentTo, and RedirectTo. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-03-27 -action.escu.modification_date = 2024-03-27 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 New Email Forwarding Rule Created - Rule action.escu.search_type = detection @@ -13953,11 +13887,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 New Email Forwarding Rule Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "68469fd0-1315-44ba-b7e4-e92847bb76d6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "68469fd0-1315-44ba-b7e4-e92847bb76d6", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior. +action.notable.param.rule_description = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters like ForwardTo, ForwardAsAttachmentTo, and RedirectTo. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches. action.notable.param.rule_title = O365 New Email Forwarding Rule Created action.notable.param.security_domain = audit action.notable.param.severity = high @@ -13975,14 +13909,14 @@ search = `o365_management_activity` (Operation=New-InboxRule OR Operation=set-In [ESCU - O365 New Email Forwarding Rule Enabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format. +description = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment via the UpdateInboxRules operation. It leverages Office 365 management activity events to detect rules that forward emails to external recipients by examining the OperationProperties for specific forwarding actions. This activity is significant as it may indicate unauthorized email redirection, potentially leading to data exfiltration. If confirmed malicious, attackers could intercept sensitive communications, leading to data breaches and information leakage. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format. +action.escu.eli5 = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment via the UpdateInboxRules operation. It leverages Office 365 management activity events to detect rules that forward emails to external recipients by examining the OperationProperties for specific forwarding actions. This activity is significant as it may indicate unauthorized email redirection, potentially leading to data exfiltration. If confirmed malicious, attackers could intercept sensitive communications, leading to data breaches and information leakage. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-03-28 -action.escu.modification_date = 2024-03-28 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 New Email Forwarding Rule Enabled - Rule action.escu.search_type = detection @@ -14000,11 +13934,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 New Email Forwarding Rule Enabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ac7c4d0a-06a3-4278-aa59-88a5e537f981", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ac7c4d0a-06a3-4278-aa59-88a5e537f981", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format. +action.notable.param.rule_description = The following analytic identifies the creation of new email forwarding rules in an Office 365 environment via the UpdateInboxRules operation. It leverages Office 365 management activity events to detect rules that forward emails to external recipients by examining the OperationProperties for specific forwarding actions. This activity is significant as it may indicate unauthorized email redirection, potentially leading to data exfiltration. If confirmed malicious, attackers could intercept sensitive communications, leading to data breaches and information leakage. action.notable.param.rule_title = O365 New Email Forwarding Rule Enabled action.notable.param.security_domain = audit action.notable.param.severity = high @@ -14022,14 +13956,14 @@ search = `o365_management_activity` Workload=Exchange Operation=UpdateInboxRules [ESCU - O365 New Federated Domain Added - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach. +description = The following analytic identifies the addition of a new federated domain in an Office 365 environment. This behavior is detected by analyzing Office 365 management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". The addition of a new federated domain is significant as it may indicate unauthorized changes or potential compromises. If confirmed malicious, attackers could establish a backdoor, bypass security measures, or exfiltrate data, leading to data breaches and unauthorized access to sensitive information. Immediate investigation is required to review the details of the added domain and any concurrent suspicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach. +action.escu.eli5 = The following analytic identifies the addition of a new federated domain in an Office 365 environment. This behavior is detected by analyzing Office 365 management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". The addition of a new federated domain is significant as it may indicate unauthorized changes or potential compromises. If confirmed malicious, attackers could establish a backdoor, bypass security measures, or exfiltrate data, leading to data breaches and unauthorized access to sensitive information. Immediate investigation is required to review the details of the added domain and any concurrent suspicious activities. action.escu.how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity. action.escu.known_false_positives = The creation of a new Federated domain is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a similar or different cloud provider. -action.escu.creation_date = 2023-08-02 -action.escu.modification_date = 2023-08-02 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 New Federated Domain Added - Rule action.escu.search_type = detection @@ -14047,11 +13981,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 New Federated Domain Added - Rule action.correlationsearch.annotations = {"analytic_story": ["Cloud Federated Credential Abuse", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e155876a-6048-11eb-ae93-0242ac130002", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e155876a-6048-11eb-ae93-0242ac130002", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach. +action.notable.param.rule_description = The following analytic identifies the addition of a new federated domain in an Office 365 environment. This behavior is detected by analyzing Office 365 management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". The addition of a new federated domain is significant as it may indicate unauthorized changes or potential compromises. If confirmed malicious, attackers could establish a backdoor, bypass security measures, or exfiltrate data, leading to data breaches and unauthorized access to sensitive information. Immediate investigation is required to review the details of the added domain and any concurrent suspicious activities. action.notable.param.rule_title = O365 New Federated Domain Added action.notable.param.security_domain = threat action.notable.param.severity = high @@ -14069,14 +14003,14 @@ search = `o365_management_activity` Operation IN ("*add*", "*new*") AND Operatio [ESCU - O365 New Forwarding Mailflow Rule Created - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification. +description = The following analytic detects the creation of new mail flow rules in Office 365 that may redirect or copy emails to unauthorized or external addresses. It leverages Office 365 Management Activity logs, specifically querying for the "New-TransportRule" operation and parameters like "BlindCopyTo", "CopyTo", and "RedirectMessageTo". This activity is significant as it can indicate potential data exfiltration or unauthorized access to sensitive information. If confirmed malicious, attackers could intercept or redirect email communications, leading to data breaches or information leakage. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification. +action.escu.eli5 = The following analytic detects the creation of new mail flow rules in Office 365 that may redirect or copy emails to unauthorized or external addresses. It leverages Office 365 Management Activity logs, specifically querying for the "New-TransportRule" operation and parameters like "BlindCopyTo", "CopyTo", and "RedirectMessageTo". This activity is significant as it can indicate potential data exfiltration or unauthorized access to sensitive information. If confirmed malicious, attackers could intercept or redirect email communications, leading to data breaches or information leakage. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Forwarding mail flow rules may be created for legitimate reasons, filter as needed. -action.escu.creation_date = 2024-04-10 -action.escu.modification_date = 2024-04-10 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 New Forwarding Mailflow Rule Created - Rule action.escu.search_type = detection @@ -14094,11 +14028,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 New Forwarding Mailflow Rule Created - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "289ed0a1-4c78-4a43-9321-44ea2e089c14", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "289ed0a1-4c78-4a43-9321-44ea2e089c14", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification. +action.notable.param.rule_description = The following analytic detects the creation of new mail flow rules in Office 365 that may redirect or copy emails to unauthorized or external addresses. It leverages Office 365 Management Activity logs, specifically querying for the "New-TransportRule" operation and parameters like "BlindCopyTo", "CopyTo", and "RedirectMessageTo". This activity is significant as it can indicate potential data exfiltration or unauthorized access to sensitive information. If confirmed malicious, attackers could intercept or redirect email communications, leading to data breaches or information leakage. action.notable.param.rule_title = O365 New Forwarding Mailflow Rule Created action.notable.param.security_domain = audit action.notable.param.severity = high @@ -14116,14 +14050,14 @@ search = `o365_management_activity` Workload=Exchange Operation="New-TransportRu [ESCU - O365 New MFA Method Registered - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account within Office 365. It leverages O365 audit logs to identify changes in MFA configurations. This activity is significant as it may indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges or access sensitive data. Immediate verification and remediation are required to secure the affected account. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Authentication"] -action.escu.eli5 = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +action.escu.eli5 = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account within Office 365. It leverages O365 audit logs to identify changes in MFA configurations. This activity is significant as it may indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges or access sensitive data. Immediate verification and remediation are required to secure the affected account. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed. -action.escu.creation_date = 2023-10-20 -action.escu.modification_date = 2023-10-20 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 New MFA Method Registered - Rule action.escu.search_type = detection @@ -14141,11 +14075,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 New MFA Method Registered - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 50, "impact": 60, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4e12db1f-f7c7-486d-8152-a221cad6ac2b", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4e12db1f-f7c7-486d-8152-a221cad6ac2b", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. +action.notable.param.rule_description = The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a user account within Office 365. It leverages O365 audit logs to identify changes in MFA configurations. This activity is significant as it may indicate an attacker's attempt to maintain persistence on a compromised account. If confirmed malicious, the attacker could bypass existing security measures, solidify their access, and potentially escalate privileges or access sensitive data. Immediate verification and remediation are required to secure the affected account. action.notable.param.rule_title = O365 New MFA Method Registered action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14163,14 +14097,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Up [ESCU - O365 OAuth App Mailbox Access via EWS - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access. +description = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. It leverages the ClientInfoString field to identify EWS interactions and aggregates metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing emails through EWS is crucial for identifying potential abuse or unauthorized data access. If confirmed malicious, this activity could lead to unauthorized email access, data exfiltration, or further compromise of sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Web"] -action.escu.eli5 = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access. +action.escu.eli5 = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. It leverages the ClientInfoString field to identify EWS interactions and aggregates metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing emails through EWS is crucial for identifying potential abuse or unauthorized data access. If confirmed malicious, this activity could lead to unauthorized email access, data exfiltration, or further compromise of sensitive information. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the src_ip to add trusted sources to an allow list. -action.escu.creation_date = 2024-01-31 -action.escu.modification_date = 2024-01-31 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 OAuth App Mailbox Access via EWS - Rule action.escu.search_type = detection @@ -14188,11 +14122,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 OAuth App Mailbox Access via EWS - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e600cf1a-0bef-4426-b42e-00176d610a4d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e600cf1a-0bef-4426-b42e-00176d610a4d", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access. +action.notable.param.rule_description = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. It leverages the ClientInfoString field to identify EWS interactions and aggregates metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing emails through EWS is crucial for identifying potential abuse or unauthorized data access. If confirmed malicious, this activity could lead to unauthorized email access, data exfiltration, or further compromise of sensitive information. action.notable.param.rule_title = O365 OAuth App Mailbox Access via EWS action.notable.param.security_domain = threat action.notable.param.severity = high @@ -14210,14 +14144,14 @@ search = `o365_management_activity` Workload=Exchange Operation=MailItemsAccess [ESCU - O365 OAuth App Mailbox Access via Graph API - Rule] action.escu = 0 action.escu.enabled = 1 -description = This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns. +description = The following analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API using the client ID '00000003-0000-0000-c000-000000000000'. It leverages the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. This activity is significant as unauthorized access to emails can lead to data breaches and information theft. If confirmed malicious, attackers could exfiltrate sensitive information, compromise user accounts, and further infiltrate the organization’s network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns. +action.escu.eli5 = The following analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API using the client ID '00000003-0000-0000-c000-000000000000'. It leverages the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. This activity is significant as unauthorized access to emails can lead to data breaches and information theft. If confirmed malicious, attackers could exfiltrate sensitive information, compromise user accounts, and further infiltrate the organization’s network. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the ClientAppId to add trusted applications to an allow list. -action.escu.creation_date = 2024-01-31 -action.escu.modification_date = 2024-01-31 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 OAuth App Mailbox Access via Graph API - Rule action.escu.search_type = detection @@ -14235,11 +14169,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 OAuth App Mailbox Access via Graph API - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9db0d5b0-4058-4cb7-baaf-77d8143539a2", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9db0d5b0-4058-4cb7-baaf-77d8143539a2", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns. +action.notable.param.rule_description = The following analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API using the client ID '00000003-0000-0000-c000-000000000000'. It leverages the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. This activity is significant as unauthorized access to emails can lead to data breaches and information theft. If confirmed malicious, attackers could exfiltrate sensitive information, compromise user accounts, and further infiltrate the organization’s network. action.notable.param.rule_title = O365 OAuth App Mailbox Access via Graph API action.notable.param.security_domain = threat action.notable.param.severity = high @@ -14257,14 +14191,14 @@ search = `o365_management_activity` Workload=Exchange Operation=MailItemsAccess [ESCU - O365 Privileged Graph API Permission Assigned - Rule] action.escu = 0 action.escu.enabled = 1 -description = This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications. +description = The following analytic detects the assignment of critical Graph API permissions in Azure AD using the O365 Unified Audit Log. It focuses on permissions such as Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. The detection method leverages Azure Active Directory workload events, specifically 'Update application' operations. This activity is significant as these permissions provide extensive control over Azure AD settings, posing a high risk if misused. If confirmed malicious, this could allow unauthorized modifications, leading to potential data breaches or privilege escalation. Immediate investigation is crucial. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications. +action.escu.eli5 = The following analytic detects the assignment of critical Graph API permissions in Azure AD using the O365 Unified Audit Log. It focuses on permissions such as Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. The detection method leverages Azure Active Directory workload events, specifically 'Update application' operations. This activity is significant as these permissions provide extensive control over Azure AD settings, posing a high risk if misused. If confirmed malicious, this could allow unauthorized modifications, leading to potential data breaches or privilege escalation. Immediate investigation is crucial. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed. -action.escu.creation_date = 2024-01-30 -action.escu.modification_date = 2024-01-30 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Privileged Graph API Permission Assigned - Rule action.escu.search_type = detection @@ -14282,11 +14216,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Privileged Graph API Permission Assigned - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 60, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "868f3131-d5e1-4bf1-af5b-9b0fbaaaedbb", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "868f3131-d5e1-4bf1-af5b-9b0fbaaaedbb", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications. +action.notable.param.rule_description = The following analytic detects the assignment of critical Graph API permissions in Azure AD using the O365 Unified Audit Log. It focuses on permissions such as Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory. The detection method leverages Azure Active Directory workload events, specifically 'Update application' operations. This activity is significant as these permissions provide extensive control over Azure AD settings, posing a high risk if misused. If confirmed malicious, this could allow unauthorized modifications, leading to potential data breaches or privilege escalation. Immediate investigation is crucial. action.notable.param.rule_title = O365 Privileged Graph API Permission Assigned action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14304,14 +14238,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Upd [ESCU - O365 PST export alert - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions. +description = The following analytic detects instances where a user has initiated an eDiscovery search or exported a PST file in an Office 365 environment. It leverages Office 365 management activity logs, specifically filtering for events under ThreatManagement with the name "eDiscovery search started or exported." This activity is significant as it may indicate data exfiltration attempts or unauthorized access to sensitive information. If confirmed malicious, it suggests an attacker or insider threat is attempting to gather or exfiltrate data, potentially leading to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions. +action.escu.eli5 = The following analytic detects instances where a user has initiated an eDiscovery search or exported a PST file in an Office 365 environment. It leverages Office 365 management activity logs, specifically filtering for events under ThreatManagement with the name "eDiscovery search started or exported." This activity is significant as it may indicate data exfiltration attempts or unauthorized access to sensitive information. If confirmed malicious, it suggests an attacker or insider threat is attempting to gather or exfiltrate data, potentially leading to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required. action.escu.how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity action.escu.known_false_positives = PST export can be done for legitimate purposes but due to the sensitive nature of its content it must be monitored. -action.escu.creation_date = 2020-12-16 -action.escu.modification_date = 2020-12-16 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 PST export alert - Rule action.escu.search_type = detection @@ -14329,11 +14263,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 PST export alert - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Office 365 Collection Techniques"], "cis20": ["CIS 10"], "confidence": 60, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f694cc4-a678-4a60-9410-bffca1b647dc", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5f694cc4-a678-4a60-9410-bffca1b647dc", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions. +action.notable.param.rule_description = The following analytic detects instances where a user has initiated an eDiscovery search or exported a PST file in an Office 365 environment. It leverages Office 365 management activity logs, specifically filtering for events under ThreatManagement with the name "eDiscovery search started or exported." This activity is significant as it may indicate data exfiltration attempts or unauthorized access to sensitive information. If confirmed malicious, it suggests an attacker or insider threat is attempting to gather or exfiltrate data, potentially leading to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required. action.notable.param.rule_title = O365 PST export alert action.notable.param.security_domain = threat action.notable.param.severity = high @@ -14351,14 +14285,14 @@ search = `o365_management_activity` Category=ThreatManagement Name="eDiscovery s [ESCU - O365 Security And Compliance Alert Triggered - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace. +description = The following analytic identifies alerts triggered by the Office 365 Security and Compliance Center, indicating potential threats or policy violations. It leverages data from the `o365_management_activity` dataset, focusing on events where the workload is SecurityComplianceCenter and the operation is AlertTriggered. This activity is significant as it highlights security and compliance issues within the O365 environment, which are crucial for maintaining organizational security. If confirmed malicious, these alerts could indicate attempts to breach security policies, leading to unauthorized access, data exfiltration, or other malicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace. +action.escu.eli5 = The following analytic identifies alerts triggered by the Office 365 Security and Compliance Center, indicating potential threats or policy violations. It leverages data from the `o365_management_activity` dataset, focusing on events where the workload is SecurityComplianceCenter and the operation is AlertTriggered. This activity is significant as it highlights security and compliance issues within the O365 environment, which are crucial for maintaining organizational security. If confirmed malicious, these alerts could indicate attempts to breach security policies, leading to unauthorized access, data exfiltration, or other malicious activities. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = O365 Security and Compliance may also generate false positives or trigger on legitimate behavior, filter as needed. -action.escu.creation_date = 2024-03-25 -action.escu.modification_date = 2024-03-25 +action.escu.creation_date = 2024-05-09 +action.escu.modification_date = 2024-05-09 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Security And Compliance Alert Triggered - Rule action.escu.search_type = detection @@ -14376,11 +14310,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Security And Compliance Alert Triggered - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 80, "impact": 60, "kill_chain_phases": ["Delivery", "Exploitation", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5b367cdd-8dfc-49ac-a9b7-6406cf27f33e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5b367cdd-8dfc-49ac-a9b7-6406cf27f33e", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace. +action.notable.param.rule_description = The following analytic identifies alerts triggered by the Office 365 Security and Compliance Center, indicating potential threats or policy violations. It leverages data from the `o365_management_activity` dataset, focusing on events where the workload is SecurityComplianceCenter and the operation is AlertTriggered. This activity is significant as it highlights security and compliance issues within the O365 environment, which are crucial for maintaining organizational security. If confirmed malicious, these alerts could indicate attempts to breach security policies, leading to unauthorized access, data exfiltration, or other malicious activities. action.notable.param.rule_title = O365 Security And Compliance Alert Triggered action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14398,14 +14332,14 @@ search = `o365_management_activity` Workload=SecurityComplianceCenter Category= [ESCU - O365 Service Principal New Client Credentials - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the addition of new credentials for Service Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application +description = The following analytic detects the addition of new credentials for Service Principals within an Office 365 tenant. It uses O365 audit logs, focusing on events related to credential modifications or additions in the AzureActiveDirectory workload. This activity is significant because Service Principals represent application identities, and their credentials allow applications to authenticate and access resources. If an attacker successfully adds or modifies these credentials, they can impersonate the application, leading to unauthorized data access, data exfiltration, or malicious operations under the application's identity. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the addition of new credentials for Service Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application +action.escu.eli5 = The following analytic detects the addition of new credentials for Service Principals within an Office 365 tenant. It uses O365 audit logs, focusing on events related to credential modifications or additions in the AzureActiveDirectory workload. This activity is significant because Service Principals represent application identities, and their credentials allow applications to authenticate and access resources. If an attacker successfully adds or modifies these credentials, they can impersonate the application, leading to unauthorized data access, data exfiltration, or malicious operations under the application's identity. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed. -action.escu.creation_date = 2023-08-31 -action.escu.modification_date = 2023-08-31 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Service Principal New Client Credentials - Rule action.escu.search_type = detection @@ -14423,11 +14357,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Service Principal New Client Credentials - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a1b229e9-d962-4222-8c62-905a8a010453", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a1b229e9-d962-4222-8c62-905a8a010453", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the addition of new credentials for Service Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application +action.notable.param.rule_description = The following analytic detects the addition of new credentials for Service Principals within an Office 365 tenant. It uses O365 audit logs, focusing on events related to credential modifications or additions in the AzureActiveDirectory workload. This activity is significant because Service Principals represent application identities, and their credentials allow applications to authenticate and access resources. If an attacker successfully adds or modifies these credentials, they can impersonate the application, leading to unauthorized data access, data exfiltration, or malicious operations under the application's identity. action.notable.param.rule_title = O365 Service Principal New Client Credentials action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14445,14 +14379,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Up [ESCU - O365 Tenant Wide Admin Consent Granted - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to organizational data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +action.escu.eli5 = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to organizational data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed. -action.escu.creation_date = 2023-09-06 -action.escu.modification_date = 2023-09-06 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 Tenant Wide Admin Consent Granted - Rule action.escu.search_type = detection @@ -14470,11 +14404,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 Tenant Wide Admin Consent Granted - Rule action.correlationsearch.annotations = {"analytic_story": ["NOBELIUM Group", "Office 365 Persistence Mechanisms"], "cis20": ["CIS 10"], "confidence": 50, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "50eaabf8-5180-4e86-bfb2-011472c359fc", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "50eaabf8-5180-4e86-bfb2-011472c359fc", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations +action.notable.param.rule_description = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to organizational data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations. action.notable.param.rule_title = O365 Tenant Wide Admin Consent Granted action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14492,14 +14426,14 @@ search = `o365_management_activity` Operation="Consent to application." | eval [ESCU - O365 User Consent Blocked for Risky Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +description = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This detection leverages O365 audit logs, specifically focusing on failed user consent actions due to system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that O365's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +action.escu.eli5 = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This detection leverages O365 audit logs, specifically focusing on failed user consent actions due to system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that O365's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. action.escu.known_false_positives = Microsofts algorithm to identify risky applications is unknown and may flag legitimate applications. -action.escu.creation_date = 2023-10-11 -action.escu.modification_date = 2023-10-11 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 User Consent Blocked for Risky Application - Rule action.escu.search_type = detection @@ -14517,11 +14451,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 User Consent Blocked for Risky Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 100, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "242e4d30-cb59-4051-b0cf-58895e218f40", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "242e4d30-cb59-4051-b0cf-58895e218f40", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. +action.notable.param.rule_description = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This detection leverages O365 audit logs, specifically focusing on failed user consent actions due to system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that O365's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation. action.notable.param.rule_title = O365 User Consent Blocked for Risky Application action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14539,14 +14473,14 @@ search = `o365_management_activity` Workload=AzureActiveDirectory Operation="Con [ESCU - O365 User Consent Denied for OAuth Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +description = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Office 365 environment. This detection leverages O365 audit logs, focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, it captures instances where users have actively rejected permission requests. This activity is significant as it may indicate users spotting potentially suspicious or unfamiliar applications. If confirmed malicious, it suggests an attempt by a potentially harmful application to gain unauthorized access, which was proactively blocked by the user. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +action.escu.eli5 = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Office 365 environment. This detection leverages O365 audit logs, focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, it captures instances where users have actively rejected permission requests. This activity is significant as it may indicate users spotting potentially suspicious or unfamiliar applications. If confirmed malicious, it suggests an attempt by a potentially harmful application to gain unauthorized access, which was proactively blocked by the user. action.escu.how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 events. action.escu.known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed. -action.escu.creation_date = 2023-10-12 -action.escu.modification_date = 2023-10-12 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - O365 User Consent Denied for OAuth Application - Rule action.escu.search_type = detection @@ -14564,11 +14498,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - O365 User Consent Denied for OAuth Application - Rule action.correlationsearch.annotations = {"analytic_story": ["Office 365 Account Takeover"], "cis20": ["CIS 10"], "confidence": 100, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2d8679ef-b075-46be-8059-c25116cb1072", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2d8679ef-b075-46be-8059-c25116cb1072", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +action.notable.param.rule_description = The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Office 365 environment. This detection leverages O365 audit logs, focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, it captures instances where users have actively rejected permission requests. This activity is significant as it may indicate users spotting potentially suspicious or unfamiliar applications. If confirmed malicious, it suggests an attempt by a potentially harmful application to gain unauthorized access, which was proactively blocked by the user. action.notable.param.rule_title = O365 User Consent Denied for OAuth Application action.notable.param.security_domain = identity action.notable.param.severity = high @@ -14586,14 +14520,14 @@ search = `o365_graph` status.errorCode=65004 | rename userPrincipalName as user [ESCU - Risk Rule for Dev Sec Ops by Repository - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts. +description = The following analytic identifies high-risk activities within repositories by correlating repository data with risk scores. It leverages risk events from the Dev Sec Ops analytic stories, summing risk scores and capturing source and user information. The detection focuses on high-risk scores above 100 and sources with more than three occurrences. This activity is significant as it highlights repositories frequently targeted by threats, providing insights into potential vulnerabilities. If confirmed malicious, attackers could exploit these repositories, leading to data breaches or infrastructure compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts. +action.escu.eli5 = The following analytic identifies high-risk activities within repositories by correlating repository data with risk scores. It leverages risk events from the Dev Sec Ops analytic stories, summing risk scores and capturing source and user information. The detection focuses on high-risk scores above 100 and sources with more than three occurrences. This activity is significant as it highlights repositories frequently targeted by threats, providing insights into potential vulnerabilities. If confirmed malicious, attackers could exploit these repositories, leading to data breaches or infrastructure compromise. action.escu.how_to_implement = Ensure that all relevant detections in the Dev Sec Ops analytic stories are enabled and are configured to create risk events in Enterprise Security. action.escu.known_false_positives = Unknown -action.escu.creation_date = 2023-10-27 -action.escu.modification_date = 2023-10-27 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Risk Rule for Dev Sec Ops by Repository - Rule action.escu.search_type = detection @@ -14606,11 +14540,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - RIR - Risk Rule for Dev Sec Ops by Repository - Rule action.correlationsearch.annotations = {"analytic_story": ["Dev Sec Ops"], "cis20": ["CIS 10"], "confidence": 100, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"], "type": "Correlation"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "161bc0ca-4651-4c13-9c27-27770660cf67", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "161bc0ca-4651-4c13-9c27-27770660cf67", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts. +action.notable.param.rule_description = The following analytic identifies high-risk activities within repositories by correlating repository data with risk scores. It leverages risk events from the Dev Sec Ops analytic stories, summing risk scores and capturing source and user information. The detection focuses on high-risk scores above 100 and sources with more than three occurrences. This activity is significant as it highlights repositories frequently targeted by threats, providing insights into potential vulnerabilities. If confirmed malicious, attackers could exploit these repositories, leading to data breaches or infrastructure compromise. action.notable.param.rule_title = RBA: Risk Rule for Dev Sec Ops by Repository action.notable.param.security_domain = cloud action.notable.param.severity = high @@ -15154,7 +15088,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count, values(DNS.dest) AS dest dc(DNS.dest) as dest_count from datamodel=Network_Resolution where DNS.message_type=QUERY by DNS.src | `drop_dm_object_name("Network_Resolution")` |where dest_count > 5 | `clients_connecting_to_multiple_dns_servers_filter` +search = | tstats `security_content_summariesonly` count, values(DNS.dest) AS dest dc(DNS.dest) as dest_count from datamodel=Network_Resolution where DNS.message_type=QUERY by DNS.src | `drop_dm_object_name("Network_Resolution")` |where dest_count > 5 | `clients_connecting_to_multiple_dns_servers_filter` [ESCU - Cloud Network Access Control List Deleted - Rule] action.escu = 0 @@ -15987,7 +15921,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count from datamodel=Network_Resolution where DNS.dest_category != dns_server AND DNS.src_category != dns_server by DNS.src DNS.dest | `drop_dm_object_name("DNS")` | `dns_query_requests_resolved_by_unauthorized_dns_servers_filter` +search = | tstats `security_content_summariesonly` count from datamodel=Network_Resolution where DNS.dest_category != dns_server AND DNS.src_category != dns_server by DNS.src DNS.dest | `drop_dm_object_name("DNS")` | `dns_query_requests_resolved_by_unauthorized_dns_servers_filter` [ESCU - DNS record changed - Rule] action.escu = 0 @@ -16399,7 +16333,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = cmd.exe Processes.process = "* /c *" by Processes.process Processes.process_name Processes.parent_process_name Processes.dest| `drop_dm_object_name(Processes)`| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | search [| tstats `security_content_summariesonly` earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = cmd.exe Processes.process = "* /c *" by Processes.process | `drop_dm_object_name(Processes)` | inputlookup append=t previously_seen_cmd_line_arguments | stats min(firstTime) as firstTime, max(lastTime) as lastTime by process | outputlookup previously_seen_cmd_line_arguments | eval newCmdLineArgument=if(firstTime >= relative_time(now(), "-70m@m"), 1, 0) | where newCmdLineArgument=1 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | table process] | `first_time_seen_command_line_argument_filter` +search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = cmd.exe Processes.process = "* /c *" by Processes.process Processes.process_name Processes.parent_process_name Processes.dest| `drop_dm_object_name(Processes)`| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | search [| tstats `security_content_summariesonly` earliest(_time) as firstTime latest(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name = cmd.exe Processes.process = "* /c *" by Processes.process | `drop_dm_object_name(Processes)` | inputlookup append=t previously_seen_cmd_line_arguments | stats min(firstTime) as firstTime, max(lastTime) as lastTime by process | outputlookup previously_seen_cmd_line_arguments | eval newCmdLineArgument=if(firstTime >= relative_time(now(), "-70m@m"), 1, 0) | where newCmdLineArgument=1 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | table process] | `first_time_seen_command_line_argument_filter` [ESCU - GCP Detect accounts with high risk roles by project - Rule] action.escu = 0 @@ -16554,7 +16488,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `google_gcp_pubsub_message` data.protoPayload.requestMetadata.callerIp!=127.0.0.1 data.protoPayload.requestMetadata.callerIp!=::1 "data.labels.authorization.k8s.io/decision"=forbid "data.protoPayload.status.message"=PERMISSION_DENIED data.protoPayload.authenticationInfo.principalEmail="system:anonymous" | rename data.protoPayload.requestMetadata.callerIp as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(data.protoPayload.methodName) as method_name values(data.protoPayload.resourceName) as resource_name values(data.protoPayload.requestMetadata.callerSuppliedUserAgent) as http_user_agent by src_ip data.resource.labels.cluster_name | rename data.resource.labels.cluster_name as cluster_name| `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `gcp_kubernetes_cluster_scan_detection_filter` +search = `google_gcp_pubsub_message` data.protoPayload.requestMetadata.callerIp!=127.0.0.1 data.protoPayload.requestMetadata.callerIp!=::1 "data.labels.authorization.k8s.io/decision"=forbid "data.protoPayload.status.message"=PERMISSION_DENIED data.protoPayload.authenticationInfo.principalEmail="system:anonymous" | rename data.protoPayload.requestMetadata.callerIp as src_ip | stats count min(_time) as firstTime max(_time) as lastTime values(data.protoPayload.methodName) as method_name values(data.protoPayload.resourceName) as resource_name values(data.protoPayload.requestMetadata.callerSuppliedUserAgent) as http_user_agent by src_ip data.resource.labels.cluster_name | rename data.resource.labels.cluster_name as cluster_name| `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `gcp_kubernetes_cluster_scan_detection_filter` [ESCU - Identify New User Accounts - Rule] action.escu = 0 @@ -17332,7 +17266,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `okta` eventType=user.session.start outcome.result=FAILURE | rename client.geographicalContext.country as country, client.geographicalContext.state as state, client.geographicalContext.city as city | stats min(_time) as firstTime max(_time) as lastTime dc(src_user) as distinct_users values(src_user) as users by src_ip, displayMessage, outcome.reason, country, state, city | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | search distinct_users > 5| `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter` +search = `okta` eventType=user.session.start outcome.result=FAILURE | rename client.geographicalContext.country as country, client.geographicalContext.state as state, client.geographicalContext.city as city | stats min(_time) as firstTime max(_time) as lastTime dc(src_user) as distinct_users values(src_user) as users by src_ip, displayMessage, outcome.reason, country, state, city | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | search distinct_users > 5| `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter` [ESCU - O365 Suspicious Admin Email Forwarding - Rule] action.escu = 0 @@ -17584,7 +17518,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `okta` eventType=app.generic.unauth_app_access_attempt | stats min(_time) as firstTime max(_time) as lastTime values(app) as Apps count by src_user, result ,displayMessage, src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_failed_sso_attempts_filter` +search = `okta` eventType=app.generic.unauth_app_access_attempt | stats min(_time) as firstTime max(_time) as lastTime values(app) as Apps count by src_user, result ,displayMessage, src_ip | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_failed_sso_attempts_filter` [ESCU - Okta ThreatInsight Login Failure with High Unknown users - Rule] action.escu = 0 @@ -17902,7 +17836,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | `prohibited_processes` | `prohibited_software_on_endpoint_filter` +search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | `prohibited_softwares` | `prohibited_software_on_endpoint_filter` [ESCU - Reg exe used to hide files directories via registry keys - Rule] action.escu = 0 @@ -18184,7 +18118,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Processes.process_name) as process_name values(Processes.parent_process_name) as parent_process_name FROM datamodel=Endpoint.Processes where Processes.process_name!=Explorer.exe AND Processes.process_name!=OpenWith.exe by Processes.process_id Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | join [| tstats `security_content_summariesonly` values(Registry.registry_path) as registry_path count from datamodel=Endpoint.Registry where Registry.registry_path=*\\Explorer\\FileExts* by Registry.process_id Registry.dest | `drop_dm_object_name("Registry")` | table process_id dest registry_path]| `suspicious_changes_to_file_associations_filter` +search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Processes.process_name) as process_name values(Processes.parent_process_name) as parent_process_name FROM datamodel=Endpoint.Processes where Processes.process_name!=Explorer.exe AND Processes.process_name!=OpenWith.exe by Processes.process_id Processes.dest | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | join [| tstats `security_content_summariesonly` values(Registry.registry_path) as registry_path count from datamodel=Endpoint.Registry where Registry.registry_path=*\\Explorer\\FileExts* by Registry.process_id Registry.dest | `drop_dm_object_name("Registry")` | table process_id dest registry_path]| `suspicious_changes_to_file_associations_filter` [ESCU - Suspicious Email - UBA Anomaly - Rule] action.escu = 0 @@ -18416,7 +18350,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | `uncommon_processes` |`uncommon_processes_on_endpoint_filter` +search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes by Processes.dest Processes.user Processes.process Processes.process_name | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Processes)` | `uncommon_processes` |`uncommon_processes_on_endpoint_filter` [ESCU - Unsigned Image Loaded by LSASS - Rule] action.escu = 0 @@ -18463,7 +18397,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `sysmon` EventID=7 Image=*lsass.exe Signed=false | stats count min(_time) as firstTime max(_time) as lastTime by dest, Image, ImageLoaded, Signed, SHA1 | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `unsigned_image_loaded_by_lsass_filter` +search = `sysmon` EventID=7 Image=*lsass.exe Signed=false | stats count min(_time) as firstTime max(_time) as lastTime by dest, Image, ImageLoaded, Signed, SHA1 | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `unsigned_image_loaded_by_lsass_filter` [ESCU - Unsuccessful Netbackup backups - Rule] action.escu = 0 @@ -18810,14 +18744,14 @@ search = | tstats `security_content_summariesonly` values(DNS.answer) as IPs min [ESCU - 7zip CommandLine To SMB Share Path - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious 7z process with commandline pointing to SMB network share. This technique was seen in CONTI LEAK tools where it use 7z to archive a sensitive files and place it in network share tmp folder. This search is a good hunting query that may give analyst a hint why specific user try to archive a file pointing to SMB user which is un usual. +description = The following analytic detects the execution of 7z or 7za processes with command lines pointing to SMB network shares. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it may indicate an attempt to archive and exfiltrate sensitive files to a network share, a technique observed in CONTI LEAK tools. If confirmed malicious, this behavior could lead to data exfiltration, compromising sensitive information and potentially aiding further attacks. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious 7z process with commandline pointing to SMB network share. This technique was seen in CONTI LEAK tools where it use 7z to archive a sensitive files and place it in network share tmp folder. This search is a good hunting query that may give analyst a hint why specific user try to archive a file pointing to SMB user which is un usual. +action.escu.eli5 = The following analytic detects the execution of 7z or 7za processes with command lines pointing to SMB network shares. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it may indicate an attempt to archive and exfiltrate sensitive files to a network share, a technique observed in CONTI LEAK tools. If confirmed malicious, this behavior could lead to data exfiltration, compromising sensitive information and potentially aiding further attacks. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-08-17 -action.escu.modification_date = 2021-08-17 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - 7zip CommandLine To SMB Share Path - Rule action.escu.search_type = detection @@ -18830,7 +18764,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - 7zip CommandLine To SMB Share Path - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01d29b48-ff6f-11eb-b81e-acde48001123", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01d29b48-ff6f-11eb-b81e-acde48001123", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -18846,14 +18780,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Access LSASS Memory for Dump Creation - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks. +description = The following analytic detects attempts to dump the LSASS process memory, a common technique in credential dumping attacks. It leverages Sysmon logs, specifically EventCode 10, to identify suspicious call traces to dbgcore.dll and dbghelp.dll associated with lsass.exe. This activity is significant as it often precedes the theft of sensitive login credentials, posing a high risk of unauthorized access to systems and data. If confirmed malicious, attackers could gain access to critical credentials, enabling further compromise and lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks. +action.escu.eli5 = The following analytic detects attempts to dump the LSASS process memory, a common technique in credential dumping attacks. It leverages Sysmon logs, specifically EventCode 10, to identify suspicious call traces to dbgcore.dll and dbghelp.dll associated with lsass.exe. This activity is significant as it often precedes the theft of sensitive login credentials, posing a high risk of unauthorized access to systems and data. If confirmed malicious, attackers could gain access to critical credentials, enabling further compromise and lateral movement within the network. action.escu.how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. action.escu.known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Access LSASS Memory for Dump Creation - Rule action.escu.search_type = detection @@ -18871,11 +18805,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Access LSASS Memory for Dump Creation - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Credential Dumping"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fb4c31b0-13e8-4155-8aa5-24de4b8d6717", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fb4c31b0-13e8-4155-8aa5-24de4b8d6717", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks. +action.notable.param.rule_description = The following analytic detects attempts to dump the LSASS process memory, a common technique in credential dumping attacks. It leverages Sysmon logs, specifically EventCode 10, to identify suspicious call traces to dbgcore.dll and dbghelp.dll associated with lsass.exe. This activity is significant as it often precedes the theft of sensitive login credentials, posing a high risk of unauthorized access to systems and data. If confirmed malicious, attackers could gain access to critical credentials, enabling further compromise and lateral movement within the network. action.notable.param.rule_title = Access LSASS Memory for Dump Creation action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -18888,19 +18822,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll* | stats count min(_time) as firstTime max(_time) as lastTime by dest, TargetImage, TargetProcessId, SourceImage, SourceProcessId | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `access_lsass_memory_for_dump_creation_filter` +search = `sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll* | stats count min(_time) as firstTime max(_time) as lastTime by dest, TargetImage, TargetProcessId, SourceImage, SourceProcessId | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `access_lsass_memory_for_dump_creation_filter` [ESCU - Account Discovery With Net App - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a potential account discovery series of command used by several malware or attack to recon the target machine. This technique is also seen in some note worthy malware like trickbot where it runs a cmd process, or even drop its module that will execute the said series of net command. This series of command are good correlation search and indicator of attacker recon if seen in the machines within a none technical user or department (HR, finance, ceo and etc) network. +description = The following analytic detects potential account discovery activities using the 'net' command, commonly employed by malware like Trickbot for reconnaissance. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line patterns and process relationships. This activity is significant as it often precedes further malicious actions, such as lateral movement or privilege escalation. If confirmed malicious, attackers could gain valuable information about user accounts, enabling them to escalate privileges or move laterally within the network, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a potential account discovery series of command used by several malware or attack to recon the target machine. This technique is also seen in some note worthy malware like trickbot where it runs a cmd process, or even drop its module that will execute the said series of net command. This series of command are good correlation search and indicator of attacker recon if seen in the machines within a none technical user or department (HR, finance, ceo and etc) network. +action.escu.eli5 = The following analytic detects potential account discovery activities using the 'net' command, commonly employed by malware like Trickbot for reconnaissance. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line patterns and process relationships. This activity is significant as it often precedes further malicious actions, such as lateral movement or privilege escalation. If confirmed malicious, attackers could gain valuable information about user accounts, enabling them to escalate privileges or move laterally within the network, posing a significant security risk. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Admin or power user may used this series of command. -action.escu.creation_date = 2023-01-04 -action.escu.modification_date = 2023-01-04 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Account Discovery With Net App - Rule action.escu.search_type = detection @@ -18918,11 +18852,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Account Discovery With Net App - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Trickbot"], "cis20": ["CIS 10"], "confidence": 50, "impact": 10, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "339805ce-ac30-11eb-b87d-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "339805ce-ac30-11eb-b87d-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a potential account discovery series of command used by several malware or attack to recon the target machine. This technique is also seen in some note worthy malware like trickbot where it runs a cmd process, or even drop its module that will execute the said series of net command. This series of command are good correlation search and indicator of attacker recon if seen in the machines within a none technical user or department (HR, finance, ceo and etc) network. +action.notable.param.rule_description = The following analytic detects potential account discovery activities using the 'net' command, commonly employed by malware like Trickbot for reconnaissance. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line patterns and process relationships. This activity is significant as it often precedes further malicious actions, such as lateral movement or privilege escalation. If confirmed malicious, attackers could gain valuable information about user accounts, enabling them to escalate privileges or move laterally within the network, posing a significant security risk. action.notable.param.rule_title = Account Discovery With Net App action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -18940,14 +18874,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Active Directory Lateral Movement Identified - Rule] action.escu = 0 action.escu.enabled = 1 -description = The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +description = The following analytic identifies potential lateral movement activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Lateral Movement analytic story within a specified time frame. This is significant for a SOC as lateral movement is a common tactic used by attackers to expand their access within a network, posing a substantial risk. If confirmed malicious, this activity could allow attackers to escalate privileges, access sensitive information, and persist within the environment, leading to severe security breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +action.escu.eli5 = The following analytic identifies potential lateral movement activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Lateral Movement analytic story within a specified time frame. This is significant for a SOC as lateral movement is a common tactic used by attackers to expand their access within a network, posing a substantial risk. If confirmed malicious, this activity could allow attackers to escalate privileges, access sensitive information, and persist within the environment, leading to severe security breaches. action.escu.how_to_implement = 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 as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance. action.escu.known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Active Directory Lateral Movement Identified - Rule action.escu.search_type = detection @@ -18960,11 +18894,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - RIR - Active Directory Lateral Movement Identified - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Lateral Movement"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"], "type": "Correlation"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6aa6f9dd-adfe-45a8-8f74-c4c7a0d7d037", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6aa6f9dd-adfe-45a8-8f74-c4c7a0d7d037", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +action.notable.param.rule_description = The following analytic identifies potential lateral movement activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Lateral Movement analytic story within a specified time frame. This is significant for a SOC as lateral movement is a common tactic used by attackers to expand their access within a network, posing a substantial risk. If confirmed malicious, this activity could allow attackers to escalate privileges, access sensitive information, and persist within the environment, leading to severe security breaches. action.notable.param.rule_title = RBA: Active Directory Lateral Movement Identified action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -18982,14 +18916,14 @@ search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_ [ESCU - Active Directory Privilege Escalation Identified - Rule] action.escu = 0 action.escu.enabled = 1 -description = The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +description = The following analytic identifies potential privilege escalation activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Privilege Escalation analytic story within a specified time frame. This is significant for a SOC as it helps identify coordinated attempts to gain elevated privileges, which could indicate a serious security threat. If confirmed malicious, this activity could allow attackers to gain unauthorized access to sensitive systems and data, leading to potential data breaches and further compromise of the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.AE"]} action.escu.data_models = ["Risk"] -action.escu.eli5 = The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +action.escu.eli5 = The following analytic identifies potential privilege escalation activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Privilege Escalation analytic story within a specified time frame. This is significant for a SOC as it helps identify coordinated attempts to gain elevated privileges, which could indicate a serious security threat. If confirmed malicious, this activity could allow attackers to gain unauthorized access to sensitive systems and data, leading to potential data breaches and further compromise of the network. action.escu.how_to_implement = 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 as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance. action.escu.known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed. -action.escu.creation_date = 2023-05-23 -action.escu.modification_date = 2023-05-23 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Active Directory Privilege Escalation Identified - Rule action.escu.search_type = detection @@ -19002,11 +18936,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - RIR - Active Directory Privilege Escalation Identified - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.AE"], "type": "Correlation"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "583e8a68-f2f7-45be-8fc9-bf725f0e22fd", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "583e8a68-f2f7-45be-8fc9-bf725f0e22fd", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization. +action.notable.param.rule_description = The following analytic identifies potential privilege escalation activities within an organization's Active Directory (AD) environment. It detects this activity by correlating multiple analytics from the Active Directory Privilege Escalation analytic story within a specified time frame. This is significant for a SOC as it helps identify coordinated attempts to gain elevated privileges, which could indicate a serious security threat. If confirmed malicious, this activity could allow attackers to gain unauthorized access to sensitive systems and data, leading to potential data breaches and further compromise of the network. action.notable.param.rule_title = RBA: Active Directory Privilege Escalation Identified action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19024,14 +18958,14 @@ search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_ [ESCU - Active Setup Registry Autostart - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is to detect a suspicious modification of the active setup registry for persistence and privilege escalation. This technique was seen in several malware (poisonIvy), adware and APT to gain persistence to the compromised machine upon boot up. This TTP is a good indicator to further check the process id that do the modification since modification of this registry is not commonly done. check the legitimacy of the file and process involve in this rules to check if it is a valid setup installer that creating or modifying this registry. +description = The following analytic detects suspicious modifications to the Active Setup registry for persistence and privilege escalation. It leverages data from the Endpoint.Registry data model, focusing on changes to the "StubPath" value within the "SOFTWARE\\Microsoft\\Active Setup\\Installed Components" path. This activity is significant as it is commonly used by malware, adware, and APTs to maintain persistence on compromised machines. If confirmed malicious, this could allow attackers to execute code upon system startup, potentially leading to further system compromise and unauthorized access. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.014", "T1547"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is to detect a suspicious modification of the active setup registry for persistence and privilege escalation. This technique was seen in several malware (poisonIvy), adware and APT to gain persistence to the compromised machine upon boot up. This TTP is a good indicator to further check the process id that do the modification since modification of this registry is not commonly done. check the legitimacy of the file and process involve in this rules to check if it is a valid setup installer that creating or modifying this registry. +action.escu.eli5 = The following analytic detects suspicious modifications to the Active Setup registry for persistence and privilege escalation. It leverages data from the Endpoint.Registry data model, focusing on changes to the "StubPath" value within the "SOFTWARE\\Microsoft\\Active Setup\\Installed Components" path. This activity is significant as it is commonly used by malware, adware, and APTs to maintain persistence on compromised machines. If confirmed malicious, this could allow attackers to execute code upon system startup, potentially leading to further system compromise and unauthorized access. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = Active setup installer may add or modify this registry. -action.escu.creation_date = 2023-04-27 -action.escu.modification_date = 2023-04-27 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Active Setup Registry Autostart - Rule action.escu.search_type = detection @@ -19049,11 +18983,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Active Setup Registry Autostart - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Destruction", "Hermetic Wiper", "Windows Persistence Techniques", "Windows Privilege Escalation"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1547.014", "T1547"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f64579c0-203f-11ec-abcc-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f64579c0-203f-11ec-abcc-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is to detect a suspicious modification of the active setup registry for persistence and privilege escalation. This technique was seen in several malware (poisonIvy), adware and APT to gain persistence to the compromised machine upon boot up. This TTP is a good indicator to further check the process id that do the modification since modification of this registry is not commonly done. check the legitimacy of the file and process involve in this rules to check if it is a valid setup installer that creating or modifying this registry. +action.notable.param.rule_description = The following analytic detects suspicious modifications to the Active Setup registry for persistence and privilege escalation. It leverages data from the Endpoint.Registry data model, focusing on changes to the "StubPath" value within the "SOFTWARE\\Microsoft\\Active Setup\\Installed Components" path. This activity is significant as it is commonly used by malware, adware, and APTs to maintain persistence on compromised machines. If confirmed malicious, this could allow attackers to execute code upon system startup, potentially leading to further system compromise and unauthorized access. action.notable.param.rule_title = Active Setup Registry Autostart action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19071,14 +19005,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Add DefaultUser And Password In Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +description = The following analytic detects suspicious registry modifications that implement auto admin logon by adding DefaultUserName and DefaultPassword values. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry path. This activity is significant because it is associated with BlackMatter ransomware, which uses this technique to automatically log on to compromised hosts and continue encryption after a safe mode boot. If confirmed malicious, this could allow attackers to maintain persistence and further encrypt the network, leading to significant data loss and operational disruption. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +action.escu.eli5 = The following analytic detects suspicious registry modifications that implement auto admin logon by adding DefaultUserName and DefaultPassword values. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry path. This activity is significant because it is associated with BlackMatter ransomware, which uses this technique to automatically log on to compromised hosts and continue encryption after a safe mode boot. If confirmed malicious, this could allow attackers to maintain persistence and further encrypt the network, leading to significant data loss and operational disruption. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-03-29 -action.escu.modification_date = 2023-03-29 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Add DefaultUser And Password In Registry - Rule action.escu.search_type = detection @@ -19096,7 +19030,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Add DefaultUser And Password In Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackMatter Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d4a3eb62-0f1e-11ec-a971-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d4a3eb62-0f1e-11ec-a971-acde48001122", "detection_version": "5"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -19112,14 +19046,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Add or Set Windows Defender Exclusion - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic will identify a suspicious process command-line related to Windows Defender exclusion feature. This command is abused by adversaries, malware authors and red teams to bypass Windows Defender Antivirus products by excluding folder path, file path, process and extensions. From its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior. +description = The following analytic detects the use of commands to add or set exclusions in Windows Defender. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "Add-MpPreference" or "Set-MpPreference" with exclusion parameters. This activity is significant because adversaries often use it to bypass Windows Defender, allowing malicious code to execute undetected. If confirmed malicious, this behavior could enable attackers to evade antivirus detection, maintain persistence, and execute further malicious activities without interference from Windows Defender. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic will identify a suspicious process command-line related to Windows Defender exclusion feature. This command is abused by adversaries, malware authors and red teams to bypass Windows Defender Antivirus products by excluding folder path, file path, process and extensions. From its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior. +action.escu.eli5 = The following analytic detects the use of commands to add or set exclusions in Windows Defender. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "Add-MpPreference" or "Set-MpPreference" with exclusion parameters. This activity is significant because adversaries often use it to bypass Windows Defender, allowing malicious code to execute undetected. If confirmed malicious, this behavior could enable attackers to evade antivirus detection, maintain persistence, and execute further malicious activities without interference from Windows Defender. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Admin or user may choose to use this windows features. Filter as needed. -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Add or Set Windows Defender Exclusion - Rule action.escu.search_type = detection @@ -19137,11 +19071,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Add or Set Windows Defender Exclusion - Rule action.correlationsearch.annotations = {"analytic_story": ["AgentTesla", "CISA AA22-320A", "Data Destruction", "Remcos", "WhisperGate", "Windows Defense Evasion Tactics"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "773b66fe-4dd9-11ec-8289-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "773b66fe-4dd9-11ec-8289-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic will identify a suspicious process command-line related to Windows Defender exclusion feature. This command is abused by adversaries, malware authors and red teams to bypass Windows Defender Antivirus products by excluding folder path, file path, process and extensions. From its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior. +action.notable.param.rule_description = The following analytic detects the use of commands to add or set exclusions in Windows Defender. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving "Add-MpPreference" or "Set-MpPreference" with exclusion parameters. This activity is significant because adversaries often use it to bypass Windows Defender, allowing malicious code to execute undetected. If confirmed malicious, this behavior could enable attackers to evade antivirus detection, maintain persistence, and execute further malicious activities without interference from Windows Defender. action.notable.param.rule_title = Add or Set Windows Defender Exclusion action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19159,14 +19093,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - AdsiSearcher Account Discovery - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain users for situational awareness and Active Directory Discovery. +description = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain users. It leverages PowerShell Script Block Logging (EventCode=4104) to identify script blocks containing `[adsisearcher]`, `objectcategory=user`, and `.findAll()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain users for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain users. It leverages PowerShell Script Block Logging (EventCode=4104) to identify script blocks containing `[adsisearcher]`, `objectcategory=user`, and `.findAll()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.escu.how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - AdsiSearcher Account Discovery - Rule action.escu.search_type = detection @@ -19184,11 +19118,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - AdsiSearcher Account Discovery - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "CISA AA23-347A", "Data Destruction", "Industroyer2"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de7fcadc-04f3-11ec-a241-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de7fcadc-04f3-11ec-a241-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain users for situational awareness and Active Directory Discovery. +action.notable.param.rule_description = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain users. It leverages PowerShell Script Block Logging (EventCode=4104) to identify script blocks containing `[adsisearcher]`, `objectcategory=user`, and `.findAll()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.notable.param.rule_title = AdsiSearcher Account Discovery action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19206,14 +19140,14 @@ search = `powershell` EventCode=4104 ScriptBlockText = "*[adsisearcher]*" Script [ESCU - Allow File And Printing Sharing In Firewall - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious modification of firewall to allow file and printer sharing. This technique was seen in ransomware to be able to discover more machine connected to the compromised host to encrypt more files +description = The following analytic detects the modification of firewall settings to allow file and printer sharing. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving 'netsh' commands that enable file and printer sharing. This activity is significant because it can indicate an attempt by ransomware to discover and encrypt files on additional machines connected to the compromised host. If confirmed malicious, this could lead to widespread file encryption across the network, significantly increasing the impact of a ransomware attack. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious modification of firewall to allow file and printer sharing. This technique was seen in ransomware to be able to discover more machine connected to the compromised host to encrypt more files +action.escu.eli5 = The following analytic detects the modification of firewall settings to allow file and printer sharing. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving 'netsh' commands that enable file and printer sharing. This activity is significant because it can indicate an attempt by ransomware to discover and encrypt files on additional machines connected to the compromised host. If confirmed malicious, this could lead to widespread file encryption across the network, significantly increasing the impact of a ransomware attack. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered. -action.escu.creation_date = 2023-12-15 -action.escu.modification_date = 2023-12-15 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Allow File And Printing Sharing In Firewall - Rule action.escu.search_type = detection @@ -19231,11 +19165,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Allow File And Printing Sharing In Firewall - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce27646e-d411-11eb-8a00-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ce27646e-d411-11eb-8a00-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a suspicious modification of firewall to allow file and printer sharing. This technique was seen in ransomware to be able to discover more machine connected to the compromised host to encrypt more files +action.notable.param.rule_description = The following analytic detects the modification of firewall settings to allow file and printer sharing. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving 'netsh' commands that enable file and printer sharing. This activity is significant because it can indicate an attempt by ransomware to discover and encrypt files on additional machines connected to the compromised host. If confirmed malicious, this could lead to widespread file encryption across the network, significantly increasing the impact of a ransomware attack. action.notable.param.rule_title = Allow File And Printing Sharing In Firewall action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19253,14 +19187,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects a potential suspicious modification of firewall rule registry allowing inbound traffic in specific port with public profile. This technique was identified when an adversary wants to grant remote access to a machine by allowing the traffic in a firewall rule. +description = The following analytic detects suspicious modifications to firewall rule registry settings that allow inbound traffic on specific ports with a public profile. It leverages data from the Endpoint.Registry data model, focusing on registry paths and values indicative of such changes. This activity is significant as it may indicate an adversary attempting to grant remote access to a machine by modifying firewall rules. If confirmed malicious, this could enable unauthorized remote access, potentially leading to further exploitation, data exfiltration, or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects a potential suspicious modification of firewall rule registry allowing inbound traffic in specific port with public profile. This technique was identified when an adversary wants to grant remote access to a machine by allowing the traffic in a firewall rule. +action.escu.eli5 = The following analytic detects suspicious modifications to firewall rule registry settings that allow inbound traffic on specific ports with a public profile. It leverages data from the Endpoint.Registry data model, focusing on registry paths and values indicative of such changes. This activity is significant as it may indicate an adversary attempting to grant remote access to a machine by modifying firewall rules. If confirmed malicious, this could enable unauthorized remote access, potentially leading to further exploitation, data exfiltration, or lateral movement within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = network admin may add/remove/modify public inbound firewall rule that may cause this rule to be triggered. -action.escu.creation_date = 2023-03-29 -action.escu.modification_date = 2023-03-29 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule action.escu.search_type = detection @@ -19278,11 +19212,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "NjRAT", "PlugX", "Prohibited Traffic Allowed or Protocol Mismatch", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0a46537c-be02-11eb-92ca-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0a46537c-be02-11eb-92ca-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects a potential suspicious modification of firewall rule registry allowing inbound traffic in specific port with public profile. This technique was identified when an adversary wants to grant remote access to a machine by allowing the traffic in a firewall rule. +action.notable.param.rule_description = The following analytic detects suspicious modifications to firewall rule registry settings that allow inbound traffic on specific ports with a public profile. It leverages data from the Endpoint.Registry data model, focusing on registry paths and values indicative of such changes. This activity is significant as it may indicate an adversary attempting to grant remote access to a machine by modifying firewall rules. If confirmed malicious, this could enable unauthorized remote access, potentially leading to further exploitation, data exfiltration, or lateral movement within the network. action.notable.param.rule_title = Allow Inbound Traffic By Firewall Rule Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19300,14 +19234,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Allow Inbound Traffic In Firewall Rule - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies suspicious PowerShell command to allow inbound traffic inbound to a specific local port within the public profile. This technique was seen in some attacker want to have a remote access to a machine by allowing the traffic in firewall rule. +description = The following analytic detects a suspicious PowerShell command that allows inbound traffic to a specific local port within the public profile. It leverages PowerShell script block logging (EventCode 4104) to identify commands containing keywords like "firewall," "Inbound," "Allow," and "-LocalPort." This activity is significant because it may indicate an attacker attempting to establish remote access by modifying firewall rules. If confirmed malicious, this could allow unauthorized access to the machine, potentially leading to further exploitation and data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies suspicious PowerShell command to allow inbound traffic inbound to a specific local port within the public profile. This technique was seen in some attacker want to have a remote access to a machine by allowing the traffic in firewall rule. +action.escu.eli5 = The following analytic detects a suspicious PowerShell command that allows inbound traffic to a specific local port within the public profile. It leverages PowerShell script block logging (EventCode 4104) to identify commands containing keywords like "firewall," "Inbound," "Allow," and "-LocalPort." This activity is significant because it may indicate an attacker attempting to establish remote access by modifying firewall rules. If confirmed malicious, this could allow unauthorized access to the machine, potentially leading to further exploitation and data exfiltration. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. action.escu.known_false_positives = administrator may allow inbound traffic in certain network or machine. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Allow Inbound Traffic In Firewall Rule - Rule action.escu.search_type = detection @@ -19325,11 +19259,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Allow Inbound Traffic In Firewall Rule - Rule action.correlationsearch.annotations = {"analytic_story": ["Prohibited Traffic Allowed or Protocol Mismatch"], "cis20": ["CIS 10"], "confidence": 30, "impact": 10, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a5d85486-b89c-11eb-8267-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a5d85486-b89c-11eb-8267-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies suspicious PowerShell command to allow inbound traffic inbound to a specific local port within the public profile. This technique was seen in some attacker want to have a remote access to a machine by allowing the traffic in firewall rule. +action.notable.param.rule_description = The following analytic detects a suspicious PowerShell command that allows inbound traffic to a specific local port within the public profile. It leverages PowerShell script block logging (EventCode 4104) to identify commands containing keywords like "firewall," "Inbound," "Allow," and "-LocalPort." This activity is significant because it may indicate an attacker attempting to establish remote access by modifying firewall rules. If confirmed malicious, this could allow unauthorized access to the machine, potentially leading to further exploitation and data exfiltration. action.notable.param.rule_title = Allow Inbound Traffic In Firewall Rule action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19347,14 +19281,14 @@ search = `powershell` EventCode=4104 ScriptBlockText = "*firewall*" ScriptBlockT [ESCU - Allow Network Discovery In Firewall - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious modification to the firewall to allow network discovery on a machine. This technique was seen in couple of ransomware (revil, reddot) to discover other machine connected to the compromised host to encrypt more files. +description = The following analytic detects a suspicious modification to the firewall to allow network discovery on a machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving the 'netsh' command to enable network discovery. This activity is significant because it is commonly used by ransomware, such as REvil and RedDot, to discover and compromise additional machines on the network. If confirmed malicious, this could lead to widespread file encryption across multiple hosts, significantly amplifying the impact of the ransomware attack. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious modification to the firewall to allow network discovery on a machine. This technique was seen in couple of ransomware (revil, reddot) to discover other machine connected to the compromised host to encrypt more files. +action.escu.eli5 = The following analytic detects a suspicious modification to the firewall to allow network discovery on a machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving the 'netsh' command to enable network discovery. This activity is significant because it is commonly used by ransomware, such as REvil and RedDot, to discover and compromise additional machines on the network. If confirmed malicious, this could lead to widespread file encryption across multiple hosts, significantly amplifying the impact of the ransomware attack. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered. -action.escu.creation_date = 2021-06-23 -action.escu.modification_date = 2021-06-23 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Allow Network Discovery In Firewall - Rule action.escu.search_type = detection @@ -19372,11 +19306,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Allow Network Discovery In Firewall - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "NjRAT", "Ransomware", "Revil Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ccd6a38c-d40b-11eb-85a5-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ccd6a38c-d40b-11eb-85a5-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a suspicious modification to the firewall to allow network discovery on a machine. This technique was seen in couple of ransomware (revil, reddot) to discover other machine connected to the compromised host to encrypt more files. +action.notable.param.rule_description = The following analytic detects a suspicious modification to the firewall to allow network discovery on a machine. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving the 'netsh' command to enable network discovery. This activity is significant because it is commonly used by ransomware, such as REvil and RedDot, to discover and compromise additional machines on the network. If confirmed malicious, this could lead to widespread file encryption across multiple hosts, significantly amplifying the impact of the ransomware attack. action.notable.param.rule_title = Allow Network Discovery In Firewall action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19394,14 +19328,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Allow Operation with Consent Admin - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies a potential privilege escalation attempt to perform malicious task. This registry modification is designed to allow the `Consent Admin` to perform an operation that requires elevation without consent or credentials. We also found this in some attacker to gain privilege escalation to the compromise machine. +description = The following analytic detects a registry modification that allows the 'Consent Admin' to perform operations requiring elevation without user consent or credentials. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the 'ConsentPromptBehaviorAdmin' value within the Windows Policies System registry path. This activity is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to execute high-privilege tasks without user approval. If confirmed malicious, this could lead to unauthorized administrative access and control over the compromised machine, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies a potential privilege escalation attempt to perform malicious task. This registry modification is designed to allow the `Consent Admin` to perform an operation that requires elevation without consent or credentials. We also found this in some attacker to gain privilege escalation to the compromise machine. +action.escu.eli5 = The following analytic detects a registry modification that allows the 'Consent Admin' to perform operations requiring elevation without user consent or credentials. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the 'ConsentPromptBehaviorAdmin' value within the Windows Policies System registry path. This activity is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to execute high-privilege tasks without user approval. If confirmed malicious, this could lead to unauthorized administrative access and control over the compromised machine, posing a severe security risk. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-03-29 -action.escu.modification_date = 2023-03-29 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Allow Operation with Consent Admin - Rule action.escu.search_type = detection @@ -19419,11 +19353,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Allow Operation with Consent Admin - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Ransomware", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7de17d7a-c9d8-11eb-a812-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7de17d7a-c9d8-11eb-a812-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies a potential privilege escalation attempt to perform malicious task. This registry modification is designed to allow the `Consent Admin` to perform an operation that requires elevation without consent or credentials. We also found this in some attacker to gain privilege escalation to the compromise machine. +action.notable.param.rule_description = The following analytic detects a registry modification that allows the 'Consent Admin' to perform operations requiring elevation without user consent or credentials. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the 'ConsentPromptBehaviorAdmin' value within the Windows Policies System registry path. This activity is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to execute high-privilege tasks without user approval. If confirmed malicious, this could lead to unauthorized administrative access and control over the compromised machine, posing a severe security risk. action.notable.param.rule_title = Allow Operation with Consent Admin action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19441,14 +19375,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Anomalous usage of 7zip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies a 7z.exe spawned from `Rundll32.exe` or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`. It has been observed where an adversary will rename `7z.exe`. Additional coverage may be required to identify the behavior of renamed instances of `7z.exe`. During triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture any files written to disk and analyze as needed. Review parallel processes for additional behaviors. Typically, archiving files will result in exfiltration. +description = The following analytic detects the execution of 7z.exe, a 7-Zip utility, spawned from rundll32.exe or dllhost.exe. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and parent processes. This activity is significant as it may indicate an adversary attempting to use 7-Zip for data exfiltration, often by renaming the executable to evade detection. If confirmed malicious, this could lead to unauthorized data archiving and exfiltration, compromising sensitive information and potentially leading to further system exploitation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following detection identifies a 7z.exe spawned from `Rundll32.exe` or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`. It has been observed where an adversary will rename `7z.exe`. Additional coverage may be required to identify the behavior of renamed instances of `7z.exe`. During triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture any files written to disk and analyze as needed. Review parallel processes for additional behaviors. Typically, archiving files will result in exfiltration. +action.escu.eli5 = The following analytic detects the execution of 7z.exe, a 7-Zip utility, spawned from rundll32.exe or dllhost.exe. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and parent processes. This activity is significant as it may indicate an adversary attempting to use 7-Zip for data exfiltration, often by renaming the executable to evade detection. If confirmed malicious, this could lead to unauthorized data archiving and exfiltration, compromising sensitive information and potentially leading to further system exploitation. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited as this behavior is not normal for `rundll32.exe` or `dllhost.exe` to spawn and run 7zip. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Anomalous usage of 7zip - Rule action.escu.search_type = detection @@ -19466,7 +19400,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Anomalous usage of 7zip - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Cobalt Strike", "Graceful Wipe Out Attack", "NOBELIUM Group"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9364ee8e-a39a-11eb-8f1d-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9364ee8e-a39a-11eb-8f1d-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -19482,14 +19416,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Any Powershell DownloadFile - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of PowerShell downloading a file using `DownloadFile` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +description = The following analytic detects the use of PowerShell's `DownloadFile` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant as it is commonly used in malicious frameworks to download and execute additional payloads. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the system. Analysts should investigate the source and destination of the download and review AMSI or PowerShell transaction logs for additional context. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the use of PowerShell downloading a file using `DownloadFile` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +action.escu.eli5 = The following analytic detects the use of PowerShell's `DownloadFile` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant as it is commonly used in malicious frameworks to download and execute additional payloads. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the system. Analysts should investigate the source and destination of the download and review AMSI or PowerShell transaction logs for additional context. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage. -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Any Powershell DownloadFile - Rule action.escu.search_type = detection @@ -19507,11 +19441,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Any Powershell DownloadFile - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkCrystal RAT", "Data Destruction", "Hermetic Wiper", "Ingress Tool Transfer", "Log4Shell CVE-2021-44228", "Malicious PowerShell", "Phemedrone Stealer"], "cis20": ["CIS 10"], "confidence": 70, "cve": ["CVE-2021-44228"], "impact": 80, "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1a93b7ea-7af7-11eb-adb5-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1a93b7ea-7af7-11eb-adb5-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of PowerShell downloading a file using `DownloadFile` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +action.notable.param.rule_description = The following analytic detects the use of PowerShell's `DownloadFile` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant as it is commonly used in malicious frameworks to download and execute additional payloads. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the system. Analysts should investigate the source and destination of the download and review AMSI or PowerShell transaction logs for additional context. action.notable.param.rule_title = Any Powershell DownloadFile action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19529,14 +19463,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Any Powershell DownloadString - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of PowerShell downloading a file using `DownloadString` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +description = The following analytic detects the use of PowerShell's `DownloadString` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because `DownloadString` is commonly used in malicious PowerShell scripts to fetch and execute remote code. If confirmed malicious, this behavior could allow an attacker to download and run arbitrary code, potentially leading to unauthorized access, data exfiltration, or further compromise of the affected system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the use of PowerShell downloading a file using `DownloadString` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +action.escu.eli5 = The following analytic detects the use of PowerShell's `DownloadString` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because `DownloadString` is commonly used in malicious PowerShell scripts to fetch and execute remote code. If confirmed malicious, this behavior could allow an attacker to download and run arbitrary code, potentially leading to unauthorized access, data exfiltration, or further compromise of the affected system. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage. -action.escu.creation_date = 2023-04-05 -action.escu.modification_date = 2023-04-05 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Any Powershell DownloadString - Rule action.escu.search_type = detection @@ -19554,11 +19488,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Any Powershell DownloadString - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Destruction", "HAFNIUM Group", "Hermetic Wiper", "IcedID", "Ingress Tool Transfer", "Malicious PowerShell", "Phemedrone Stealer", "SysAid On-Prem Software CVE-2023-47246 Vulnerability", "Winter Vivern"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Command and Control", "Installation"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d015ef2-7adf-11eb-95da-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4d015ef2-7adf-11eb-95da-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of PowerShell downloading a file using `DownloadString` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant. +action.notable.param.rule_description = The following analytic detects the use of PowerShell's `DownloadString` method to download files. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because `DownloadString` is commonly used in malicious PowerShell scripts to fetch and execute remote code. If confirmed malicious, this behavior could allow an attacker to download and run arbitrary code, potentially leading to unauthorized access, data exfiltration, or further compromise of the affected system. action.notable.param.rule_title = Any Powershell DownloadString action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19576,14 +19510,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Attacker Tools On Endpoint - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives. +description = The following analytic detects the execution of tools commonly exploited by cybercriminals, such as those used for unauthorized access, network scanning, or data exfiltration. It leverages process activity data from Endpoint Detection and Response (EDR) agents, focusing on known attacker tool names. This activity is significant because it serves as an early warning system for potential security incidents, enabling prompt response. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further network compromise, posing a severe threat to the organization's security infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Reconnaissance"], "mitre_attack": ["T1036.005", "T1036", "T1003", "T1595"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives. +action.escu.eli5 = The following analytic detects the execution of tools commonly exploited by cybercriminals, such as those used for unauthorized access, network scanning, or data exfiltration. It leverages process activity data from Endpoint Detection and Response (EDR) agents, focusing on known attacker tool names. This activity is significant because it serves as an early warning system for potential security incidents, enabling prompt response. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further network compromise, posing a severe threat to the organization's security infrastructure. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Some administrator activity can be potentially triggered, please add those users to the filter macro. -action.escu.creation_date = 2024-01-01 -action.escu.modification_date = 2024-01-01 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Attacker Tools On Endpoint - Rule action.escu.search_type = detection @@ -19601,11 +19535,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Attacker Tools On Endpoint - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-264A", "Monitor for Unauthorized Software", "SamSam Ransomware", "Unusual Processes", "XMRig"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Reconnaissance"], "mitre_attack": ["T1036.005", "T1036", "T1003", "T1595"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a51bfe1a-94f0-48cc-b4e4-16a110145893", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a51bfe1a-94f0-48cc-b4e4-16a110145893", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives. +action.notable.param.rule_description = The following analytic detects the execution of tools commonly exploited by cybercriminals, such as those used for unauthorized access, network scanning, or data exfiltration. It leverages process activity data from Endpoint Detection and Response (EDR) agents, focusing on known attacker tool names. This activity is significant because it serves as an early warning system for potential security incidents, enabling prompt response. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further network compromise, posing a severe threat to the organization's security infrastructure. action.notable.param.rule_title = Attacker Tools On Endpoint action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19623,14 +19557,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Attempt To Add Certificate To Untrusted Store - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security. +description = The following analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. It leverages process activity and command-line arguments from Endpoint Detection and Response (EDR) logs mapped to the Splunk `Processes` data model. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security. +action.escu.eli5 = The following analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. It leverages process activity and command-line arguments from Endpoint Detection and Response (EDR) logs mapped to the Splunk `Processes` data model. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = There may be legitimate reasons for administrators to add a certificate to the untrusted certificate store. In such cases, this will typically be done on a large number of systems. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Attempt To Add Certificate To Untrusted Store - Rule action.escu.search_type = detection @@ -19648,11 +19582,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Attempt To Add Certificate To Untrusted Store - Rule action.correlationsearch.annotations = {"analytic_story": ["Disabling Security Tools"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6bc5243e-ef36-45dc-9b12-f4a6be131159", "detection_version": "7"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6bc5243e-ef36-45dc-9b12-f4a6be131159", "detection_version": "8"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security. +action.notable.param.rule_description = The following analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. It leverages process activity and command-line arguments from Endpoint Detection and Response (EDR) logs mapped to the Splunk `Processes` data model. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment. action.notable.param.rule_title = Attempt To Add Certificate To Untrusted Store action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19670,14 +19604,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Attempt To Stop Security Service - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack. +description = The following analytic detects attempts to stop security-related services on an endpoint, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, specifically searching for processes involving the "sc.exe" command with the "stop" parameter. This activity is significant because disabling security services can undermine the organization's security posture, potentially leading to unauthorized access, data exfiltration, or further attacks like malware installation or privilege escalation. If confirmed malicious, this behavior could compromise the endpoint and the entire network, necessitating immediate investigation and response. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack. +action.escu.eli5 = The following analytic detects attempts to stop security-related services on an endpoint, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, specifically searching for processes involving the "sc.exe" command with the "stop" parameter. This activity is significant because disabling security services can undermine the organization's security posture, potentially leading to unauthorized access, data exfiltration, or further attacks like malware installation or privilege escalation. If confirmed malicious, this behavior could compromise the endpoint and the entire network, necessitating immediate investigation and response. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = None identified. Attempts to disable security-related services should be identified and understood. -action.escu.creation_date = 2023-06-13 -action.escu.modification_date = 2023-06-13 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Attempt To Stop Security Service - Rule action.escu.search_type = detection @@ -19695,11 +19629,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Attempt To Stop Security Service - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Data Destruction", "Disabling Security Tools", "Graceful Wipe Out Attack", "Trickbot", "WhisperGate"], "cis20": ["CIS 10"], "confidence": 50, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c8e349c6-b97c-486e-8949-bd7bcd1f3910", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c8e349c6-b97c-486e-8949-bd7bcd1f3910", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack. +action.notable.param.rule_description = The following analytic detects attempts to stop security-related services on an endpoint, which may indicate malicious activity. It leverages data from Endpoint Detection and Response (EDR) agents, specifically searching for processes involving the "sc.exe" command with the "stop" parameter. This activity is significant because disabling security services can undermine the organization's security posture, potentially leading to unauthorized access, data exfiltration, or further attacks like malware installation or privilege escalation. If confirmed malicious, this behavior could compromise the endpoint and the entire network, necessitating immediate investigation and response. action.notable.param.rule_title = Attempt To Stop Security Service action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19764,14 +19698,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Auto Admin Logon Registry Entry - Rule] action.escu = 0 action.escu.enabled = 1 -description = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +description = The following analytic detects a suspicious registry modification that enables auto admin logon on a host. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "AutoAdminLogon" value within the "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" registry path. This activity is significant because it was observed in BlackMatter ransomware attacks to maintain access after a safe mode reboot, facilitating further encryption. If confirmed malicious, this could allow attackers to automatically log in and continue their operations, potentially leading to widespread network encryption and data loss. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +action.escu.eli5 = The following analytic detects a suspicious registry modification that enables auto admin logon on a host. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "AutoAdminLogon" value within the "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" registry path. This activity is significant because it was observed in BlackMatter ransomware attacks to maintain access after a safe mode reboot, facilitating further encryption. If confirmed malicious, this could allow attackers to automatically log in and continue their operations, potentially leading to widespread network encryption and data loss. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-04-11 -action.escu.modification_date = 2023-04-11 +action.escu.creation_date = 2024-05-10 +action.escu.modification_date = 2024-05-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Auto Admin Logon Registry Entry - Rule action.escu.search_type = detection @@ -19789,11 +19723,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Auto Admin Logon Registry Entry - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackMatter Ransomware", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1379d2b8-0f18-11ec-8ca3-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1379d2b8-0f18-11ec-8ca3-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise. +action.notable.param.rule_description = The following analytic detects a suspicious registry modification that enables auto admin logon on a host. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "AutoAdminLogon" value within the "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" registry path. This activity is significant because it was observed in BlackMatter ransomware attacks to maintain access after a safe mode reboot, facilitating further encryption. If confirmed malicious, this could allow attackers to automatically log in and continue their operations, potentially leading to widespread network encryption and data loss. action.notable.param.rule_title = Auto Admin Logon Registry Entry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19858,14 +19792,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Bcdedit Command Back To Normal Mode Boot - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious bcdedit commandline to configure the host from safe mode back to normal boot configuration. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +description = The following analytic detects the execution of a suspicious `bcdedit` command that reconfigures a host from safe mode back to normal boot. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant as it may indicate the presence of ransomware, such as BlackMatter, which manipulates boot configurations to facilitate encryption processes. If confirmed malicious, this behavior could allow attackers to maintain control over the boot process, potentially leading to further system compromise and data encryption. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious bcdedit commandline to configure the host from safe mode back to normal boot configuration. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +action.escu.eli5 = The following analytic detects the execution of a suspicious `bcdedit` command that reconfigures a host from safe mode back to normal boot. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant as it may indicate the presence of ransomware, such as BlackMatter, which manipulates boot configurations to facilitate encryption processes. If confirmed malicious, this behavior could allow attackers to maintain control over the boot process, potentially leading to further system compromise and data encryption. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-06 -action.escu.modification_date = 2021-09-06 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Bcdedit Command Back To Normal Mode Boot - Rule action.escu.search_type = detection @@ -19883,11 +19817,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Bcdedit Command Back To Normal Mode Boot - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackMatter Ransomware"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc7a8004-0f18-11ec-8c54-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc7a8004-0f18-11ec-8c54-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a suspicious bcdedit commandline to configure the host from safe mode back to normal boot configuration. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +action.notable.param.rule_description = The following analytic detects the execution of a suspicious `bcdedit` command that reconfigures a host from safe mode back to normal boot. This detection leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant as it may indicate the presence of ransomware, such as BlackMatter, which manipulates boot configurations to facilitate encryption processes. If confirmed malicious, this behavior could allow attackers to maintain control over the boot process, potentially leading to further system compromise and data encryption. action.notable.param.rule_title = Bcdedit Command Back To Normal Mode Boot action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19952,14 +19886,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - BITS Job Persistence - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. The query identifies the parameters used to create, resume or add a file to a BITS job. Typically seen combined in a oneliner or ran in sequence. If identified, review the BITS job created and capture any files written to disk. It is possible for BITS to be used to upload files and this may require further network data analysis to identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +description = The following analytic detects the use of `bitsadmin.exe` to schedule a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line parameters such as `create`, `addfile`, and `resume`. This activity is significant because BITS jobs can be used by attackers to maintain persistence, download malicious payloads, or exfiltrate data. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or transfer sensitive information, necessitating further investigation and potential remediation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. The query identifies the parameters used to create, resume or add a file to a BITS job. Typically seen combined in a oneliner or ran in sequence. If identified, review the BITS job created and capture any files written to disk. It is possible for BITS to be used to upload files and this may require further network data analysis to identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +action.escu.eli5 = The following analytic detects the use of `bitsadmin.exe` to schedule a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line parameters such as `create`, `addfile`, and `resume`. This activity is significant because BITS jobs can be used by attackers to maintain persistence, download malicious payloads, or exfiltrate data. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or transfer sensitive information, necessitating further investigation and potential remediation. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives will be present. Typically, applications will use `BitsAdmin.exe`. Any filtering should be done based on command-line arguments (legitimate applications) or parent process. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - BITS Job Persistence - Rule action.escu.search_type = detection @@ -19977,11 +19911,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - BITS Job Persistence - Rule action.correlationsearch.annotations = {"analytic_story": ["BITS Jobs", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e97a5ffe-90bf-11eb-928a-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e97a5ffe-90bf-11eb-928a-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. The query identifies the parameters used to create, resume or add a file to a BITS job. Typically seen combined in a oneliner or ran in sequence. If identified, review the BITS job created and capture any files written to disk. It is possible for BITS to be used to upload files and this may require further network data analysis to identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +action.notable.param.rule_description = The following analytic detects the use of `bitsadmin.exe` to schedule a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line parameters such as `create`, `addfile`, and `resume`. This activity is significant because BITS jobs can be used by attackers to maintain persistence, download malicious payloads, or exfiltrate data. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or transfer sensitive information, necessitating further investigation and potential remediation. action.notable.param.rule_title = BITS Job Persistence action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -19999,14 +19933,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - BITSAdmin Download File - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote object. In addition, look for `download` or `upload` on the command-line, the switches are not required to perform a transfer. Capture any files downloaded. Review the reputation of the IP or domain used. Typically once executed, a follow on command will be used to execute the dropped file. Note that the network connection or file modification events related will not spawn or create from `bitsadmin.exe`, but the artifacts will appear in a parallel process of `svchost.exe` with a command-line similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel and child processes to capture any behaviors and artifacts. In some suspicious and malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +description = The following analytic detects the use of `bitsadmin.exe` with the `transfer` parameter to download a remote object. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because `bitsadmin.exe` can be exploited to download and execute malicious files without immediate detection. If confirmed malicious, an attacker could use this technique to download and execute payloads, potentially leading to code execution, privilege escalation, or persistent access within the environment. Review parallel and child processes, especially `svchost.exe`, for associated artifacts. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation", "Installation"], "mitre_attack": ["T1197", "T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote object. In addition, look for `download` or `upload` on the command-line, the switches are not required to perform a transfer. Capture any files downloaded. Review the reputation of the IP or domain used. Typically once executed, a follow on command will be used to execute the dropped file. Note that the network connection or file modification events related will not spawn or create from `bitsadmin.exe`, but the artifacts will appear in a parallel process of `svchost.exe` with a command-line similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel and child processes to capture any behaviors and artifacts. In some suspicious and malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +action.escu.eli5 = The following analytic detects the use of `bitsadmin.exe` with the `transfer` parameter to download a remote object. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because `bitsadmin.exe` can be exploited to download and execute malicious files without immediate detection. If confirmed malicious, an attacker could use this technique to download and execute payloads, potentially leading to code execution, privilege escalation, or persistent access within the environment. Review parallel and child processes, especially `svchost.exe`, for associated artifacts. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives, however it may be required to filter based on parent process name or network connection. -action.escu.creation_date = 2022-11-29 -action.escu.modification_date = 2022-11-29 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - BITSAdmin Download File - Rule action.escu.search_type = detection @@ -20024,11 +19958,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - BITSAdmin Download File - Rule action.correlationsearch.annotations = {"analytic_story": ["BITS Jobs", "DarkSide Ransomware", "Flax Typhoon", "Ingress Tool Transfer", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Command and Control", "Exploitation", "Installation"], "mitre_attack": ["T1197", "T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "80630ff4-8e4c-11eb-aab5-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "80630ff4-8e4c-11eb-aab5-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote object. In addition, look for `download` or `upload` on the command-line, the switches are not required to perform a transfer. Capture any files downloaded. Review the reputation of the IP or domain used. Typically once executed, a follow on command will be used to execute the dropped file. Note that the network connection or file modification events related will not spawn or create from `bitsadmin.exe`, but the artifacts will appear in a parallel process of `svchost.exe` with a command-line similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel and child processes to capture any behaviors and artifacts. In some suspicious and malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` to list out the jobs during investigation. +action.notable.param.rule_description = The following analytic detects the use of `bitsadmin.exe` with the `transfer` parameter to download a remote object. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because `bitsadmin.exe` can be exploited to download and execute malicious files without immediate detection. If confirmed malicious, an attacker could use this technique to download and execute payloads, potentially leading to code execution, privilege escalation, or persistent access within the environment. Review parallel and child processes, especially `svchost.exe`, for associated artifacts. action.notable.param.rule_title = BITSAdmin Download File action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20046,14 +19980,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - CertUtil Download With URLCache and Split Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = Certutil.exe may download a file from a remote destination using `-urlcache`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. However, it is uncommon for `certutil.exe` to write files to world writeable paths. During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. +description = The following analytic detects the use of certutil.exe to download files using the `-urlcache` and `-split` arguments. It leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions that include these specific arguments. This activity is significant because certutil.exe is typically used for certificate services, and its use to download files from remote locations is uncommon and potentially malicious. If confirmed, this behavior could indicate an attempt to download and execute malicious payloads, leading to potential system compromise and unauthorized data access. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = Certutil.exe may download a file from a remote destination using `-urlcache`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. However, it is uncommon for `certutil.exe` to write files to world writeable paths. During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. +action.escu.eli5 = The following analytic detects the use of certutil.exe to download files using the `-urlcache` and `-split` arguments. It leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions that include these specific arguments. This activity is significant because certutil.exe is typically used for certificate services, and its use to download files from remote locations is uncommon and potentially malicious. If confirmed, this behavior could indicate an attempt to download and execute malicious payloads, leading to potential system compromise and unauthorized data access. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection. -action.escu.creation_date = 2022-02-03 -action.escu.modification_date = 2022-02-03 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - CertUtil Download With URLCache and Split Arguments - Rule action.escu.search_type = detection @@ -20071,11 +20005,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CertUtil Download With URLCache and Split Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-277A", "DarkSide Ransomware", "Flax Typhoon", "Forest Blizzard", "Ingress Tool Transfer", "Living Off The Land", "ProxyNotShell"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "415b4306-8bfb-11eb-85c4-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "415b4306-8bfb-11eb-85c4-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Certutil.exe may download a file from a remote destination using `-urlcache`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. However, it is uncommon for `certutil.exe` to write files to world writeable paths. During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. +action.notable.param.rule_description = The following analytic detects the use of certutil.exe to download files using the `-urlcache` and `-split` arguments. It leverages Endpoint Detection and Response (EDR) data, focusing on command-line executions that include these specific arguments. This activity is significant because certutil.exe is typically used for certificate services, and its use to download files from remote locations is uncommon and potentially malicious. If confirmed, this behavior could indicate an attempt to download and execute malicious payloads, leading to potential system compromise and unauthorized data access. action.notable.param.rule_title = CertUtil Download With URLCache and Split Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20093,14 +20027,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = Certutil.exe may download a file from a remote destination using `-VerifyCtl`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. \ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. Using `-VerifyCtl`, the file will either be written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\`. +description = The following analytic detects the use of `certutil.exe` to download files using the `-VerifyCtl` and `-split` arguments. This behavior is identified by monitoring command-line executions for these specific arguments via Endpoint Detection and Response (EDR) telemetry. This activity is significant because `certutil.exe` is a legitimate tool often abused by attackers to download and execute malicious payloads. If confirmed malicious, this could allow an attacker to download and execute arbitrary files, potentially leading to code execution, data exfiltration, or further compromise of the system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = Certutil.exe may download a file from a remote destination using `-VerifyCtl`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. \ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. Using `-VerifyCtl`, the file will either be written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\`. +action.escu.eli5 = The following analytic detects the use of `certutil.exe` to download files using the `-VerifyCtl` and `-split` arguments. This behavior is identified by monitoring command-line executions for these specific arguments via Endpoint Detection and Response (EDR) telemetry. This activity is significant because `certutil.exe` is a legitimate tool often abused by attackers to download and execute malicious payloads. If confirmed malicious, this could allow an attacker to download and execute arbitrary files, potentially leading to code execution, data exfiltration, or further compromise of the system. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection. -action.escu.creation_date = 2022-02-03 -action.escu.modification_date = 2022-02-03 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule action.escu.search_type = detection @@ -20118,11 +20052,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkSide Ransomware", "Ingress Tool Transfer", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "801ad9e4-8bfb-11eb-8b31-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "801ad9e4-8bfb-11eb-8b31-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Certutil.exe may download a file from a remote destination using `-VerifyCtl`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. \ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. Using `-VerifyCtl`, the file will either be written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\`. +action.notable.param.rule_description = The following analytic detects the use of `certutil.exe` to download files using the `-VerifyCtl` and `-split` arguments. This behavior is identified by monitoring command-line executions for these specific arguments via Endpoint Detection and Response (EDR) telemetry. This activity is significant because `certutil.exe` is a legitimate tool often abused by attackers to download and execute malicious payloads. If confirmed malicious, this could allow an attacker to download and execute arbitrary files, potentially leading to code execution, data exfiltration, or further compromise of the system. action.notable.param.rule_title = CertUtil Download With VerifyCtl and Split Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20187,14 +20121,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - CertUtil With Decode Argument - Rule] action.escu = 0 action.escu.enabled = 1 -description = CertUtil.exe may be used to `encode` and `decode` a file, including PE and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded file that was downloaded. Once decoded, it will be loaded by a parallel process. Note that there are two additional command switches that may be used - `encodehex` and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for further execution. During triage, identify the source of the file being decoded. Review its contents or execution behavior for further analysis. +description = The following analytic detects the use of CertUtil.exe with the 'decode' argument, which may indicate an attempt to decode a previously encoded file, potentially containing malicious payloads. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving CertUtil.exe. This activity is significant because attackers often use CertUtil to decode malicious files downloaded from the internet, which are then executed to compromise the system. If confirmed malicious, this activity could lead to unauthorized code execution, further system compromise, and potential data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1140"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = CertUtil.exe may be used to `encode` and `decode` a file, including PE and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded file that was downloaded. Once decoded, it will be loaded by a parallel process. Note that there are two additional command switches that may be used - `encodehex` and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for further execution. During triage, identify the source of the file being decoded. Review its contents or execution behavior for further analysis. +action.escu.eli5 = The following analytic detects the use of CertUtil.exe with the 'decode' argument, which may indicate an attempt to decode a previously encoded file, potentially containing malicious payloads. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving CertUtil.exe. This activity is significant because attackers often use CertUtil to decode malicious files downloaded from the internet, which are then executed to compromise the system. If confirmed malicious, this activity could lead to unauthorized code execution, further system compromise, and potential data exfiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Typically seen used to `encode` files, but it is possible to see legitimate use of `decode`. Filter based on parent-child relationship, file paths, endpoint or user. -action.escu.creation_date = 2021-03-23 -action.escu.modification_date = 2021-03-23 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - CertUtil With Decode Argument - Rule action.escu.search_type = detection @@ -20212,11 +20146,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CertUtil With Decode Argument - Rule action.correlationsearch.annotations = {"analytic_story": ["APT29 Diplomatic Deceptions with WINELOADER", "Deobfuscate-Decode Files or Information", "Forest Blizzard", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 80, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1140"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bfe94226-8c10-11eb-a4b3-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bfe94226-8c10-11eb-a4b3-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = CertUtil.exe may be used to `encode` and `decode` a file, including PE and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded file that was downloaded. Once decoded, it will be loaded by a parallel process. Note that there are two additional command switches that may be used - `encodehex` and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for further execution. During triage, identify the source of the file being decoded. Review its contents or execution behavior for further analysis. +action.notable.param.rule_description = The following analytic detects the use of CertUtil.exe with the 'decode' argument, which may indicate an attempt to decode a previously encoded file, potentially containing malicious payloads. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving CertUtil.exe. This activity is significant because attackers often use CertUtil to decode malicious files downloaded from the internet, which are then executed to compromise the system. If confirmed malicious, this activity could lead to unauthorized code execution, further system compromise, and potential data exfiltration. action.notable.param.rule_title = CertUtil With Decode Argument action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20234,14 +20168,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Change Default File Association - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is developed to detect suspicious registry modification to change the default file association of windows to malicious payload. This technique was seen in some APT where it modify the default process to run file association, like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other payload that will load malicious commands to the compromised host. +description = The following analytic detects suspicious registry modifications that change the default file association to execute a malicious payload. It leverages data from the Endpoint data model, specifically monitoring registry paths under "*\\shell\\open\\command\\*" and "*HKCR\\*". This activity is significant because altering default file associations can allow attackers to execute arbitrary scripts or payloads when a user opens a file, leading to potential code execution. If confirmed malicious, this technique can enable attackers to persist on the compromised host and execute further malicious commands, posing a severe threat to the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is developed to detect suspicious registry modification to change the default file association of windows to malicious payload. This technique was seen in some APT where it modify the default process to run file association, like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other payload that will load malicious commands to the compromised host. +action.escu.eli5 = The following analytic detects suspicious registry modifications that change the default file association to execute a malicious payload. It leverages data from the Endpoint data model, specifically monitoring registry paths under "*\\shell\\open\\command\\*" and "*HKCR\\*". This activity is significant because altering default file associations can allow attackers to execute arbitrary scripts or payloads when a user opens a file, leading to potential code execution. If confirmed malicious, this technique can enable attackers to persist on the compromised host and execute further malicious commands, posing a severe threat to the environment. action.escu.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 endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Change Default File Association - Rule action.escu.search_type = detection @@ -20259,11 +20193,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Change Default File Association - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Destruction", "Hermetic Wiper", "Prestige Ransomware", "Windows Persistence Techniques", "Windows Privilege Escalation", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "462d17d8-1f71-11ec-ad07-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "462d17d8-1f71-11ec-ad07-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is developed to detect suspicious registry modification to change the default file association of windows to malicious payload. This technique was seen in some APT where it modify the default process to run file association, like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other payload that will load malicious commands to the compromised host. +action.notable.param.rule_description = The following analytic detects suspicious registry modifications that change the default file association to execute a malicious payload. It leverages data from the Endpoint data model, specifically monitoring registry paths under "*\\shell\\open\\command\\*" and "*HKCR\\*". This activity is significant because altering default file associations can allow attackers to execute arbitrary scripts or payloads when a user opens a file, leading to potential code execution. If confirmed malicious, this technique can enable attackers to persist on the compromised host and execute further malicious commands, posing a severe threat to the environment. action.notable.param.rule_title = Change Default File Association action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20281,14 +20215,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTim [ESCU - Change To Safe Mode With Network Config - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious bcdedit commandline to configure the host to boot in safe mode with network config. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +description = The following analytic detects the execution of a suspicious `bcdedit` command that configures a host to boot in safe mode with network support. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant because it is a known technique used by BlackMatter ransomware to force a compromised host into safe mode for continued encryption. If confirmed malicious, this could allow attackers to bypass certain security controls, persist in the environment, and continue their malicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious bcdedit commandline to configure the host to boot in safe mode with network config. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +action.escu.eli5 = The following analytic detects the execution of a suspicious `bcdedit` command that configures a host to boot in safe mode with network support. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant because it is a known technique used by BlackMatter ransomware to force a compromised host into safe mode for continued encryption. If confirmed malicious, this could allow attackers to bypass certain security controls, persist in the environment, and continue their malicious activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-06 -action.escu.modification_date = 2021-09-06 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Change To Safe Mode With Network Config - Rule action.escu.search_type = detection @@ -20306,11 +20240,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Change To Safe Mode With Network Config - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackMatter Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "81f1dce0-0f18-11ec-a5d7-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "81f1dce0-0f18-11ec-a5d7-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a suspicious bcdedit commandline to configure the host to boot in safe mode with network config. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal. +action.notable.param.rule_description = The following analytic detects the execution of a suspicious `bcdedit` command that configures a host to boot in safe mode with network support. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `bcdedit.exe` with specific parameters. This activity is significant because it is a known technique used by BlackMatter ransomware to force a compromised host into safe mode for continued encryption. If confirmed malicious, this could allow attackers to bypass certain security controls, persist in the environment, and continue their malicious activities. action.notable.param.rule_title = Change To Safe Mode With Network Config action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20328,14 +20262,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - CHCP Command Execution - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect execution of chcp.exe application. this utility is used to change the active code page of the console. This technique was seen in icedid malware to know the locale region/language/country of the compromise host. +description = The following analytic detects the execution of the chcp.exe application, which is used to change the active code page of the console. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where chcp.exe is executed by cmd.exe with specific command-line arguments. This activity is significant because it can indicate the presence of malware, such as IcedID, which uses this technique to determine the locale region, language, or country of the compromised host. If confirmed malicious, this could lead to further system compromise and data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect execution of chcp.exe application. this utility is used to change the active code page of the console. This technique was seen in icedid malware to know the locale region/language/country of the compromise host. +action.escu.eli5 = The following analytic detects the execution of the chcp.exe application, which is used to change the active code page of the console. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where chcp.exe is executed by cmd.exe with specific command-line arguments. This activity is significant because it can indicate the presence of malware, such as IcedID, which uses this technique to determine the locale region, language, or country of the compromised host. If confirmed malicious, this could lead to further system compromise and data exfiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = other tools or script may used this to change code page to UTF-* or others -action.escu.creation_date = 2021-07-27 -action.escu.modification_date = 2021-07-27 +action.escu.creation_date = 2024-05-09 +action.escu.modification_date = 2024-05-09 action.escu.confidence = high action.escu.full_search_name = ESCU - CHCP Command Execution - Rule action.escu.search_type = detection @@ -20353,11 +20287,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CHCP Command Execution - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Forest Blizzard", "IcedID"], "cis20": ["CIS 10"], "confidence": 30, "impact": 30, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "21d236ec-eec1-11eb-b23e-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "21d236ec-eec1-11eb-b23e-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect execution of chcp.exe application. this utility is used to change the active code page of the console. This technique was seen in icedid malware to know the locale region/language/country of the compromise host. +action.notable.param.rule_description = The following analytic detects the execution of the chcp.exe application, which is used to change the active code page of the console. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where chcp.exe is executed by cmd.exe with specific command-line arguments. This activity is significant because it can indicate the presence of malware, such as IcedID, which uses this technique to determine the locale region, language, or country of the compromised host. If confirmed malicious, this could lead to further system compromise and data exfiltration. action.notable.param.rule_title = CHCP Command Execution action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20375,14 +20309,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Check Elevated CMD using whoami - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious whoami execution to check if the cmd or shell instance process is with elevated privileges. This technique was seen in FIN7 js implant where it execute this as part of its data collection to the infected machine to check if the running shell cmd process is elevated or not. This TTP is really a good alert for known attacker that recon on the targetted host. This command is not so commonly executed by a normal user or even an admin to check if a process is elevated. +description = The following analytic identifies the execution of the 'whoami' command with specific parameters to check for elevated privileges. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because it is commonly used by attackers, such as FIN7, to perform reconnaissance on a compromised host. If confirmed malicious, this behavior could indicate an attacker is assessing their privilege level, potentially leading to further privilege escalation or persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a suspicious whoami execution to check if the cmd or shell instance process is with elevated privileges. This technique was seen in FIN7 js implant where it execute this as part of its data collection to the infected machine to check if the running shell cmd process is elevated or not. This TTP is really a good alert for known attacker that recon on the targetted host. This command is not so commonly executed by a normal user or even an admin to check if a process is elevated. +action.escu.eli5 = The following analytic identifies the execution of the 'whoami' command with specific parameters to check for elevated privileges. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because it is commonly used by attackers, such as FIN7, to perform reconnaissance on a compromised host. If confirmed malicious, this behavior could indicate an attacker is assessing their privilege level, potentially leading to further privilege escalation or persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-15 -action.escu.modification_date = 2021-09-15 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Check Elevated CMD using whoami - Rule action.escu.search_type = detection @@ -20400,11 +20334,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Check Elevated CMD using whoami - Rule action.correlationsearch.annotations = {"analytic_story": ["FIN7"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9079b18-1633-11ec-859c-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9079b18-1633-11ec-859c-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a suspicious whoami execution to check if the cmd or shell instance process is with elevated privileges. This technique was seen in FIN7 js implant where it execute this as part of its data collection to the infected machine to check if the running shell cmd process is elevated or not. This TTP is really a good alert for known attacker that recon on the targetted host. This command is not so commonly executed by a normal user or even an admin to check if a process is elevated. +action.notable.param.rule_description = The following analytic identifies the execution of the 'whoami' command with specific parameters to check for elevated privileges. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant because it is commonly used by attackers, such as FIN7, to perform reconnaissance on a compromised host. If confirmed malicious, this behavior could indicate an attacker is assessing their privilege level, potentially leading to further privilege escalation or persistence within the environment. action.notable.param.rule_title = Check Elevated CMD using whoami action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20464,7 +20398,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count values(Processes.process_name) as process_name values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=spoolsv.exe AND Processes.process_name!=regsvr32.exe by Processes.dest Processes.parent_process Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `child_processes_of_spoolsv_exe_filter` +search = | tstats `security_content_summariesonly` count values(Processes.process_name) as process_name values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=spoolsv.exe AND Processes.process_name!=regsvr32.exe by Processes.dest Processes.parent_process Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `child_processes_of_spoolsv_exe_filter` [ESCU - Clear Unallocated Sector Using Cipher App - Rule] action.escu = 0 @@ -20516,14 +20450,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Clop Common Exec Parameter - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytics are designed to identifies some CLOP ransomware variant that using arguments to execute its main code or feature of its code. In this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files in network shares and if it is "temp.dat", it will try to read from some stream pipe or file start encrypting files within the infected local machines. This technique can be also identified as an anti-sandbox technique to make its code non-responsive since it is waiting for some parameter to execute properly. +description = The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytics are designed to identifies some CLOP ransomware variant that using arguments to execute its main code or feature of its code. In this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files in network shares and if it is "temp.dat", it will try to read from some stream pipe or file start encrypting files within the infected local machines. This technique can be also identified as an anti-sandbox technique to make its code non-responsive since it is waiting for some parameter to execute properly. +action.escu.eli5 = The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Operators can execute third party tools using these parameters. -action.escu.creation_date = 2023-03-17 -action.escu.modification_date = 2023-03-17 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - Clop Common Exec Parameter - Rule action.escu.search_type = detection @@ -20541,11 +20475,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Clop Common Exec Parameter - Rule action.correlationsearch.annotations = {"analytic_story": ["Clop Ransomware"], "cis20": ["CIS 10"], "confidence": 100, "impact": 100, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5a8a2a72-8322-11eb-9ee9-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5a8a2a72-8322-11eb-9ee9-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytics are designed to identifies some CLOP ransomware variant that using arguments to execute its main code or feature of its code. In this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files in network shares and if it is "temp.dat", it will try to read from some stream pipe or file start encrypting files within the infected local machines. This technique can be also identified as an anti-sandbox technique to make its code non-responsive since it is waiting for some parameter to execute properly. +action.notable.param.rule_description = The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response. action.notable.param.rule_title = Clop Common Exec Parameter action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20563,14 +20497,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Clop Ransomware Known Service Name - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection is to identify the common service name created by the CLOP ransomware as part of its persistence and high privilege code execution in the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API in creating this service entry. +description = The following analytic identifies the creation of a service with a known name used by CLOP ransomware for persistence and high-privilege code execution. It detects this activity by monitoring Windows Event Logs (EventCode 7045) for specific service names ("SecurityCenterIBM", "WinCheckDRVs"). This activity is significant because the creation of such services is a common tactic used by ransomware to maintain control over infected systems. If confirmed malicious, this could allow attackers to execute code with elevated privileges, maintain persistence, and potentially disrupt or encrypt critical data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This detection is to identify the common service name created by the CLOP ransomware as part of its persistence and high privilege code execution in the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API in creating this service entry. +action.escu.eli5 = The following analytic identifies the creation of a service with a known name used by CLOP ransomware for persistence and high-privilege code execution. It detects this activity by monitoring Windows Event Logs (EventCode 7045) for specific service names ("SecurityCenterIBM", "WinCheckDRVs"). This activity is significant because the creation of such services is a common tactic used by ransomware to maintain control over infected systems. If confirmed malicious, this could allow attackers to execute code with elevated privileges, maintain persistence, and potentially disrupt or encrypt critical data. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Clop Ransomware Known Service Name - Rule action.escu.search_type = detection @@ -20588,11 +20522,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Clop Ransomware Known Service Name - Rule action.correlationsearch.annotations = {"analytic_story": ["Clop Ransomware"], "cis20": ["CIS 10"], "confidence": 100, "impact": 100, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07e08a12-870c-11eb-b5f9-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07e08a12-870c-11eb-b5f9-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This detection is to identify the common service name created by the CLOP ransomware as part of its persistence and high privilege code execution in the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API in creating this service entry. +action.notable.param.rule_description = The following analytic identifies the creation of a service with a known name used by CLOP ransomware for persistence and high-privilege code execution. It detects this activity by monitoring Windows Event Logs (EventCode 7045) for specific service names ("SecurityCenterIBM", "WinCheckDRVs"). This activity is significant because the creation of such services is a common tactic used by ransomware to maintain control over infected systems. If confirmed malicious, this could allow attackers to execute code with elevated privileges, maintain persistence, and potentially disrupt or encrypt critical data. action.notable.param.rule_title = Clop Ransomware Known Service Name action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20610,14 +20544,14 @@ search = `wineventlog_system` EventCode=7045 ServiceName IN ("SecurityCenterIBM" [ESCU - CMD Carry Out String Command Parameter - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies command-line arguments where `cmd.exe /c` is used to execute a program. `cmd /c` is used to run commands in MS-DOS and terminate after command or process completion. This technique is commonly seen in adversaries and malware to execute batch command using different shell like PowerShell or different process other than `cmd.exe`. This is a good hunting query for suspicious command-line made by a script or relative process execute it. +description = The following analytic detects the use of `cmd.exe /c` to execute commands, a technique often employed by adversaries and malware to run batch commands or invoke other shells like PowerShell. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. Monitoring this activity is crucial as it can indicate script-based attacks or unauthorized command execution. If confirmed malicious, this behavior could lead to unauthorized code execution, privilege escalation, or persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies command-line arguments where `cmd.exe /c` is used to execute a program. `cmd /c` is used to run commands in MS-DOS and terminate after command or process completion. This technique is commonly seen in adversaries and malware to execute batch command using different shell like PowerShell or different process other than `cmd.exe`. This is a good hunting query for suspicious command-line made by a script or relative process execute it. +action.escu.eli5 = The following analytic detects the use of `cmd.exe /c` to execute commands, a technique often employed by adversaries and malware to run batch commands or invoke other shells like PowerShell. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process metadata. Monitoring this activity is crucial as it can indicate script-based attacks or unauthorized command execution. If confirmed malicious, this behavior could lead to unauthorized code execution, privilege escalation, or persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives may be high based on legitimate scripted code in any environment. Filter as needed. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - CMD Carry Out String Command Parameter - Rule action.escu.search_type = detection @@ -20630,7 +20564,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CMD Carry Out String Command Parameter - Rule action.correlationsearch.annotations = {"analytic_story": ["AsyncRAT", "Azorult", "CISA AA23-347A", "Chaos Ransomware", "DarkCrystal RAT", "DarkGate Malware", "Data Destruction", "Hermetic Wiper", "IcedID", "Living Off The Land", "Log4Shell CVE-2021-44228", "NjRAT", "PlugX", "ProxyNotShell", "Qakbot", "RedLine Stealer", "Rhysida Ransomware", "Warzone RAT", "WhisperGate", "Winter Vivern"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2021-44228"], "impact": 60, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "54a6ed00-3256-11ec-b031-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "54a6ed00-3256-11ec-b031-acde48001122", "detection_version": "5"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -20646,14 +20580,14 @@ search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_ [ESCU - CMD Echo Pipe - Escalation - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies a common behavior by Cobalt Strike and other frameworks where the adversary will escalate privileges, either via `jump` (Cobalt Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. +description = The following analytic identifies the use of named-pipe impersonation for privilege escalation, commonly associated with Cobalt Strike and similar frameworks. It detects command-line executions where `cmd.exe` uses `echo` to write to a named pipe, such as `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant as it indicates potential privilege escalation attempts. If confirmed malicious, attackers could gain elevated privileges, enabling further compromise and persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059", "T1059.003", "T1543.003", "T1543"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies a common behavior by Cobalt Strike and other frameworks where the adversary will escalate privileges, either via `jump` (Cobalt Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. +action.escu.eli5 = The following analytic identifies the use of named-pipe impersonation for privilege escalation, commonly associated with Cobalt Strike and similar frameworks. It detects command-line executions where `cmd.exe` uses `echo` to write to a named pipe, such as `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant as it indicates potential privilege escalation attempts. If confirmed malicious, attackers could gain elevated privileges, enabling further compromise and persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Unknown. It is possible filtering may be required to ensure fidelity. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - CMD Echo Pipe - Escalation - Rule action.escu.search_type = detection @@ -20671,11 +20605,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CMD Echo Pipe - Escalation - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Cobalt Strike", "Graceful Wipe Out Attack"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1059", "T1059.003", "T1543.003", "T1543"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eb277ba0-b96b-11eb-b00e-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "eb277ba0-b96b-11eb-b00e-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies a common behavior by Cobalt Strike and other frameworks where the adversary will escalate privileges, either via `jump` (Cobalt Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. +action.notable.param.rule_description = The following analytic identifies the use of named-pipe impersonation for privilege escalation, commonly associated with Cobalt Strike and similar frameworks. It detects command-line executions where `cmd.exe` uses `echo` to write to a named pipe, such as `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line telemetry. This activity is significant as it indicates potential privilege escalation attempts. If confirmed malicious, attackers could gain elevated privileges, enabling further compromise and persistence within the environment. action.notable.param.rule_title = CMD Echo Pipe - Escalation action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20693,14 +20627,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Cmdline Tool Not Executed In CMD Shell - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a non-standard parent process (not matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also typically seen when an adversary is injected into another process performing different discovery techniques. This event stands out as a TTP since these tools are commonly executed with a shell application or Explorer parent, and not by another application. This TTP is a good indicator for an adversary gathering host information, but one possible false positive might be an automated tool used by a system administator. +description = The following analytic identifies instances where `ipconfig.exe`, `systeminfo.exe`, or similar tools are executed by a non-standard parent process, excluding CMD, PowerShell, or Explorer. This detection leverages Endpoint Detection and Response (EDR) telemetry to monitor process creation events. Such behavior is significant as it may indicate adversaries using injected processes to perform system discovery, a tactic observed in FIN7's JSSLoader. If confirmed malicious, this activity could allow attackers to gather critical host information, aiding in further exploitation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies a non-standard parent process (not matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also typically seen when an adversary is injected into another process performing different discovery techniques. This event stands out as a TTP since these tools are commonly executed with a shell application or Explorer parent, and not by another application. This TTP is a good indicator for an adversary gathering host information, but one possible false positive might be an automated tool used by a system administator. +action.escu.eli5 = The following analytic identifies instances where `ipconfig.exe`, `systeminfo.exe`, or similar tools are executed by a non-standard parent process, excluding CMD, PowerShell, or Explorer. This detection leverages Endpoint Detection and Response (EDR) telemetry to monitor process creation events. Such behavior is significant as it may indicate adversaries using injected processes to perform system discovery, a tactic observed in FIN7's JSSLoader. If confirmed malicious, this activity could allow attackers to gather critical host information, aiding in further exploitation or lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = A network operator or systems administrator may utilize an automated host discovery application that may generate false positives. Filter as needed. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Cmdline Tool Not Executed In CMD Shell - Rule action.escu.search_type = detection @@ -20718,11 +20652,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Cmdline Tool Not Executed In CMD Shell - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-277A", "CISA AA23-347A", "DarkGate Malware", "FIN7", "Qakbot", "Rhysida Ransomware", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6c3f7dd8-153c-11ec-ac2d-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6c3f7dd8-153c-11ec-ac2d-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies a non-standard parent process (not matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also typically seen when an adversary is injected into another process performing different discovery techniques. This event stands out as a TTP since these tools are commonly executed with a shell application or Explorer parent, and not by another application. This TTP is a good indicator for an adversary gathering host information, but one possible false positive might be an automated tool used by a system administator. +action.notable.param.rule_description = The following analytic identifies instances where `ipconfig.exe`, `systeminfo.exe`, or similar tools are executed by a non-standard parent process, excluding CMD, PowerShell, or Explorer. This detection leverages Endpoint Detection and Response (EDR) telemetry to monitor process creation events. Such behavior is significant as it may indicate adversaries using injected processes to perform system discovery, a tactic observed in FIN7's JSSLoader. If confirmed malicious, this activity could allow attackers to gather critical host information, aiding in further exploitation or lateral movement within the network. action.notable.param.rule_title = Cmdline Tool Not Executed In CMD Shell action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20787,16 +20721,14 @@ search = `sysmon` EventCode=7 ImageLoaded IN ("*\\CMLUA.dll", "*\\CMSTPLUA.dll" [ESCU - Cobalt Strike Named Pipes - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of default or publicly known named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. Cobalt Strike uses named pipes in many ways and has default values used with the Artifact Kit and Malleable C2 Profiles. The following query assists with identifying these default named pipes. Each EDR product presents named pipes a little different. Consider taking the values and generating a query based on the product of choice. \ -Upon triage, review the process performing the named pipe. If it is explorer.exe, It is possible it was injected into by another process. Review recent parallel processes to identify suspicious patterns or behaviors. A parallel process may have a network connection, review and follow the connection back to identify any file modifications. +description = The following analytic detects the use of default or publicly known named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 to identify specific named pipes commonly used by Cobalt Strike's Artifact Kit and Malleable C2 Profiles. This activity is significant because Cobalt Strike is a popular tool for adversaries to conduct post-exploitation tasks, and identifying its named pipes can reveal potential malicious activity. If confirmed malicious, this could indicate an active Cobalt Strike beacon, leading to unauthorized access, data exfiltration, or further lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the use of default or publicly known named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. Cobalt Strike uses named pipes in many ways and has default values used with the Artifact Kit and Malleable C2 Profiles. The following query assists with identifying these default named pipes. Each EDR product presents named pipes a little different. Consider taking the values and generating a query based on the product of choice. \ -Upon triage, review the process performing the named pipe. If it is explorer.exe, It is possible it was injected into by another process. Review recent parallel processes to identify suspicious patterns or behaviors. A parallel process may have a network connection, review and follow the connection back to identify any file modifications. +action.escu.eli5 = The following analytic detects the use of default or publicly known named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 to identify specific named pipes commonly used by Cobalt Strike's Artifact Kit and Malleable C2 Profiles. This activity is significant because Cobalt Strike is a popular tool for adversaries to conduct post-exploitation tasks, and identifying its named pipes can reveal potential malicious activity. If confirmed malicious, this could indicate an active Cobalt Strike beacon, leading to unauthorized access, data exfiltration, or further lateral movement within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = The idea of using named pipes with Cobalt Strike is to blend in. Therefore, some of the named pipes identified and added may cause false positives. Filter by process name or pipe name to reduce false positives. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Cobalt Strike Named Pipes - Rule action.escu.search_type = detection @@ -20814,12 +20746,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Cobalt Strike Named Pipes - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Cobalt Strike", "DarkSide Ransomware", "Graceful Wipe Out Attack", "LockBit Ransomware", "Trickbot"], "cis20": ["CIS 10"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5876d429-0240-4709-8b93-ea8330b411b5", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5876d429-0240-4709-8b93-ea8330b411b5", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of default or publicly known named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. Cobalt Strike uses named pipes in many ways and has default values used with the Artifact Kit and Malleable C2 Profiles. The following query assists with identifying these default named pipes. Each EDR product presents named pipes a little different. Consider taking the values and generating a query based on the product of choice. \ -Upon triage, review the process performing the named pipe. If it is explorer.exe, It is possible it was injected into by another process. Review recent parallel processes to identify suspicious patterns or behaviors. A parallel process may have a network connection, review and follow the connection back to identify any file modifications. +action.notable.param.rule_description = The following analytic detects the use of default or publicly known named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 to identify specific named pipes commonly used by Cobalt Strike's Artifact Kit and Malleable C2 Profiles. This activity is significant because Cobalt Strike is a popular tool for adversaries to conduct post-exploitation tasks, and identifying its named pipes can reveal potential malicious activity. If confirmed malicious, this could indicate an active Cobalt Strike beacon, leading to unauthorized access, data exfiltration, or further lateral movement within the network. action.notable.param.rule_title = Cobalt Strike Named Pipes action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20837,14 +20768,14 @@ search = `sysmon` EventID=17 OR EventID=18 PipeName IN (\\msagent_*, \\DserNameP [ESCU - Common Ransomware Extensions - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack. +description = The following analytic detects modifications to files with extensions commonly associated with ransomware. It leverages the Endpoint.Filesystem data model to identify changes in file extensions that match known ransomware patterns. This activity is significant because it suggests an attacker is attempting to encrypt or alter files, potentially leading to severe data loss and operational disruption. If confirmed malicious, this activity could result in the encryption of critical data, rendering it inaccessible and causing significant damage to the organization's data integrity and availability. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack. +action.escu.eli5 = The following analytic detects modifications to files with extensions commonly associated with ransomware. It leverages the Endpoint.Filesystem data model to identify changes in file extensions that match known ransomware patterns. This activity is significant because it suggests an attacker is attempting to encrypt or alter files, potentially leading to severe data loss and operational disruption. If confirmed malicious, this activity could result in the encryption of critical data, rendering it inaccessible and causing significant damage to the organization's data integrity and availability. action.escu.how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint Filesystem data model node. To see the additional metadata, add the following fields, if not already present, please review the detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details` action.escu.known_false_positives = It is possible for a legitimate file with these extensions to be created. If this is a true ransomware attack, there will be a large number of files created with these extensions. -action.escu.creation_date = 2022-11-10 -action.escu.modification_date = 2022-11-10 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Common Ransomware Extensions - Rule action.escu.search_type = detection @@ -20857,7 +20788,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Common Ransomware Extensions - Rule action.correlationsearch.annotations = {"analytic_story": ["Clop Ransomware", "LockBit Ransomware", "Prestige Ransomware", "Ransomware", "Rhysida Ransomware", "Ryuk Ransomware", "SamSam Ransomware"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9e5c5db-db11-43ca-86a8-c852d1b2c0ec", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a9e5c5db-db11-43ca-86a8-c852d1b2c0ec", "detection_version": "6"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -20909,14 +20840,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - ConnectWise ScreenConnect Path Traversal - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +description = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows path traversal attacks by manipulating file_path and file_name parameters in the URL. It leverages the Endpoint datamodel Filesystem node to identify suspicious file system events, specifically targeting paths and filenames associated with ScreenConnect. This activity is significant as it can lead to unauthorized access to sensitive files and directories, potentially resulting in data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access and control over the host system, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +action.escu.eli5 = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows path traversal attacks by manipulating file_path and file_name parameters in the URL. It leverages the Endpoint datamodel Filesystem node to identify suspicious file system events, specifically targeting paths and filenames associated with ScreenConnect. This activity is significant as it can lead to unauthorized access to sensitive files and directories, potentially resulting in data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access and control over the host system, posing a severe security risk. action.escu.how_to_implement = This analytic utilizes the Endpoint datamodel Filesystem node to identify path traversal attempts against ScreenConnect. Note that using SACL auditing or other file system monitoring tools may also be used to detect path traversal attempts. Typically the data for this analytic will come from EDR or other properly CIM mapped data sources. action.escu.known_false_positives = False positives are not expected, as the detection is based on the presence of file system events that indicate path traversal attempts. The analytic may be modified to look for any file writes to this path as it is not common for files to write here. -action.escu.creation_date = 2024-02-21 -action.escu.modification_date = 2024-02-21 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - ConnectWise ScreenConnect Path Traversal - Rule action.escu.search_type = detection @@ -20934,11 +20865,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ConnectWise ScreenConnect Path Traversal - Rule action.correlationsearch.annotations = {"analytic_story": ["ConnectWise ScreenConnect Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2024-1708", "CVE-2024-1709"], "impact": 100, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "56a3ac65-e747-41f7-b014-dff7423c1dda", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "56a3ac65-e747-41f7-b014-dff7423c1dda", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +action.notable.param.rule_description = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows path traversal attacks by manipulating file_path and file_name parameters in the URL. It leverages the Endpoint datamodel Filesystem node to identify suspicious file system events, specifically targeting paths and filenames associated with ScreenConnect. This activity is significant as it can lead to unauthorized access to sensitive files and directories, potentially resulting in data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access and control over the host system, posing a severe security risk. action.notable.param.rule_title = ConnectWise ScreenConnect Path Traversal action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -20956,14 +20887,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - ConnectWise ScreenConnect Path Traversal Windows SACL - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +description = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability using Windows SACL EventCode 4663. It identifies path traversal attacks by monitoring file system events related to the ScreenConnect service. This activity is significant as it allows unauthorized access to sensitive files and directories, potentially leading to data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access to critical data or execute harmful code, compromising the integrity and security of the affected system. Immediate remediation by updating to version 23.9.8 or above is recommended. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +action.escu.eli5 = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability using Windows SACL EventCode 4663. It identifies path traversal attacks by monitoring file system events related to the ScreenConnect service. This activity is significant as it allows unauthorized access to sensitive files and directories, potentially leading to data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access to critical data or execute harmful code, compromising the integrity and security of the affected system. Immediate remediation by updating to version 23.9.8 or above is recommended. action.escu.how_to_implement = To implement the following query, enable SACL auditing for the ScreenConnect directory(ies). With this data, the following analytic will work correctly. A GIST is provided in the references to assist with enabling SACL Auditing. action.escu.known_false_positives = False positives should be limited as the analytic is specific to ScreenConnect path traversal attempts. Tune as needed, or restrict to specific hosts if false positives are encountered. -action.escu.creation_date = 2024-02-21 -action.escu.modification_date = 2024-02-21 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - ConnectWise ScreenConnect Path Traversal Windows SACL - Rule action.escu.search_type = detection @@ -20981,11 +20912,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - ConnectWise ScreenConnect Path Traversal Windows SACL - Rule action.correlationsearch.annotations = {"analytic_story": ["ConnectWise ScreenConnect Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2024-1708", "CVE-2024-1709"], "impact": 100, "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4e127857-1fc9-4c95-9d69-ba24c91d52d7", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4e127857-1fc9-4c95-9d69-ba24c91d52d7", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. +action.notable.param.rule_description = The following analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability using Windows SACL EventCode 4663. It identifies path traversal attacks by monitoring file system events related to the ScreenConnect service. This activity is significant as it allows unauthorized access to sensitive files and directories, potentially leading to data exfiltration or arbitrary code execution. If confirmed malicious, attackers could gain unauthorized access to critical data or execute harmful code, compromising the integrity and security of the affected system. Immediate remediation by updating to version 23.9.8 or above is recommended. action.notable.param.rule_title = ConnectWise ScreenConnect Path Traversal Windows SACL action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21050,14 +20981,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Control Loading from World Writable Directory - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies control.exe loading either a .cpl or .inf from a writable directory. This is related to CVE-2021-40444. During triage, review parallel processes, parent and child, for further suspicious behaviors. In addition, capture file modifications and analyze. +description = The following analytic identifies instances of control.exe loading a .cpl or .inf file from a writable directory, which is related to CVE-2021-40444. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it may indicate an attempt to exploit a known vulnerability, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to gain control over the affected system, leading to further compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following detection identifies control.exe loading either a .cpl or .inf from a writable directory. This is related to CVE-2021-40444. During triage, review parallel processes, parent and child, for further suspicious behaviors. In addition, capture file modifications and analyze. +action.escu.eli5 = The following analytic identifies instances of control.exe loading a .cpl or .inf file from a writable directory, which is related to CVE-2021-40444. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it may indicate an attempt to exploit a known vulnerability, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to gain control over the affected system, leading to further compromise. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives will be present as control.exe does not natively load from writable paths as defined. One may add .cpl or .inf to the command-line if there is any false positives. Tune as needed. -action.escu.creation_date = 2021-09-08 -action.escu.modification_date = 2021-09-08 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Control Loading from World Writable Directory - Rule action.escu.search_type = detection @@ -21075,11 +21006,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Control Loading from World Writable Directory - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Microsoft MSHTML Remote Code Execution CVE-2021-40444"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2021-40444"], "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10423ac4-10c9-11ec-8dc4-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10423ac4-10c9-11ec-8dc4-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following detection identifies control.exe loading either a .cpl or .inf from a writable directory. This is related to CVE-2021-40444. During triage, review parallel processes, parent and child, for further suspicious behaviors. In addition, capture file modifications and analyze. +action.notable.param.rule_description = The following analytic identifies instances of control.exe loading a .cpl or .inf file from a writable directory, which is related to CVE-2021-40444. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions mapped to the `Processes` node of the `Endpoint` data model. This activity is significant as it may indicate an attempt to exploit a known vulnerability, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to gain control over the affected system, leading to further compromise. action.notable.param.rule_title = Control Loading from World Writable Directory action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21097,14 +21028,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Create local admin accounts using net exe - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack. +description = The following analytic detects the creation of local administrator accounts using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes named net.exe or net1.exe with the "/add" parameter and keywords related to administrator accounts. This activity is significant as it may indicate an attacker attempting to gain persistent access or escalate privileges. If confirmed malicious, this could lead to unauthorized access, data theft, or further system compromise. Review the process details, user context, and related artifacts to determine the legitimacy of the activity. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack. +action.escu.eli5 = The following analytic detects the creation of local administrator accounts using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes named net.exe or net1.exe with the "/add" parameter and keywords related to administrator accounts. This activity is significant as it may indicate an attacker attempting to gain persistent access or escalate privileges. If confirmed malicious, this could lead to unauthorized access, data theft, or further system compromise. Review the process details, user context, and related artifacts to determine the legitimacy of the activity. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators often leverage net.exe to create admin accounts. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Create local admin accounts using net exe - Rule action.escu.search_type = detection @@ -21122,11 +21053,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Create local admin accounts using net exe - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "CISA AA22-257A", "DHS Report TA18-074A", "DarkGate Malware"], "cis20": ["CIS 10"], "confidence": 60, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b89919ed-fe5f-492c-b139-151bb162040e", "detection_version": "9"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b89919ed-fe5f-492c-b139-151bb162040e", "detection_version": "10"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack. +action.notable.param.rule_description = The following analytic detects the creation of local administrator accounts using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes named net.exe or net1.exe with the "/add" parameter and keywords related to administrator accounts. This activity is significant as it may indicate an attacker attempting to gain persistent access or escalate privileges. If confirmed malicious, this could lead to unauthorized access, data theft, or further system compromise. Review the process details, user context, and related artifacts to determine the legitimacy of the activity. action.notable.param.rule_title = Create local admin accounts using net exe action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21144,14 +21075,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.user) [ESCU - Create or delete windows shares using net exe - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. +description = The following analytic detects the creation or deletion of Windows shares using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes involving net.exe with actions related to share management. This activity is significant because it may indicate an attacker attempting to manipulate network shares for malicious purposes, such as data exfiltration, malware distribution, or establishing persistence. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, service disruption, or malware introduction. Immediate investigation is required to determine the intent and mitigate potential threats. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. +action.escu.eli5 = The following analytic detects the creation or deletion of Windows shares using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes involving net.exe with actions related to share management. This activity is significant because it may indicate an attacker attempting to manipulate network shares for malicious purposes, such as data exfiltration, malware distribution, or establishing persistence. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, service disruption, or malware introduction. Immediate investigation is required to determine the intent and mitigate potential threats. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators often leverage net.exe to create or delete network shares. You should verify that the activity was intentional and is legitimate. -action.escu.creation_date = 2020-09-16 -action.escu.modification_date = 2020-09-16 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Create or delete windows shares using net exe - Rule action.escu.search_type = detection @@ -21169,11 +21100,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Create or delete windows shares using net exe - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-277A", "DarkGate Malware", "Hidden Cobra Malware", "Prestige Ransomware", "Windows Post-Exploitation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "743a322c-9a68-4a0f-9c17-85d9cce2a27c", "detection_version": "6"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "743a322c-9a68-4a0f-9c17-85d9cce2a27c", "detection_version": "7"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack. +action.notable.param.rule_description = The following analytic detects the creation or deletion of Windows shares using the net.exe command. It leverages Endpoint Detection and Response (EDR) data to identify processes involving net.exe with actions related to share management. This activity is significant because it may indicate an attacker attempting to manipulate network shares for malicious purposes, such as data exfiltration, malware distribution, or establishing persistence. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, service disruption, or malware introduction. Immediate investigation is required to determine the intent and mitigate potential threats. action.notable.param.rule_title = Create or delete windows shares using net exe action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21186,19 +21117,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count values(Processes.user) as user values(Processes.parent_process) as parent_process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_net` by Processes.process Processes.process_name Processes.parent_process_name Processes.original_file_name Processes.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | search process=*share* | `create_or_delete_windows_shares_using_net_exe_filter` +search = | tstats `security_content_summariesonly` count values(Processes.user) as user values(Processes.parent_process) as parent_process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_net` by Processes.process Processes.process_name Processes.parent_process_name Processes.original_file_name Processes.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | search process=*share* | `create_or_delete_windows_shares_using_net_exe_filter` [ESCU - Create Remote Thread In Shell Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect suspicious process injection in command shell. This technique was seen in IcedID where it execute cmd.exe process to inject its shellcode as part of its execution as banking trojan. It is really uncommon to have a create remote thread execution in the following application. +description = The following analytic detects suspicious process injection in command shell applications, specifically targeting `cmd.exe` and `powershell.exe`. It leverages Sysmon EventCode 8 to identify the creation of remote threads within these shell processes. This activity is significant because it is a common technique used by malware, such as IcedID, to inject malicious code and execute it within legitimate processes. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect suspicious process injection in command shell. This technique was seen in IcedID where it execute cmd.exe process to inject its shellcode as part of its execution as banking trojan. It is really uncommon to have a create remote thread execution in the following application. +action.escu.eli5 = The following analytic detects suspicious process injection in command shell applications, specifically targeting `cmd.exe` and `powershell.exe`. It leverages Sysmon EventCode 8 to identify the creation of remote threads within these shell processes. This activity is significant because it is a common technique used by malware, such as IcedID, to inject malicious code and execute it within legitimate processes. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-01-31 -action.escu.modification_date = 2024-01-31 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Create Remote Thread In Shell Application - Rule action.escu.search_type = detection @@ -21216,11 +21147,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Create Remote Thread In Shell Application - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Qakbot", "Warzone RAT"], "cis20": ["CIS 10"], "confidence": 100, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10399c1e-f51e-11eb-b920-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10399c1e-f51e-11eb-b920-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect suspicious process injection in command shell. This technique was seen in IcedID where it execute cmd.exe process to inject its shellcode as part of its execution as banking trojan. It is really uncommon to have a create remote thread execution in the following application. +action.notable.param.rule_description = The following analytic detects suspicious process injection in command shell applications, specifically targeting `cmd.exe` and `powershell.exe`. It leverages Sysmon EventCode 8 to identify the creation of remote threads within these shell processes. This activity is significant because it is a common technique used by malware, such as IcedID, to inject malicious code and execute it within legitimate processes. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security. action.notable.param.rule_title = Create Remote Thread In Shell Application action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21238,14 +21169,14 @@ search = `sysmon` EventCode=8 TargetImage IN ("*\\cmd.exe", "*\\powershell*") | [ESCU - Create Remote Thread into LSASS - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon EventID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats. +description = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS). This behavior is identified using Sysmon Event ID 8 logs, focusing on processes that create remote threads in lsass.exe. This activity is significant because it is commonly associated with credential dumping, a tactic used by adversaries to steal user authentication credentials. If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information, leading to potential compromise of the entire network. Analysts should investigate to differentiate between legitimate tools and potential threats. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon EventID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats. +action.escu.eli5 = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS). This behavior is identified using Sysmon Event ID 8 logs, focusing on processes that create remote threads in lsass.exe. This activity is significant because it is commonly associated with credential dumping, a tactic used by adversaries to steal user authentication credentials. If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information, leading to potential compromise of the entire network. Analysts should investigate to differentiate between legitimate tools and potential threats. action.escu.how_to_implement = This search needs Sysmon Logs with a Sysmon configuration, which includes EventCode 8 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. action.escu.known_false_positives = Other tools can access LSASS for legitimate reasons and generate an event. In these cases, tweaking the search may help eliminate noise. -action.escu.creation_date = 2019-12-06 -action.escu.modification_date = 2019-12-06 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Create Remote Thread into LSASS - Rule action.escu.search_type = detection @@ -21263,11 +21194,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Create Remote Thread into LSASS - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "67d4dbef-9564-4699-8da8-03a151529edc", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "67d4dbef-9564-4699-8da8-03a151529edc", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon EventID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats. +action.notable.param.rule_description = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS). This behavior is identified using Sysmon Event ID 8 logs, focusing on processes that create remote threads in lsass.exe. This activity is significant because it is commonly associated with credential dumping, a tactic used by adversaries to steal user authentication credentials. If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information, leading to potential compromise of the entire network. Analysts should investigate to differentiate between legitimate tools and potential threats. action.notable.param.rule_title = Create Remote Thread into LSASS action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21285,14 +21216,14 @@ search = `sysmon` EventID=8 TargetImage=*lsass.exe | stats count min(_time) as f [ESCU - Creation of lsass Dump with Taskmgr - Rule] action.escu = 0 action.escu.enabled = 1 -description = Detect the hands on keyboard behavior of Windows Task Manager creating a process dump of lsass.exe. Upon this behavior occurring, a file write/modification will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, cannot be renamed, however if the dump occurs more than once, it will be named lsass (2).dmp. +description = The following analytic detects the creation of an lsass.exe process dump using Windows Task Manager. It leverages Sysmon EventID 11 to identify file creation events where the target filename matches *lsass*.dmp. This activity is significant because creating an lsass dump can be a precursor to credential theft, as the dump file contains sensitive information such as user passwords. If confirmed malicious, an attacker could use the lsass dump to extract credentials and escalate privileges, potentially compromising the entire network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = Detect the hands on keyboard behavior of Windows Task Manager creating a process dump of lsass.exe. Upon this behavior occurring, a file write/modification will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, cannot be renamed, however if the dump occurs more than once, it will be named lsass (2).dmp. +action.escu.eli5 = The following analytic detects the creation of an lsass.exe process dump using Windows Task Manager. It leverages Sysmon EventID 11 to identify file creation events where the target filename matches *lsass*.dmp. This activity is significant because creating an lsass dump can be a precursor to credential theft, as the dump file contains sensitive information such as user passwords. If confirmed malicious, an attacker could use the lsass dump to extract credentials and escalate privileges, potentially compromising the entire network. action.escu.how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 11 for detecting file create of lsass.dmp. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. action.escu.known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual. -action.escu.creation_date = 2020-02-03 -action.escu.modification_date = 2020-02-03 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Creation of lsass Dump with Taskmgr - Rule action.escu.search_type = detection @@ -21310,11 +21241,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Creation of lsass Dump with Taskmgr - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-257A", "Credential Dumping"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b2fbe95a-9c62-4c12-8a29-24b97e84c0cd", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b2fbe95a-9c62-4c12-8a29-24b97e84c0cd", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Detect the hands on keyboard behavior of Windows Task Manager creating a process dump of lsass.exe. Upon this behavior occurring, a file write/modification will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, cannot be renamed, however if the dump occurs more than once, it will be named lsass (2).dmp. +action.notable.param.rule_description = The following analytic detects the creation of an lsass.exe process dump using Windows Task Manager. It leverages Sysmon EventID 11 to identify file creation events where the target filename matches *lsass*.dmp. This activity is significant because creating an lsass dump can be a precursor to credential theft, as the dump file contains sensitive information such as user passwords. If confirmed malicious, an attacker could use the lsass dump to extract credentials and escalate privileges, potentially compromising the entire network. action.notable.param.rule_title = Creation of lsass Dump with Taskmgr action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21379,14 +21310,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Creation of Shadow Copy with wmic and powershell - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack. +description = The following analytic detects the creation of shadow copies using "wmic" or "Powershell" commands. It leverages the Endpoint.Processes data model in Splunk to identify processes where the command includes "shadowcopy" and "create". This activity is significant because it may indicate an attacker attempting to manipulate or access data unauthorizedly, potentially leading to data theft or manipulation. If confirmed malicious, this behavior could allow attackers to backup and exfiltrate sensitive data or hide their tracks by restoring files to a previous state after an attack. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack. +action.escu.eli5 = The following analytic detects the creation of shadow copies using "wmic" or "Powershell" commands. It leverages the Endpoint.Processes data model in Splunk to identify processes where the command includes "shadowcopy" and "create". This activity is significant because it may indicate an attacker attempting to manipulate or access data unauthorizedly, potentially leading to data theft or manipulation. If confirmed malicious, this behavior could allow attackers to backup and exfiltrate sensitive data or hide their tracks by restoring files to a previous state after an attack. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Legtimate administrator usage of wmic to create a shadow copy. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-18 +action.escu.modification_date = 2024-05-18 action.escu.confidence = high action.escu.full_search_name = ESCU - Creation of Shadow Copy with wmic and powershell - Rule action.escu.search_type = detection @@ -21404,11 +21335,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Creation of Shadow Copy with wmic and powershell - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping", "Living Off The Land", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2ed8b538-d284-449a-be1d-82ad1dbd186b", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2ed8b538-d284-449a-be1d-82ad1dbd186b", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack. +action.notable.param.rule_description = The following analytic detects the creation of shadow copies using "wmic" or "Powershell" commands. It leverages the Endpoint.Processes data model in Splunk to identify processes where the command includes "shadowcopy" and "create". This activity is significant because it may indicate an attacker attempting to manipulate or access data unauthorizedly, potentially leading to data theft or manipulation. If confirmed malicious, this behavior could allow attackers to backup and exfiltrate sensitive data or hide their tracks by restoring files to a previous state after an attack. action.notable.param.rule_title = Creation of Shadow Copy with wmic and powershell action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21426,14 +21357,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Credential Dumping via Copy Command from Shadow Copy - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as "sam", "security", "system", and "ntds.dit", located in system directories like "system32" or "windows". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack +description = The following analytic detects the use of the copy command to dump credentials from a shadow copy. It leverages Endpoint Detection and Response (EDR) data to identify processes with command lines referencing critical files like "sam", "security", "system", and "ntds.dit" in system directories. This activity is significant as it indicates an attempt to extract credentials, a common technique for unauthorized access and privilege escalation. If confirmed malicious, this could lead to attackers gaining sensitive login information, escalating privileges, moving laterally within the network, or accessing sensitive data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as "sam", "security", "system", and "ntds.dit", located in system directories like "system32" or "windows". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack +action.escu.eli5 = The following analytic detects the use of the copy command to dump credentials from a shadow copy. It leverages Endpoint Detection and Response (EDR) data to identify processes with command lines referencing critical files like "sam", "security", "system", and "ntds.dit" in system directories. This activity is significant as it indicates an attempt to extract credentials, a common technique for unauthorized access and privilege escalation. If confirmed malicious, this could lead to attackers gaining sensitive login information, escalating privileges, moving laterally within the network, or accessing sensitive data. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-30 +action.escu.modification_date = 2024-05-30 action.escu.confidence = high action.escu.full_search_name = ESCU - Credential Dumping via Copy Command from Shadow Copy - Rule action.escu.search_type = detection @@ -21451,11 +21382,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Credential Dumping via Copy Command from Shadow Copy - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d8c406fe-23d2-45f3-a983-1abe7b83ff3b", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d8c406fe-23d2-45f3-a983-1abe7b83ff3b", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as "sam", "security", "system", and "ntds.dit", located in system directories like "system32" or "windows". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack +action.notable.param.rule_description = The following analytic detects the use of the copy command to dump credentials from a shadow copy. It leverages Endpoint Detection and Response (EDR) data to identify processes with command lines referencing critical files like "sam", "security", "system", and "ntds.dit" in system directories. This activity is significant as it indicates an attempt to extract credentials, a common technique for unauthorized access and privilege escalation. If confirmed malicious, this could lead to attackers gaining sensitive login information, escalating privileges, moving laterally within the network, or accessing sensitive data. action.notable.param.rule_title = Credential Dumping via Copy Command from Shadow Copy action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21468,19 +21399,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_cmd` (Processes.process=*\\system32\\config\\sam* OR Processes.process=*\\system32\\config\\security* OR Processes.process=*\\system32\\config\\system* OR Processes.process=*\\windows\\ntds\\ntds.dit*) by Processes.dest Processes.user Processes.process_name Processes.process Processes.parent_process Processes.original_file_name Processes.process_id Processes.parent_process_id Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `credential_dumping_via_copy_command_from_shadow_copy_filter` +search = | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_cmd` (Processes.process=*\\system32\\config\\sam* OR Processes.process=*\\system32\\config\\security* OR Processes.process=*\\system32\\config\\system* OR Processes.process=*\\windows\\ntds\\ntds.dit*) by Processes.dest Processes.user Processes.process_name Processes.process Processes.parent_process Processes.original_file_name Processes.process_id Processes.parent_process_id Processes.parent_process_name | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `credential_dumping_via_copy_command_from_shadow_copy_filter` [ESCU - Credential Dumping via Symlink to Shadow Copy - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies. The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model. The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack. +description = The following analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. It leverages the Endpoint.Processes data model in Splunk to identify processes executing commands containing "mklink" and "HarddiskVolumeShadowCopy". This activity is significant because attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts. If confirmed malicious, this could prevent data restoration, complicate incident response, and lead to data loss or compromise. Analysts should review the process details, user, parent process, and any related artifacts to identify the attack source. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies. The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model. The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack. +action.escu.eli5 = The following analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. It leverages the Endpoint.Processes data model in Splunk to identify processes executing commands containing "mklink" and "HarddiskVolumeShadowCopy". This activity is significant because attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts. If confirmed malicious, this could prevent data restoration, complicate incident response, and lead to data loss or compromise. Analysts should review the process details, user, parent process, and any related artifacts to identify the attack source. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Credential Dumping via Symlink to Shadow Copy - Rule action.escu.search_type = detection @@ -21498,11 +21429,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Credential Dumping via Symlink to Shadow Copy - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c5eac648-fae0-4263-91a6-773df1f4c903", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c5eac648-fae0-4263-91a6-773df1f4c903", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies. The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model. The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack. +action.notable.param.rule_description = The following analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. It leverages the Endpoint.Processes data model in Splunk to identify processes executing commands containing "mklink" and "HarddiskVolumeShadowCopy". This activity is significant because attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts. If confirmed malicious, this could prevent data restoration, complicate incident response, and lead to data loss or compromise. Analysts should review the process details, user, parent process, and any related artifacts to identify the attack source. action.notable.param.rule_title = Credential Dumping via Symlink to Shadow Copy action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21520,14 +21451,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - CSC Net On The Fly Compilation - Rule] action.escu = 0 action.escu.enabled = 1 -description = this analytic is to detect a suspicious compile before delivery approach of .net compiler csc.exe. This technique was seen in several adversaries, malware and even in red teams to take advantage the csc.exe .net compiler tool to compile on the fly a malicious .net code to evade detection from security product. This is a good hunting query to check further the file or process created after this event and check the file path that passed to csc.exe which is the .net code. Aside from that, powershell is capable of using this compiler in executing .net code in a powershell script so filter on that case is needed. +description = The following analytic detects the use of the .NET compiler csc.exe for on-the-fly compilation of potentially malicious .NET code. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns associated with csc.exe. This activity is significant because adversaries and malware often use this technique to evade detection by compiling malicious code at runtime. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.004", "T1027"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = this analytic is to detect a suspicious compile before delivery approach of .net compiler csc.exe. This technique was seen in several adversaries, malware and even in red teams to take advantage the csc.exe .net compiler tool to compile on the fly a malicious .net code to evade detection from security product. This is a good hunting query to check further the file or process created after this event and check the file path that passed to csc.exe which is the .net code. Aside from that, powershell is capable of using this compiler in executing .net code in a powershell script so filter on that case is needed. +action.escu.eli5 = The following analytic detects the use of the .NET compiler csc.exe for on-the-fly compilation of potentially malicious .NET code. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line patterns associated with csc.exe. This activity is significant because adversaries and malware often use this technique to evade detection by compiling malicious code at runtime. If confirmed malicious, this could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = A network operator or systems administrator may utilize an automated powershell script taht execute .net code that may generate false positive. filter is needed. -action.escu.creation_date = 2021-11-12 -action.escu.modification_date = 2021-11-12 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - CSC Net On The Fly Compilation - Rule action.escu.search_type = detection @@ -21540,7 +21471,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - CSC Net On The Fly Compilation - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Defense Evasion Tactics"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.004", "T1027"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ea73128a-43ab-11ec-9753-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ea73128a-43ab-11ec-9753-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -21556,14 +21487,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Curl Download and Bash Execution - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of curl on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +description = The following analytic detects the use of curl on Linux or MacOS systems to download a file from a remote source and pipe it directly to bash for execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and parent processes. This activity is significant as it is commonly associated with malicious actions such as coinminers and exploitation of vulnerabilities like CVE-2021-44228 in Log4j. If confirmed malicious, this behavior could lead to unauthorized code execution, system compromise, and further exploitation within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the use of curl on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +action.escu.eli5 = The following analytic detects the use of curl on Linux or MacOS systems to download a file from a remote source and pipe it directly to bash for execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and parent processes. This activity is significant as it is commonly associated with malicious actions such as coinminers and exploitation of vulnerabilities like CVE-2021-44228 in Log4j. If confirmed malicious, this behavior could lead to unauthorized code execution, system compromise, and further exploitation within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited, however filtering may be required. -action.escu.creation_date = 2021-12-10 -action.escu.modification_date = 2021-12-10 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Curl Download and Bash Execution - Rule action.escu.search_type = detection @@ -21581,11 +21512,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Curl Download and Bash Execution - Rule action.correlationsearch.annotations = {"analytic_story": ["Ingress Tool Transfer", "Linux Living Off The Land", "Log4Shell CVE-2021-44228"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2021-44228"], "impact": 80, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "900bc324-59f3-11ec-9fb4-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "900bc324-59f3-11ec-9fb4-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of curl on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j. +action.notable.param.rule_description = The following analytic detects the use of curl on Linux or MacOS systems to download a file from a remote source and pipe it directly to bash for execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line arguments, and parent processes. This activity is significant as it is commonly associated with malicious actions such as coinminers and exploitation of vulnerabilities like CVE-2021-44228 in Log4j. If confirmed malicious, this behavior could lead to unauthorized code execution, system compromise, and further exploitation within the environment. action.notable.param.rule_title = Curl Download and Bash Execution action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21603,14 +21534,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Delete ShadowCopy With PowerShell - Rule] action.escu = 0 action.escu.enabled = 1 -description = This following analytic detects PowerShell command to delete shadow copy using the WMIC PowerShell module. This technique was seen used by a recent adversary to deploy DarkSide Ransomware where it executed a child process of PowerShell to execute a hex encoded command to delete shadow copy. This hex encoded command was able to be decrypted by PowerShell log. +description = The following analytic detects the use of PowerShell to delete shadow copies via the WMIC PowerShell module. It leverages EventCode 4104 and searches for specific keywords like "ShadowCopy," "Delete," or "Remove" within the ScriptBlockText. This activity is significant because deleting shadow copies is a common tactic used by ransomware, such as DarkSide, to prevent data recovery. If confirmed malicious, this action could lead to irreversible data loss and hinder recovery efforts, significantly impacting business continuity and data integrity. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This following analytic detects PowerShell command to delete shadow copy using the WMIC PowerShell module. This technique was seen used by a recent adversary to deploy DarkSide Ransomware where it executed a child process of PowerShell to execute a hex encoded command to delete shadow copy. This hex encoded command was able to be decrypted by PowerShell log. +action.escu.eli5 = The following analytic detects the use of PowerShell to delete shadow copies via the WMIC PowerShell module. It leverages EventCode 4104 and searches for specific keywords like "ShadowCopy," "Delete," or "Remove" within the ScriptBlockText. This activity is significant because deleting shadow copies is a common tactic used by ransomware, such as DarkSide, to prevent data recovery. If confirmed malicious, this action could lead to irreversible data loss and hinder recovery efforts, significantly impacting business continuity and data integrity. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs from your endpoints. make sure you enable needed registry to monitor this event. action.escu.known_false_positives = unknown -action.escu.creation_date = 2022-05-02 -action.escu.modification_date = 2022-05-02 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Delete ShadowCopy With PowerShell - Rule action.escu.search_type = detection @@ -21628,11 +21559,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Delete ShadowCopy With PowerShell - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkGate Malware", "DarkSide Ransomware", "Ransomware", "Revil Ransomware"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5ee2bcd0-b2ff-11eb-bb34-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "5ee2bcd0-b2ff-11eb-bb34-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This following analytic detects PowerShell command to delete shadow copy using the WMIC PowerShell module. This technique was seen used by a recent adversary to deploy DarkSide Ransomware where it executed a child process of PowerShell to execute a hex encoded command to delete shadow copy. This hex encoded command was able to be decrypted by PowerShell log. +action.notable.param.rule_description = The following analytic detects the use of PowerShell to delete shadow copies via the WMIC PowerShell module. It leverages EventCode 4104 and searches for specific keywords like "ShadowCopy," "Delete," or "Remove" within the ScriptBlockText. This activity is significant because deleting shadow copies is a common tactic used by ransomware, such as DarkSide, to prevent data recovery. If confirmed malicious, this action could lead to irreversible data loss and hinder recovery efforts, significantly impacting business continuity and data integrity. action.notable.param.rule_title = Delete ShadowCopy With PowerShell action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21650,14 +21581,14 @@ search = `powershell` EventCode=4104 ScriptBlockText= "*ShadowCopy*" (ScriptBloc [ESCU - Deleting Of Net Users - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic will detect a suspicious net.exe/net1.exe command-line to delete a user on a system. This technique may be use by an administrator for legitimate purposes, however this behavior has been used in the wild to impair some user or deleting adversaries tracks created during its lateral movement additional systems. During triage, review parallel processes for additional behavior. Identify any other user accounts created before or after. +description = The following analytic detects the use of net.exe or net1.exe command-line to delete a user account on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. This activity is significant as it may indicate an attempt to impair user accounts or cover tracks during lateral movement. If confirmed malicious, this could lead to unauthorized access removal, disruption of legitimate user activities, or concealment of adversarial actions, complicating incident response and forensic investigations. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic will detect a suspicious net.exe/net1.exe command-line to delete a user on a system. This technique may be use by an administrator for legitimate purposes, however this behavior has been used in the wild to impair some user or deleting adversaries tracks created during its lateral movement additional systems. During triage, review parallel processes for additional behavior. Identify any other user accounts created before or after. +action.escu.eli5 = The following analytic detects the use of net.exe or net1.exe command-line to delete a user account on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. This activity is significant as it may indicate an attempt to impair user accounts or cover tracks during lateral movement. If confirmed malicious, this could lead to unauthorized access removal, disruption of legitimate user activities, or concealment of adversarial actions, complicating incident response and forensic investigations. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = System administrators or scripts may delete user accounts via this technique. Filter as needed. -action.escu.creation_date = 2023-06-13 -action.escu.modification_date = 2023-06-13 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Deleting Of Net Users - Rule action.escu.search_type = detection @@ -21675,11 +21606,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Deleting Of Net Users - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkGate Malware", "Graceful Wipe Out Attack", "XMRig"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c8c6f66-acce-11eb-aafb-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c8c6f66-acce-11eb-aafb-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic will detect a suspicious net.exe/net1.exe command-line to delete a user on a system. This technique may be use by an administrator for legitimate purposes, however this behavior has been used in the wild to impair some user or deleting adversaries tracks created during its lateral movement additional systems. During triage, review parallel processes for additional behavior. Identify any other user accounts created before or after. +action.notable.param.rule_description = The following analytic detects the use of net.exe or net1.exe command-line to delete a user account on a system. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process and command-line execution logs. This activity is significant as it may indicate an attempt to impair user accounts or cover tracks during lateral movement. If confirmed malicious, this could lead to unauthorized access removal, disruption of legitimate user activities, or concealment of adversarial actions, complicating incident response and forensic investigations. action.notable.param.rule_title = Deleting Of Net Users action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21744,14 +21675,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Detect AzureHound Command-Line Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the common command-line argument used by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +description = The following analytic detects the execution of the `Invoke-AzureHound` command-line argument, commonly used by the AzureHound tool. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because AzureHound is often used for reconnaissance in Azure environments, potentially exposing sensitive information. If confirmed malicious, this activity could allow an attacker to map out Azure Active Directory structures, aiding in further attacks and privilege escalation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the common command-line argument used by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +action.escu.eli5 = The following analytic detects the execution of the `Invoke-AzureHound` command-line argument, commonly used by the AzureHound tool. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because AzureHound is often used for reconnaissance in Azure environments, potentially exposing sensitive information. If confirmed malicious, this activity could allow an attacker to map out Azure Active Directory structures, aiding in further attacks and privilege escalation. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Unknown. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AzureHound Command-Line Arguments - Rule action.escu.search_type = detection @@ -21769,11 +21700,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect AzureHound Command-Line Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Discovery Techniques"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "26f02e96-c300-11eb-b611-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "26f02e96-c300-11eb-b611-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the common command-line argument used by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +action.notable.param.rule_description = The following analytic detects the execution of the `Invoke-AzureHound` command-line argument, commonly used by the AzureHound tool. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because AzureHound is often used for reconnaissance in Azure environments, potentially exposing sensitive information. If confirmed malicious, this activity could allow an attacker to map out Azure Active Directory structures, aiding in further attacks and privilege escalation. action.notable.param.rule_title = Detect AzureHound Command-Line Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21791,14 +21722,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect AzureHound File Modifications - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic is similar to SharpHound file modifications, but this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound equivilent but for Azure. It's possible this may never be seen in an environment as most attackers may execute this tool remotely. Once execution is complete, a zip file with a similar name will drop `20210601090751-azurecollection.zip`. In addition to the zip, multiple .json files will be written to disk, which are in the zip. +description = The following analytic detects the creation of specific AzureHound-related files, such as `*-azurecollection.zip` and various `.json` files, on disk. It leverages data from the Endpoint.Filesystem datamodel, focusing on file creation events with specific filenames. This activity is significant because AzureHound is a tool used to gather information about Azure environments, similar to SharpHound for on-premises Active Directory. If confirmed malicious, this activity could indicate an attacker is collecting sensitive Azure environment data, potentially leading to further exploitation or privilege escalation within the cloud infrastructure. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic is similar to SharpHound file modifications, but this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound equivilent but for Azure. It's possible this may never be seen in an environment as most attackers may execute this tool remotely. Once execution is complete, a zip file with a similar name will drop `20210601090751-azurecollection.zip`. In addition to the zip, multiple .json files will be written to disk, which are in the zip. +action.escu.eli5 = The following analytic detects the creation of specific AzureHound-related files, such as `*-azurecollection.zip` and various `.json` files, on disk. It leverages data from the Endpoint.Filesystem datamodel, focusing on file creation events with specific filenames. This activity is significant because AzureHound is a tool used to gather information about Azure environments, similar to SharpHound for on-premises Active Directory. If confirmed malicious, this activity could indicate an attacker is collecting sensitive Azure environment data, potentially leading to further exploitation or privilege escalation within the cloud infrastructure. action.escu.how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. action.escu.known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect AzureHound File Modifications - Rule action.escu.search_type = detection @@ -21816,11 +21747,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect AzureHound File Modifications - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Discovery Techniques"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c34549e-c31b-11eb-996b-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1c34549e-c31b-11eb-996b-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic is similar to SharpHound file modifications, but this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound equivilent but for Azure. It's possible this may never be seen in an environment as most attackers may execute this tool remotely. Once execution is complete, a zip file with a similar name will drop `20210601090751-azurecollection.zip`. In addition to the zip, multiple .json files will be written to disk, which are in the zip. +action.notable.param.rule_description = The following analytic detects the creation of specific AzureHound-related files, such as `*-azurecollection.zip` and various `.json` files, on disk. It leverages data from the Endpoint.Filesystem datamodel, focusing on file creation events with specific filenames. This activity is significant because AzureHound is a tool used to gather information about Azure environments, similar to SharpHound for on-premises Active Directory. If confirmed malicious, this activity could indicate an attacker is collecting sensitive Azure environment data, potentially leading to further exploitation or privilege escalation within the cloud infrastructure. action.notable.param.rule_title = Detect AzureHound File Modifications action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21838,14 +21769,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Baron Samedit CVE-2021-3156 - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects attempts to exploit the Baron Samedit vulnerability (CVE-2021-3156) by identifying the use of the "sudoedit -s \\" command. This detection leverages logs from Linux systems, specifically searching for instances of the sudoedit command with the "-s" flag followed by a double quote. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows attackers to gain root privileges. If confirmed malicious, this could lead to complete system compromise, unauthorized access to sensitive data, and potential data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit. +action.escu.eli5 = The following analytic detects attempts to exploit the Baron Samedit vulnerability (CVE-2021-3156) by identifying the use of the "sudoedit -s \\" command. This detection leverages logs from Linux systems, specifically searching for instances of the sudoedit command with the "-s" flag followed by a double quote. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows attackers to gain root privileges. If confirmed malicious, this could lead to complete system compromise, unauthorized access to sensitive data, and potential data breaches. action.escu.how_to_implement = Splunk Universal Forwarder running on Linux systems, capturing logs from the /var/log directory. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-01-27 -action.escu.modification_date = 2021-01-27 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Baron Samedit CVE-2021-3156 - Rule action.escu.search_type = detection @@ -21863,11 +21794,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect Baron Samedit CVE-2021-3156 - Rule action.correlationsearch.annotations = {"analytic_story": ["Baron Samedit CVE-2021-3156"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2021-3156"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "93fbec4e-0375-440c-8db3-4508eca470c4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "93fbec4e-0375-440c-8db3-4508eca470c4", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit. +action.notable.param.rule_description = The following analytic detects attempts to exploit the Baron Samedit vulnerability (CVE-2021-3156) by identifying the use of the "sudoedit -s \\" command. This detection leverages logs from Linux systems, specifically searching for instances of the sudoedit command with the "-s" flag followed by a double quote. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows attackers to gain root privileges. If confirmed malicious, this could lead to complete system compromise, unauthorized access to sensitive data, and potential data breaches. action.notable.param.rule_title = Detect Baron Samedit CVE-2021-3156 action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21885,14 +21816,14 @@ search = `linux_hosts` "sudoedit -s \\" | `detect_baron_samedit_cve_2021_3156_fi [ESCU - Detect Baron Samedit CVE-2021-3156 Segfault - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies a heap-based buffer overflow in sudoedit by detecting Linux logs containing both "sudoedit" and "segfault" terms. This detection leverages Splunk to monitor for more than five occurrences of these terms on a single host within a specified timeframe. This activity is significant because exploiting this vulnerability (CVE-2021-3156) can allow attackers to gain root privileges, leading to potential system compromise, unauthorized access, and data breaches. If confirmed malicious, this could result in elevated privileges and full control over the affected system, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action. +action.escu.eli5 = The following analytic identifies a heap-based buffer overflow in sudoedit by detecting Linux logs containing both "sudoedit" and "segfault" terms. This detection leverages Splunk to monitor for more than five occurrences of these terms on a single host within a specified timeframe. This activity is significant because exploiting this vulnerability (CVE-2021-3156) can allow attackers to gain root privileges, leading to potential system compromise, unauthorized access, and data breaches. If confirmed malicious, this could result in elevated privileges and full control over the affected system, posing a severe security risk. action.escu.how_to_implement = Splunk Universal Forwarder running on Linux systems (tested on Centos and Ubuntu), where segfaults are being logged. This also captures instances where the exploit has been compiled into a binary. The detection looks for greater than 5 instances of sudoedit combined with segfault over your search time period on a single host action.escu.known_false_positives = If sudoedit is throwing segfaults for other reasons this will pick those up too. -action.escu.creation_date = 2021-01-29 -action.escu.modification_date = 2021-01-29 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Baron Samedit CVE-2021-3156 Segfault - Rule action.escu.search_type = detection @@ -21910,11 +21841,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect Baron Samedit CVE-2021-3156 Segfault - Rule action.correlationsearch.annotations = {"analytic_story": ["Baron Samedit CVE-2021-3156"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2021-3156"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10f2bae0-bbe6-4984-808c-37dc1c67980d", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10f2bae0-bbe6-4984-808c-37dc1c67980d", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action. +action.notable.param.rule_description = The following analytic identifies a heap-based buffer overflow in sudoedit by detecting Linux logs containing both "sudoedit" and "segfault" terms. This detection leverages Splunk to monitor for more than five occurrences of these terms on a single host within a specified timeframe. This activity is significant because exploiting this vulnerability (CVE-2021-3156) can allow attackers to gain root privileges, leading to potential system compromise, unauthorized access, and data breaches. If confirmed malicious, this could result in elevated privileges and full control over the affected system, posing a severe security risk. action.notable.param.rule_title = Detect Baron Samedit CVE-2021-3156 Segfault action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21932,14 +21863,14 @@ search = `linux_hosts` TERM(sudoedit) TERM(segfault) | stats count min(_time) as [ESCU - Detect Baron Samedit CVE-2021-3156 via OSQuery - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command "sudoedit -s *" is run using the osquery_process data source. This indicates that the sudoedit command is used with the "-s" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the "-s" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects the execution of the "sudoedit -s *" command, which is associated with the Baron Samedit CVE-2021-3156 heap-based buffer overflow vulnerability. This detection leverages the `osquery_process` data source to identify instances where this specific command is run. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows privilege escalation. If confirmed malicious, an attacker could gain full control of the system, execute arbitrary code, or access sensitive data, leading to potential data breaches and system disruptions. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command "sudoedit -s *" is run using the osquery_process data source. This indicates that the sudoedit command is used with the "-s" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the "-s" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment. +action.escu.eli5 = The following analytic detects the execution of the "sudoedit -s *" command, which is associated with the Baron Samedit CVE-2021-3156 heap-based buffer overflow vulnerability. This detection leverages the `osquery_process` data source to identify instances where this specific command is run. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows privilege escalation. If confirmed malicious, an attacker could gain full control of the system, execute arbitrary code, or access sensitive data, leading to potential data breaches and system disruptions. action.escu.how_to_implement = OSQuery installed and configured to pick up process events (info at https://osquery.io) as well as using the Splunk OSQuery Add-on https://splunkbase.splunk.com/app/4402. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-01-28 -action.escu.modification_date = 2021-01-28 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Baron Samedit CVE-2021-3156 via OSQuery - Rule action.escu.search_type = detection @@ -21957,11 +21888,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect Baron Samedit CVE-2021-3156 via OSQuery - Rule action.correlationsearch.annotations = {"analytic_story": ["Baron Samedit CVE-2021-3156"], "cis20": ["CIS 10"], "confidence": 50, "cve": ["CVE-2021-3156"], "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1de31d5d-8fa6-4ee0-af89-17069134118a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1de31d5d-8fa6-4ee0-af89-17069134118a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command "sudoedit -s *" is run using the osquery_process data source. This indicates that the sudoedit command is used with the "-s" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the "-s" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment. +action.notable.param.rule_description = The following analytic detects the execution of the "sudoedit -s *" command, which is associated with the Baron Samedit CVE-2021-3156 heap-based buffer overflow vulnerability. This detection leverages the `osquery_process` data source to identify instances where this specific command is run. This activity is significant because it indicates an attempt to exploit a known vulnerability that allows privilege escalation. If confirmed malicious, an attacker could gain full control of the system, execute arbitrary code, or access sensitive data, leading to potential data breaches and system disruptions. action.notable.param.rule_title = Detect Baron Samedit CVE-2021-3156 via OSQuery action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -21979,14 +21910,14 @@ search = `osquery_process` | search "columns.cmdline"="sudoedit -s \\*" | `detec [ESCU - Detect Certify Command Line Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when the attacker tool Certify or Certipy are used to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments of these tools are similar and perform near identical enumeration or exploitation functions. +description = The following analytic detects the use of Certify or Certipy tools to enumerate Active Directory Certificate Services (AD CS) environments. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with these tools. This activity is significant because it indicates potential reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized access or privilege escalation. If confirmed malicious, attackers could gain insights into the AD CS infrastructure, potentially compromising sensitive certificates and escalating their privileges within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1649", "T1105"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies when the attacker tool Certify or Certipy are used to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments of these tools are similar and perform near identical enumeration or exploitation functions. +action.escu.eli5 = The following analytic detects the use of Certify or Certipy tools to enumerate Active Directory Certificate Services (AD CS) environments. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with these tools. This activity is significant because it indicates potential reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized access or privilege escalation. If confirmed malicious, attackers could gain insights into the AD CS infrastructure, potentially compromising sensitive certificates and escalating their privileges within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Unknown -action.escu.creation_date = 2023-06-25 -action.escu.modification_date = 2023-06-25 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Certify Command Line Arguments - Rule action.escu.search_type = detection @@ -22004,11 +21935,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Certify Command Line Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["Ingress Tool Transfer", "Windows Certificate Services"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1649", "T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e6d2dc61-a8b9-4b03-906c-da0ca75d71b8", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e6d2dc61-a8b9-4b03-906c-da0ca75d71b8", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when the attacker tool Certify or Certipy are used to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments of these tools are similar and perform near identical enumeration or exploitation functions. +action.notable.param.rule_description = The following analytic detects the use of Certify or Certipy tools to enumerate Active Directory Certificate Services (AD CS) environments. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with these tools. This activity is significant because it indicates potential reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized access or privilege escalation. If confirmed malicious, attackers could gain insights into the AD CS infrastructure, potentially compromising sensitive certificates and escalating their privileges within the network. action.notable.param.rule_title = Detect Certify Command Line Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22026,14 +21957,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Certify With PowerShell Script Block Logging - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when the attacker tool Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions. +description = The following analytic detects the use of the Certify tool via an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. It leverages PowerShell Script Block Logging (EventCode 4104) to identify specific command patterns associated with Certify's enumeration and exploitation functions. This activity is significant as it indicates potential reconnaissance or exploitation attempts against AD CS, which could lead to unauthorized certificate issuance. If confirmed malicious, attackers could leverage this to escalate privileges, persist in the environment, or access sensitive information by abusing AD CS. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1649", "T1059", "T1059.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies when the attacker tool Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions. +action.escu.eli5 = The following analytic detects the use of the Certify tool via an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. It leverages PowerShell Script Block Logging (EventCode 4104) to identify specific command patterns associated with Certify's enumeration and exploitation functions. This activity is significant as it indicates potential reconnaissance or exploitation attempts against AD CS, which could lead to unauthorized certificate issuance. If confirmed malicious, attackers could leverage this to escalate privileges, persist in the environment, or access sensitive information by abusing AD CS. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.. action.escu.known_false_positives = Unknown, partial script block matches. -action.escu.creation_date = 2023-06-25 -action.escu.modification_date = 2023-06-25 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Certify With PowerShell Script Block Logging - Rule action.escu.search_type = detection @@ -22051,11 +21982,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Certify With PowerShell Script Block Logging - Rule action.correlationsearch.annotations = {"analytic_story": ["Malicious PowerShell", "Windows Certificate Services"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1649", "T1059", "T1059.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f533ca6c-9440-4686-80cb-7f294c07812a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f533ca6c-9440-4686-80cb-7f294c07812a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when the attacker tool Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions. +action.notable.param.rule_description = The following analytic detects the use of the Certify tool via an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. It leverages PowerShell Script Block Logging (EventCode 4104) to identify specific command patterns associated with Certify's enumeration and exploitation functions. This activity is significant as it indicates potential reconnaissance or exploitation attempts against AD CS, which could lead to unauthorized certificate issuance. If confirmed malicious, attackers could leverage this to escalate privileges, persist in the environment, or access sensitive information by abusing AD CS. action.notable.param.rule_title = Detect Certify With PowerShell Script Block Logging action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22073,14 +22004,14 @@ search = `powershell` EventCode=4104 (ScriptBlockText IN ("*find *") AND ScriptB [ESCU - Detect Certipy File Modifications - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process. +description = The following analytic detects the use of the Certipy tool to enumerate Active Directory Certificate Services (AD CS) environments by identifying unique file modifications. It leverages endpoint process and filesystem data to spot the creation of files with specific names or extensions associated with Certipy's information gathering and exfiltration activities. This activity is significant as it indicates potential reconnaissance and data exfiltration efforts by an attacker. If confirmed malicious, this could lead to unauthorized access to sensitive AD CS information, enabling further attacks or privilege escalation within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1560"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process. +action.escu.eli5 = The following analytic detects the use of the Certipy tool to enumerate Active Directory Certificate Services (AD CS) environments by identifying unique file modifications. It leverages endpoint process and filesystem data to spot the creation of files with specific names or extensions associated with Certipy's information gathering and exfiltration activities. This activity is significant as it indicates potential reconnaissance and data exfiltration efforts by an attacker. If confirmed malicious, this could lead to unauthorized access to sensitive AD CS information, enabling further attacks or privilege escalation within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints as well as file creation or deletion events. action.escu.known_false_positives = Unknown -action.escu.creation_date = 2023-06-25 -action.escu.modification_date = 2023-06-25 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Certipy File Modifications - Rule action.escu.search_type = detection @@ -22098,11 +22029,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Certipy File Modifications - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Exfiltration", "Ingress Tool Transfer", "Windows Certificate Services"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1560"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7e3df743-b1d8-4631-8fa8-bd5819688876", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "7e3df743-b1d8-4631-8fa8-bd5819688876", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process. +action.notable.param.rule_description = The following analytic detects the use of the Certipy tool to enumerate Active Directory Certificate Services (AD CS) environments by identifying unique file modifications. It leverages endpoint process and filesystem data to spot the creation of files with specific names or extensions associated with Certipy's information gathering and exfiltration activities. This activity is significant as it indicates potential reconnaissance and data exfiltration efforts by an attacker. If confirmed malicious, this could lead to unauthorized access to sensitive AD CS information, enabling further attacks or privilege escalation within the network. action.notable.param.rule_title = Detect Certipy File Modifications action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22156,20 +22087,14 @@ search = `wineventlog_security` EventCode=4624 OR EventCode=4742 TargetUserName= [ESCU - Detect Copy of ShadowCopy with Script Block Logging - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the most basic use cases for credentials being taken for offline cracking. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +description = The following analytic detects the use of PowerShell commands to copy the SAM, SYSTEM, or SECURITY hives, which are critical for credential theft. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command executed. This activity is significant as it indicates an attempt to exfiltrate sensitive registry hives for offline password cracking. If confirmed malicious, this could lead to unauthorized access to credentials, enabling further compromise of the system and potential lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the most basic use cases for credentials being taken for offline cracking. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.escu.eli5 = The following analytic detects the use of PowerShell commands to copy the SAM, SYSTEM, or SECURITY hives, which are critical for credential theft. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command executed. This activity is significant as it indicates an attempt to exfiltrate sensitive registry hives for offline password cracking. If confirmed malicious, this could lead to unauthorized access to credentials, enabling further compromise of the system and potential lateral movement within the network. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Limited false positives as the scope is limited to SAM, SYSTEM and SECURITY hives. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Copy of ShadowCopy with Script Block Logging - Rule action.escu.search_type = detection @@ -22187,14 +22112,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Copy of ShadowCopy with Script Block Logging - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping"], "cis20": ["CIS 10"], "confidence": 100, "cve": ["CVE-2021-36934"], "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9251299c-ea5b-11eb-a8de-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9251299c-ea5b-11eb-a8de-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the most basic use cases for credentials being taken for offline cracking. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.notable.param.rule_description = The following analytic detects the use of PowerShell commands to copy the SAM, SYSTEM, or SECURITY hives, which are critical for credential theft. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command executed. This activity is significant as it indicates an attempt to exfiltrate sensitive registry hives for offline password cracking. If confirmed malicious, this could lead to unauthorized access to credentials, enabling further compromise of the system and potential lateral movement within the network. action.notable.param.rule_title = Detect Copy of ShadowCopy with Script Block Logging action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22212,14 +22134,14 @@ search = `powershell` EventCode=4104 ScriptBlockText IN ("*copy*","*[System.IO.F [ESCU - Detect Credential Dumping through LSASS access - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities. +description = The following analytic detects attempts to read LSASS memory, indicative of credential dumping. It leverages Sysmon EventCode 10, filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process. This activity is significant because it suggests an attacker is trying to extract credentials from LSASS memory, potentially leading to unauthorized access, data breaches, and compromise of sensitive information. If confirmed malicious, this could enable attackers to escalate privileges, move laterally within the network, or exfiltrate data. Extensive triage is necessary to differentiate between malicious and benign activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities. +action.escu.eli5 = The following analytic detects attempts to read LSASS memory, indicative of credential dumping. It leverages Sysmon EventCode 10, filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process. This activity is significant because it suggests an attacker is trying to extract credentials from LSASS memory, potentially leading to unauthorized access, data breaches, and compromise of sensitive information. If confirmed malicious, this could enable attackers to escalate privileges, move laterally within the network, or exfiltrate data. Extensive triage is necessary to differentiate between malicious and benign activities. action.escu.how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives. action.escu.known_false_positives = The activity may be legitimate. Other tools can access lsass for legitimate reasons, and it's possible this event could be generated in those cases. In these cases, false positives should be fairly obvious and you may need to tweak the search to eliminate noise. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Credential Dumping through LSASS access - Rule action.escu.search_type = detection @@ -22237,11 +22159,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Credential Dumping through LSASS access - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Credential Dumping", "Detect Zerologon Attack"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2c365e57-4414-4540-8dc0-73ab10729996", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2c365e57-4414-4540-8dc0-73ab10729996", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities. +action.notable.param.rule_description = The following analytic detects attempts to read LSASS memory, indicative of credential dumping. It leverages Sysmon EventCode 10, filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process. This activity is significant because it suggests an attacker is trying to extract credentials from LSASS memory, potentially leading to unauthorized access, data breaches, and compromise of sensitive information. If confirmed malicious, this could enable attackers to escalate privileges, move laterally within the network, or exfiltrate data. Extensive triage is necessary to differentiate between malicious and benign activities. action.notable.param.rule_title = Detect Credential Dumping through LSASS access action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22254,25 +22176,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410) | stats count min(_time) as firstTime max(_time) as lastTime by dest, SourceImage, SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_credential_dumping_through_lsass_access_filter` +search = `sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410) | stats count min(_time) as firstTime max(_time) as lastTime by dest, SourceImage, SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `detect_credential_dumping_through_lsass_access_filter` [ESCU - Detect Empire with PowerShell Script Block Logging - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the common PowerShell stager used by PowerShell-Empire. Each stager that may use PowerShell all uses the same pattern. The initial HTTP will be base64 encoded and use `system.net.webclient`. Note that some obfuscation may evade the analytic. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +description = The following analytic detects suspicious PowerShell execution indicative of PowerShell-Empire activity. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze commands sent to PowerShell, specifically looking for patterns involving `system.net.webclient` and base64 encoding. This behavior is significant as it often represents initial stagers used by PowerShell-Empire, a known post-exploitation framework. If confirmed malicious, this activity could allow attackers to download and execute additional payloads, leading to potential code execution, data exfiltration, or further compromise of the affected system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the common PowerShell stager used by PowerShell-Empire. Each stager that may use PowerShell all uses the same pattern. The initial HTTP will be base64 encoded and use `system.net.webclient`. Note that some obfuscation may evade the analytic. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.escu.eli5 = The following analytic detects suspicious PowerShell execution indicative of PowerShell-Empire activity. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze commands sent to PowerShell, specifically looking for patterns involving `system.net.webclient` and base64 encoding. This behavior is significant as it often represents initial stagers used by PowerShell-Empire, a known post-exploitation framework. If confirmed malicious, this activity could allow attackers to download and execute additional payloads, leading to potential code execution, data exfiltration, or further compromise of the affected system. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = False positives may only pertain to it not being related to Empire, but another framework. Filter as needed if any applications use the same pattern. -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Empire with PowerShell Script Block Logging - Rule action.escu.search_type = detection @@ -22290,14 +22206,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Empire with PowerShell Script Block Logging - Rule action.correlationsearch.annotations = {"analytic_story": ["Data Destruction", "Hermetic Wiper", "Malicious PowerShell"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc1dc6b8-c954-11eb-bade-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc1dc6b8-c954-11eb-bade-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \ - \ -This analytic identifies the common PowerShell stager used by PowerShell-Empire. Each stager that may use PowerShell all uses the same pattern. The initial HTTP will be base64 encoded and use `system.net.webclient`. Note that some obfuscation may evade the analytic. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.notable.param.rule_description = The following analytic detects suspicious PowerShell execution indicative of PowerShell-Empire activity. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze commands sent to PowerShell, specifically looking for patterns involving `system.net.webclient` and base64 encoding. This behavior is significant as it often represents initial stagers used by PowerShell-Empire, a known post-exploitation framework. If confirmed malicious, this activity could allow attackers to download and execute additional payloads, leading to potential code execution, data exfiltration, or further compromise of the affected system. action.notable.param.rule_title = Detect Empire with PowerShell Script Block Logging action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22399,14 +22312,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Exchange Web Shell - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant. +description = The following analytic identifies the creation of suspicious .aspx files in known drop locations for Exchange exploitation, specifically targeting paths associated with HAFNIUM group and vulnerabilities like ProxyShell and ProxyNotShell. It leverages data from the Endpoint datamodel, focusing on process and filesystem events. This activity is significant as it may indicate a web shell deployment, a common method for persistent access and remote code execution. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary commands, and potentially escalate privileges within the Exchange environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant. +action.escu.eli5 = The following analytic identifies the creation of suspicious .aspx files in known drop locations for Exchange exploitation, specifically targeting paths associated with HAFNIUM group and vulnerabilities like ProxyShell and ProxyNotShell. It leverages data from the Endpoint datamodel, focusing on process and filesystem events. This activity is significant as it may indicate a web shell deployment, a common method for persistent access and remote code execution. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary commands, and potentially escalate privileges within the Exchange environment. action.escu.how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node. action.escu.known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Exchange Web Shell - Rule action.escu.search_type = detection @@ -22424,11 +22337,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Exchange Web Shell - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "CISA AA22-257A", "HAFNIUM Group", "ProxyNotShell", "ProxyShell"], "cis20": ["CIS 10"], "confidence": 90, "impact": 90, "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8c14eeee-2af1-4a4b-bda8-228da0f4862a", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8c14eeee-2af1-4a4b-bda8-228da0f4862a", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant. +action.notable.param.rule_description = The following analytic identifies the creation of suspicious .aspx files in known drop locations for Exchange exploitation, specifically targeting paths associated with HAFNIUM group and vulnerabilities like ProxyShell and ProxyNotShell. It leverages data from the Endpoint datamodel, focusing on process and filesystem events. This activity is significant as it may indicate a web shell deployment, a common method for persistent access and remote code execution. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary commands, and potentially escalate privileges within the Exchange environment. action.notable.param.rule_title = Detect Exchange Web Shell action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22446,14 +22359,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Detect HTML Help Renamed - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies a renamed instance of hh.exe (HTML Help) executing a Compiled HTML Help (CHM). This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Validate it is the legitimate version of hh.exe by reviewing the PE metadata. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description = The following analytic detects instances where hh.exe (HTML Help) has been renamed and is executing a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because attackers can use renamed hh.exe to execute malicious scripts embedded in CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow attackers to run arbitrary scripts, escalate privileges, or persist within the environment, posing a significant security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies a renamed instance of hh.exe (HTML Help) executing a Compiled HTML Help (CHM). This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Validate it is the legitimate version of hh.exe by reviewing the PE metadata. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.escu.eli5 = The following analytic detects instances where hh.exe (HTML Help) has been renamed and is executing a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because attackers can use renamed hh.exe to execute malicious scripts embedded in CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow attackers to run arbitrary scripts, escalate privileges, or persist within the environment, posing a significant security risk. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely a renamed instance of hh.exe will be used legitimately, filter as needed. -action.escu.creation_date = 2022-04-07 -action.escu.modification_date = 2022-04-07 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect HTML Help Renamed - Rule action.escu.search_type = detection @@ -22466,7 +22379,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect HTML Help Renamed - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Compiled HTML Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "62fed254-513b-460e-953d-79771493a9f3", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "62fed254-513b-460e-953d-79771493a9f3", "detection_version": "5"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -22482,14 +22395,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect HTML Help Spawn Child Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) that spawns a child process. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review child process events and investigate further. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description = The following analytic detects the execution of hh.exe (HTML Help) spawning a child process, indicating the use of a Compiled HTML Help (CHM) file to execute Windows script code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where hh.exe is the parent process. This activity is significant as it may indicate an attempt to execute malicious scripts via CHM files, a known technique for bypassing security controls. If confirmed malicious, this could lead to unauthorized code execution, potentially compromising the system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) that spawns a child process. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review child process events and investigate further. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.escu.eli5 = The following analytic detects the execution of hh.exe (HTML Help) spawning a child process, indicating the use of a Compiled HTML Help (CHM) file to execute Windows script code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where hh.exe is the parent process. This activity is significant as it may indicate an attempt to execute malicious scripts via CHM files, a known technique for bypassing security controls. If confirmed malicious, this could lead to unauthorized code execution, potentially compromising the system. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications (ex. web browsers) may spawn a child process. Filter as needed. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect HTML Help Spawn Child Process - Rule action.escu.search_type = detection @@ -22507,11 +22420,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect HTML Help Spawn Child Process - Rule action.correlationsearch.annotations = {"analytic_story": ["AgentTesla", "Living Off The Land", "Suspicious Compiled HTML Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "723716de-ee55-4cd4-9759-c44e7e55ba4b", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "723716de-ee55-4cd4-9759-c44e7e55ba4b", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) that spawns a child process. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review child process events and investigate further. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.notable.param.rule_description = The following analytic detects the execution of hh.exe (HTML Help) spawning a child process, indicating the use of a Compiled HTML Help (CHM) file to execute Windows script code. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where hh.exe is the parent process. This activity is significant as it may indicate an attempt to execute malicious scripts via CHM files, a known technique for bypassing security controls. If confirmed malicious, this could lead to unauthorized code execution, potentially compromising the system. action.notable.param.rule_title = Detect HTML Help Spawn Child Process action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22529,14 +22442,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect HTML Help URL in Command Line - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file from a remote url. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review reputation of remote IP and domain. Some instances, it is worth decompiling the .chm file to review its original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description = The following analytic detects the execution of hh.exe (HTML Help) loading a Compiled HTML Help (CHM) file from a remote URL. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing URLs. This activity is significant as it can indicate an attempt to execute malicious scripts via CHM files, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to run scripts using engines like JScript or VBScript, leading to further system compromise or data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file from a remote url. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review reputation of remote IP and domain. Some instances, it is worth decompiling the .chm file to review its original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.escu.eli5 = The following analytic detects the execution of hh.exe (HTML Help) loading a Compiled HTML Help (CHM) file from a remote URL. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing URLs. This activity is significant as it can indicate an attempt to execute malicious scripts via CHM files, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to run scripts using engines like JScript or VBScript, leading to further system compromise or data exfiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may retrieve a CHM remotely, filter as needed. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect HTML Help URL in Command Line - Rule action.escu.search_type = detection @@ -22554,11 +22467,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect HTML Help URL in Command Line - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Compiled HTML Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8c5835b9-39d9-438b-817c-95f14c69a31e", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8c5835b9-39d9-438b-817c-95f14c69a31e", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file from a remote url. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review reputation of remote IP and domain. Some instances, it is worth decompiling the .chm file to review its original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.notable.param.rule_description = The following analytic detects the execution of hh.exe (HTML Help) loading a Compiled HTML Help (CHM) file from a remote URL. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions containing URLs. This activity is significant as it can indicate an attempt to execute malicious scripts via CHM files, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to run scripts using engines like JScript or VBScript, leading to further system compromise or data exfiltration. action.notable.param.rule_title = Detect HTML Help URL in Command Line action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22576,14 +22489,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique will load Windows script code from a compiled help file, using InfoTech Storage Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm file from within a CHM file. CHM files may contain nearly any file type embedded. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description = The following analytic detects the execution of hh.exe (HTML Help) using InfoTech Storage Handlers to load Windows script code from a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because it can be used to execute malicious scripts embedded within CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique will load Windows script code from a compiled help file, using InfoTech Storage Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm file from within a CHM file. CHM files may contain nearly any file type embedded. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.escu.eli5 = The following analytic detects the execution of hh.exe (HTML Help) using InfoTech Storage Handlers to load Windows script code from a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because it can be used to execute malicious scripts embedded within CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = It is rare to see instances of InfoTech Storage Handlers being used, but it does happen in some legitimate instances. Filter as needed. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule action.escu.search_type = detection @@ -22601,11 +22514,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Compiled HTML Activity"], "cis20": ["CIS 10"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b2eefa5-5508-450d-b970-3dd2fb761aec", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0b2eefa5-5508-450d-b970-3dd2fb761aec", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique will load Windows script code from a compiled help file, using InfoTech Storage Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm file from within a CHM file. CHM files may contain nearly any file type embedded. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.notable.param.rule_description = The following analytic detects the execution of hh.exe (HTML Help) using InfoTech Storage Handlers to load Windows script code from a Compiled HTML Help (CHM) file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because it can be used to execute malicious scripts embedded within CHM files, potentially leading to code execution. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment. action.notable.param.rule_title = Detect HTML Help Using InfoTech Storage Handlers action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22623,20 +22536,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies common Mimikatz functions that may be identified in the script block, including `mimikatz`. This will catch the most basic use cases for Pass the Ticket, Pass the Hash and `-DumprCreds`. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +description = The following analytic detects the execution of Mimikatz commands via PowerShell by leveraging PowerShell Script Block Logging (EventCode=4104). This method captures and logs the full command sent to PowerShell, allowing for the identification of suspicious activities such as Pass the Ticket, Pass the Hash, and credential dumping. This activity is significant as Mimikatz is a well-known tool used for credential theft and lateral movement. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1003", "T1059.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies common Mimikatz functions that may be identified in the script block, including `mimikatz`. This will catch the most basic use cases for Pass the Ticket, Pass the Hash and `-DumprCreds`. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.escu.eli5 = The following analytic detects the execution of Mimikatz commands via PowerShell by leveraging PowerShell Script Block Logging (EventCode=4104). This method captures and logs the full command sent to PowerShell, allowing for the identification of suspicious activities such as Pass the Ticket, Pass the Hash, and credential dumping. This activity is significant as Mimikatz is a well-known tool used for credential theft and lateral movement. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information within the environment. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = False positives should be limited as the commands being identifies are quite specific to EventCode 4104 and Mimikatz. Filter as needed. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule action.escu.search_type = detection @@ -22654,14 +22561,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-264A", "CISA AA22-320A", "CISA AA23-347A", "Data Destruction", "Hermetic Wiper", "Malicious PowerShell", "Sandworm Tools"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1003", "T1059.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8148c29c-c952-11eb-9255-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8148c29c-c952-11eb-9255-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \ - \ -This analytic identifies common Mimikatz functions that may be identified in the script block, including `mimikatz`. This will catch the most basic use cases for Pass the Ticket, Pass the Hash and `-DumprCreds`. \ -During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block. +action.notable.param.rule_description = The following analytic detects the execution of Mimikatz commands via PowerShell by leveraging PowerShell Script Block Logging (EventCode=4104). This method captures and logs the full command sent to PowerShell, allowing for the identification of suspicious activities such as Pass the Ticket, Pass the Hash, and credential dumping. This activity is significant as Mimikatz is a well-known tool used for credential theft and lateral movement. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of sensitive information within the environment. action.notable.param.rule_title = Detect Mimikatz With PowerShell Script Block Logging action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22679,14 +22583,14 @@ search = `powershell` EventCode=4104 ScriptBlockText IN (*mimikatz*, *-dumpcr*, [ESCU - Detect mshta inline hta execution - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies "mshta.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "mshta.exe" and its parent process. +description = The following analytic detects the execution of "mshta.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments and process details. This activity is significant because mshta.exe can be exploited to execute malicious scripts, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or establish persistence within the environment, posing a severe security risk. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies "mshta.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "mshta.exe" and its parent process. +action.escu.eli5 = The following analytic detects the execution of "mshta.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments and process details. This activity is significant because mshta.exe can be exploited to execute malicious scripts, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or establish persistence within the environment, posing a severe security risk. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect mshta inline hta execution - Rule action.escu.search_type = detection @@ -22704,11 +22608,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect mshta inline hta execution - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious MSHTA Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 90, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a0873b32-5b68-11eb-ae93-0242ac130002", "detection_version": "6"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a0873b32-5b68-11eb-ae93-0242ac130002", "detection_version": "7"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies "mshta.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "mshta.exe" and its parent process. +action.notable.param.rule_description = The following analytic detects the execution of "mshta.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments and process details. This activity is significant because mshta.exe can be exploited to execute malicious scripts, potentially leading to unauthorized code execution. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or establish persistence within the environment, posing a severe security risk. action.notable.param.rule_title = Detect mshta inline hta execution action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22726,14 +22630,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Detect mshta renamed - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies renamed instances of mshta.exe executing. Mshta.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. This analytic utilizes the internal name of the PE to identify if is the legitimate mshta binary. Further analysis should be performed to review the executed content and validation it is the real mshta. +description = The following analytic identifies instances where mshta.exe has been renamed and executed. It leverages Endpoint Detection and Response (EDR) data, specifically focusing on the original file name field to detect discrepancies. This activity is significant because renaming mshta.exe is a common tactic used by attackers to evade detection and execute malicious scripts. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies renamed instances of mshta.exe executing. Mshta.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. This analytic utilizes the internal name of the PE to identify if is the legitimate mshta binary. Further analysis should be performed to review the executed content and validation it is the real mshta. +action.escu.eli5 = The following analytic identifies instances where mshta.exe has been renamed and executed. It leverages Endpoint Detection and Response (EDR) data, specifically focusing on the original file name field to detect discrepancies. This activity is significant because renaming mshta.exe is a common tactic used by attackers to evade detection and execute malicious scripts. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may use a moved copy of mshta.exe, but never renamed, triggering a false positive. -action.escu.creation_date = 2022-04-07 -action.escu.modification_date = 2022-04-07 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect mshta renamed - Rule action.escu.search_type = detection @@ -22746,7 +22650,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect mshta renamed - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious MSHTA Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8f45fcf0-5b68-11eb-ae93-0242ac130002", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8f45fcf0-5b68-11eb-ae93-0242ac130002", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -22762,14 +22666,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect MSHTA Url in Command Line - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies when Microsoft HTML Application Host (mshta.exe) utility is used to make remote http connections. Adversaries may use mshta.exe to proxy the download and execution of remote .hta files. The analytic identifies command line arguments of http and https being used. This technique is commonly used by malicious software to bypass preventative controls. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +description = The following analytic detects the use of Microsoft HTML Application Host (mshta.exe) to make remote HTTP or HTTPS connections. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments containing URLs. This activity is significant because adversaries often use mshta.exe to download and execute remote .hta files, bypassing security controls. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further network infiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies when Microsoft HTML Application Host (mshta.exe) utility is used to make remote http connections. Adversaries may use mshta.exe to proxy the download and execution of remote .hta files. The analytic identifies command line arguments of http and https being used. This technique is commonly used by malicious software to bypass preventative controls. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +action.escu.eli5 = The following analytic detects the use of Microsoft HTML Application Host (mshta.exe) to make remote HTTP or HTTPS connections. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments containing URLs. This activity is significant because adversaries often use mshta.exe to download and execute remote .hta files, bypassing security controls. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further network infiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = It is possible legitimate applications may perform this behavior and will need to be filtered. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect MSHTA Url in Command Line - Rule action.escu.search_type = detection @@ -22787,11 +22691,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect MSHTA Url in Command Line - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious MSHTA Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9b3af1e6-5b68-11eb-ae93-0242ac130002", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9b3af1e6-5b68-11eb-ae93-0242ac130002", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies when Microsoft HTML Application Host (mshta.exe) utility is used to make remote http connections. Adversaries may use mshta.exe to proxy the download and execution of remote .hta files. The analytic identifies command line arguments of http and https being used. This technique is commonly used by malicious software to bypass preventative controls. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +action.notable.param.rule_description = The following analytic detects the use of Microsoft HTML Application Host (mshta.exe) to make remote HTTP or HTTPS connections. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line arguments containing URLs. This activity is significant because adversaries often use mshta.exe to download and execute remote .hta files, bypassing security controls. If confirmed malicious, this behavior could allow attackers to execute arbitrary code, potentially leading to system compromise, data exfiltration, or further network infiltration. action.notable.param.rule_title = Detect MSHTA Url in Command Line action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -22809,14 +22713,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Detect New Local Admin account - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack. +description = The following analytic detects the creation of new accounts elevated to local administrators. It uses Windows event logs, specifically EventCode 4720 (user account creation) and EventCode 4732 (user added to Administrators group). This activity is significant as it indicates potential unauthorized privilege escalation, which is critical for SOC monitoring. If confirmed malicious, this could allow attackers to gain administrative access, leading to unauthorized data access, system modifications, and disruption of services. Immediate investigation is required to mitigate risks and prevent further unauthorized actions. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack. +action.escu.eli5 = The following analytic detects the creation of new accounts elevated to local administrators. It uses Windows event logs, specifically EventCode 4720 (user account creation) and EventCode 4732 (user added to Administrators group). This activity is significant as it indicates potential unauthorized privilege escalation, which is critical for SOC monitoring. If confirmed malicious, this could allow attackers to gain administrative access, leading to unauthorized data access, system modifications, and disruption of services. Immediate investigation is required to mitigate risks and prevent further unauthorized actions. action.escu.how_to_implement = You must be ingesting Windows event logs using the Splunk Windows TA and collecting event code 4720 and 4732 action.escu.known_false_positives = The activity may be legitimate. For this reason, it's best to verify the account with an administrator and ask whether there was a valid service request for the account creation. If your local administrator group name is not "Administrators", this search may generate an excessive number of false positives -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect New Local Admin account - Rule action.escu.search_type = detection @@ -22834,11 +22738,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect New Local Admin account - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-257A", "DHS Report TA18-074A", "HAFNIUM Group"], "cis20": ["CIS 10"], "confidence": 70, "impact": 60, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b25f6f62-0712-43c1-b203-083231ffd97d", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b25f6f62-0712-43c1-b203-083231ffd97d", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack. +action.notable.param.rule_description = The following analytic detects the creation of new accounts elevated to local administrators. It uses Windows event logs, specifically EventCode 4720 (user account creation) and EventCode 4732 (user added to Administrators group). This activity is significant as it indicates potential unauthorized privilege escalation, which is critical for SOC monitoring. If confirmed malicious, this could allow attackers to gain administrative access, leading to unauthorized data access, system modifications, and disruption of services. Immediate investigation is required to mitigate risks and prevent further unauthorized actions. action.notable.param.rule_title = Detect New Local Admin account action.notable.param.security_domain = access action.notable.param.severity = high @@ -22898,7 +22802,7 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.process_name=outlook.exe by _time span=5m Processes.parent_process_id Processes.process_id Processes.dest Processes.process_name Processes.parent_process_name Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename process_id as malicious_id| rename parent_process_id as outlook_id| join malicious_id type=inner[| tstats `security_content_summariesonly` count values(Filesystem.file_path) as file_path values(Filesystem.file_name) as file_name FROM datamodel=Endpoint.Filesystem where (Filesystem.file_path=*.zip* OR Filesystem.file_name=*.lnk ) AND (Filesystem.file_path=C:\\Users* OR Filesystem.file_path=*Local\\Temp*) by _time span=5m Filesystem.process_id Filesystem.file_hash Filesystem.dest | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename process_id as malicious_id| fields malicious_id outlook_id dest file_path file_name file_hash count file_id] | table firstTime lastTime user malicious_id outlook_id process_name parent_process_name file_name file_path | where file_name != "" | `detect_outlook_exe_writing_a_zip_file_filter` +search = | tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.process_name=outlook.exe by _time span=5m Processes.parent_process_id Processes.process_id Processes.dest Processes.process_name Processes.parent_process_name Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename process_id as malicious_id| rename parent_process_id as outlook_id| join malicious_id type=inner[| tstats `security_content_summariesonly` count values(Filesystem.file_path) as file_path values(Filesystem.file_name) as file_name FROM datamodel=Endpoint.Filesystem where (Filesystem.file_path=*.zip* OR Filesystem.file_name=*.lnk ) AND (Filesystem.file_path=C:\\Users* OR Filesystem.file_path=*Local\\Temp*) by _time span=5m Filesystem.process_id Filesystem.file_hash Filesystem.dest | `drop_dm_object_name(Filesystem)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | rename process_id as malicious_id| fields malicious_id outlook_id dest file_path file_name file_hash count file_id] | table firstTime lastTime user malicious_id outlook_id process_name parent_process_name file_name file_path | where file_name != "" | `detect_outlook_exe_writing_a_zip_file_filter` [ESCU - Detect Path Interception By Creation Of program exe - Rule] action.escu = 0 @@ -23033,14 +22937,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Detect PsExec With accepteula Flag - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for events where `PsExec.exe` is run with the `accepteula` flag in the command line. PsExec is a built-in Windows utility that enables you to execute processes on other systems. It is fully interactive for console applications. This tool is widely used for launching interactive command prompts on remote systems. Threat actors leverage this extensively for executing code on compromised systems. If an attacker is running PsExec for the first time, they will be prompted to accept the end-user license agreement (EULA), which can be passed as the argument `accepteula` within the command line. +description = The following analytic identifies the execution of `PsExec.exe` with the `accepteula` flag in the command line. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because PsExec is commonly used by threat actors to execute code on remote systems, and the `accepteula` flag indicates first-time usage, which could signify initial compromise. If confirmed malicious, this activity could allow attackers to gain remote code execution capabilities, potentially leading to further system compromise and lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search looks for events where `PsExec.exe` is run with the `accepteula` flag in the command line. PsExec is a built-in Windows utility that enables you to execute processes on other systems. It is fully interactive for console applications. This tool is widely used for launching interactive command prompts on remote systems. Threat actors leverage this extensively for executing code on compromised systems. If an attacker is running PsExec for the first time, they will be prompted to accept the end-user license agreement (EULA), which can be passed as the argument `accepteula` within the command line. +action.escu.eli5 = The following analytic identifies the execution of `PsExec.exe` with the `accepteula` flag in the command line. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because PsExec is commonly used by threat actors to execute code on remote systems, and the `accepteula` flag indicates first-time usage, which could signify initial compromise. If confirmed malicious, this activity could allow attackers to gain remote code execution capabilities, potentially leading to further system compromise and lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators can leverage PsExec for accessing remote systems and might pass `accepteula` as an argument if they are running this tool for the first time. However, it is not likely that you'd see multiple occurrences of this event on a machine -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect PsExec With accepteula Flag - Rule action.escu.search_type = detection @@ -23058,11 +22962,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect PsExec With accepteula Flag - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Lateral Movement", "BlackByte Ransomware", "CISA AA22-320A", "DHS Report TA18-074A", "DarkGate Malware", "DarkSide Ransomware", "HAFNIUM Group", "IcedID", "Rhysida Ransomware", "SamSam Ransomware", "Sandworm Tools", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "27c3a83d-cada-47c6-9042-67baf19d2574", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "27c3a83d-cada-47c6-9042-67baf19d2574", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for events where `PsExec.exe` is run with the `accepteula` flag in the command line. PsExec is a built-in Windows utility that enables you to execute processes on other systems. It is fully interactive for console applications. This tool is widely used for launching interactive command prompts on remote systems. Threat actors leverage this extensively for executing code on compromised systems. If an attacker is running PsExec for the first time, they will be prompted to accept the end-user license agreement (EULA), which can be passed as the argument `accepteula` within the command line. +action.notable.param.rule_description = The following analytic identifies the execution of `PsExec.exe` with the `accepteula` flag in the command line. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line arguments. This activity is significant because PsExec is commonly used by threat actors to execute code on remote systems, and the `accepteula` flag indicates first-time usage, which could signify initial compromise. If confirmed malicious, this activity could allow attackers to gain remote code execution capabilities, potentially leading to further system compromise and lateral movement within the network. action.notable.param.rule_title = Detect PsExec With accepteula Flag action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23080,14 +22984,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Detect Rare Executables - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the occurrence of rare processes that appear only once across the network within a specified timeframe. It operates by compiling a list of process executions. This detection is crucial for a Security Operations Center (SOC) as it helps in identifying potentially malicious activities or unauthorized software that could indicate a security breach or an ongoing attack. Identifying such rare processes allows for early detection of threats, minimizing the potential impact of an attack which could range from data theft to complete system compromise. +description = The following analytic detects the execution of rare processes that appear only once across the network within a specified timeframe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant for a SOC as it helps identify potentially malicious activities or unauthorized software, which could indicate a security breach or ongoing attack. If confirmed malicious, such rare processes could lead to data theft, privilege escalation, or complete system compromise, making early detection crucial for minimizing impact. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the occurrence of rare processes that appear only once across the network within a specified timeframe. It operates by compiling a list of process executions. This detection is crucial for a Security Operations Center (SOC) as it helps in identifying potentially malicious activities or unauthorized software that could indicate a security breach or an ongoing attack. Identifying such rare processes allows for early detection of threats, minimizing the potential impact of an attack which could range from data theft to complete system compromise. +action.escu.eli5 = The following analytic detects the execution of rare processes that appear only once across the network within a specified timeframe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs. This activity is significant for a SOC as it helps identify potentially malicious activities or unauthorized software, which could indicate a security breach or ongoing attack. If confirmed malicious, such rare processes could lead to data theft, privilege escalation, or complete system compromise, making early detection crucial for minimizing impact. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Some legitimate processes may be only rarely executed in your environment. -action.escu.creation_date = 2024-03-12 -action.escu.modification_date = 2024-03-12 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Rare Executables - Rule action.escu.search_type = detection @@ -23105,7 +23009,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Rare Executables - Rule action.correlationsearch.annotations = {"analytic_story": ["Rhysida Ransomware", "Unusual Processes"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "44fddcb2-8d3b-454c-874e-7c6de5a4f7ac", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "44fddcb2-8d3b-454c-874e-7c6de5a4f7ac", "detection_version": "5"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23121,14 +23025,14 @@ search = | tstats `security_content_summariesonly` dc(Processes.dest) as dc_dest [ESCU - Detect RClone Command-Line Usage - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies commonly used command-line arguments used by `rclone.exe` to initiate a file transfer. Some arguments were negated as they are specific to the configuration used by adversaries. In particular, an adversary may list the files or directories of the remote file share using `ls` or `lsd`, which is not indicative of malicious behavior. During triage, at this stage of a ransomware event, exfiltration is about to occur or has already. Isolate the endpoint and continue investigating by review file modifications and parallel processes. +description = The following analytic detects the usage of `rclone.exe` with specific command-line arguments indicative of file transfer activities. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as `rclone.exe` is often used by adversaries for data exfiltration, especially during ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized data transfer, resulting in data breaches and potential loss of sensitive information. Immediate isolation of the affected endpoint and further investigation are recommended. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies commonly used command-line arguments used by `rclone.exe` to initiate a file transfer. Some arguments were negated as they are specific to the configuration used by adversaries. In particular, an adversary may list the files or directories of the remote file share using `ls` or `lsd`, which is not indicative of malicious behavior. During triage, at this stage of a ransomware event, exfiltration is about to occur or has already. Isolate the endpoint and continue investigating by review file modifications and parallel processes. +action.escu.eli5 = The following analytic detects the usage of `rclone.exe` with specific command-line arguments indicative of file transfer activities. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as `rclone.exe` is often used by adversaries for data exfiltration, especially during ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized data transfer, resulting in data breaches and potential loss of sensitive information. Immediate isolation of the affected endpoint and further investigation are recommended. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited as this is restricted to the Rclone process name. Filter or tune the analytic as needed. -action.escu.creation_date = 2021-11-29 -action.escu.modification_date = 2021-11-29 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect RClone Command-Line Usage - Rule action.escu.search_type = detection @@ -23146,11 +23050,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect RClone Command-Line Usage - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkSide Ransomware", "Ransomware"], "cis20": ["CIS 10"], "confidence": 70, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "32e0baea-b3f1-11eb-a2ce-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "32e0baea-b3f1-11eb-a2ce-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies commonly used command-line arguments used by `rclone.exe` to initiate a file transfer. Some arguments were negated as they are specific to the configuration used by adversaries. In particular, an adversary may list the files or directories of the remote file share using `ls` or `lsd`, which is not indicative of malicious behavior. During triage, at this stage of a ransomware event, exfiltration is about to occur or has already. Isolate the endpoint and continue investigating by review file modifications and parallel processes. +action.notable.param.rule_description = The following analytic detects the usage of `rclone.exe` with specific command-line arguments indicative of file transfer activities. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions and process details. This activity is significant as `rclone.exe` is often used by adversaries for data exfiltration, especially during ransomware attacks. If confirmed malicious, this behavior could lead to unauthorized data transfer, resulting in data breaches and potential loss of sensitive information. Immediate isolation of the affected endpoint and further investigation are recommended. action.notable.param.rule_title = Detect RClone Command-Line Usage action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23168,14 +23072,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Regasm Spawning a Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies regasm.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description = The following analytic detects regasm.exe spawning a child process. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where regasm.exe is the parent process. This activity is significant because regasm.exe spawning a process is rare and can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies regasm.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.escu.eli5 = The following analytic detects regasm.exe spawning a child process. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where regasm.exe is the parent process. This activity is significant because regasm.exe spawning a process is rare and can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2024-04-29 -action.escu.modification_date = 2024-04-29 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regasm Spawning a Process - Rule action.escu.search_type = detection @@ -23193,11 +23097,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regasm Spawning a Process - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkGate Malware", "Living Off The Land", "Snake Keylogger", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "72170ec5-f7d2-42f5-aefb-2b8be6aad15f", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "72170ec5-f7d2-42f5-aefb-2b8be6aad15f", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies regasm.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.notable.param.rule_description = The following analytic detects regasm.exe spawning a child process. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where regasm.exe is the parent process. This activity is significant because regasm.exe spawning a process is rare and can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated activities. action.notable.param.rule_title = Detect Regasm Spawning a Process action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23215,14 +23119,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Regasm with Network Connection - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies regasm.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description = The following analytic detects the execution of regasm.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon EventID 3 logs to identify such behavior. This activity is significant as regasm.exe is a legitimate Microsoft-signed binary that can be exploited to bypass application control mechanisms. If confirmed malicious, this behavior could indicate an adversary's attempt to establish a remote Command and Control (C2) channel, potentially leading to privilege escalation and further malicious actions within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies regasm.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.escu.eli5 = The following analytic detects the execution of regasm.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon EventID 3 logs to identify such behavior. This activity is significant as regasm.exe is a legitimate Microsoft-signed binary that can be exploited to bypass application control mechanisms. If confirmed malicious, this behavior could indicate an adversary's attempt to establish a remote Command and Control (C2) channel, potentially leading to privilege escalation and further malicious actions within the environment. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = Although unlikely, limited instances of regasm.exe with a network connection may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2024-01-30 -action.escu.modification_date = 2024-01-30 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regasm with Network Connection - Rule action.escu.search_type = detection @@ -23240,11 +23144,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regasm with Network Connection - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07921114-6db4-4e2e-ae58-3ea8a52ae93f", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "07921114-6db4-4e2e-ae58-3ea8a52ae93f", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies regasm.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.notable.param.rule_description = The following analytic detects the execution of regasm.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon EventID 3 logs to identify such behavior. This activity is significant as regasm.exe is a legitimate Microsoft-signed binary that can be exploited to bypass application control mechanisms. If confirmed malicious, this behavior could indicate an adversary's attempt to establish a remote Command and Control (C2) channel, potentially leading to privilege escalation and further malicious actions within the environment. action.notable.param.rule_title = Detect Regasm with Network Connection action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23262,14 +23166,14 @@ search = `sysmon` EventID=3 dest_ip!=10.0.0.0/8 dest_ip!=172.16.0.0/12 dest_ip!= [ESCU - Detect Regasm with no Command Line Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies regasm.exe with no command line arguments. This particular behavior occurs when another process injects into regasm.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`. +description = The following analytic detects instances of regasm.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regasm.exe. The detection leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line executions. This activity is significant as it may signal an attempt to evade detection or execute malicious code. If confirmed malicious, attackers could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. Investigate network connections, parallel processes, and suspicious module loads for further context. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies regasm.exe with no command line arguments. This particular behavior occurs when another process injects into regasm.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`. +action.escu.eli5 = The following analytic detects instances of regasm.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regasm.exe. The detection leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line executions. This activity is significant as it may signal an attempt to evade detection or execute malicious code. If confirmed malicious, attackers could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. Investigate network connections, parallel processes, and suspicious module loads for further context. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, limited instances of regasm.exe or may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2022-03-15 -action.escu.modification_date = 2022-03-15 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regasm with no Command Line Arguments - Rule action.escu.search_type = detection @@ -23287,11 +23191,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regasm with no Command Line Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c3bc1430-04e7-4178-835f-047d8e6e97df", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "c3bc1430-04e7-4178-835f-047d8e6e97df", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies regasm.exe with no command line arguments. This particular behavior occurs when another process injects into regasm.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`. +action.notable.param.rule_description = The following analytic detects instances of regasm.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regasm.exe. The detection leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line executions. This activity is significant as it may signal an attempt to evade detection or execute malicious code. If confirmed malicious, attackers could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. Investigate network connections, parallel processes, and suspicious module loads for further context. action.notable.param.rule_title = Detect Regasm with no Command Line Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23309,14 +23213,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Detect Regsvcs Spawning a Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies regsvcs.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description = The following analytic identifies regsvcs.exe spawning a child process. This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is regsvcs.exe. This activity is significant because regsvcs.exe rarely spawns child processes, and such behavior can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated suspicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies regsvcs.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.escu.eli5 = The following analytic identifies regsvcs.exe spawning a child process. This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is regsvcs.exe. This activity is significant because regsvcs.exe rarely spawns child processes, and such behavior can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated suspicious activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regsvcs Spawning a Process - Rule action.escu.search_type = detection @@ -23334,11 +23238,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regsvcs Spawning a Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 80, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc477b57-5c21-4ab6-9c33-668772e7f114", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "bc477b57-5c21-4ab6-9c33-668772e7f114", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies regsvcs.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.notable.param.rule_description = The following analytic identifies regsvcs.exe spawning a child process. This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is regsvcs.exe. This activity is significant because regsvcs.exe rarely spawns child processes, and such behavior can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated suspicious activities. action.notable.param.rule_title = Detect Regsvcs Spawning a Process action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23356,14 +23260,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Regsvcs with Network Connection - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies Regsvcs.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description = The following analytic identifies instances of Regsvcs.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon Event ID 3 logs to monitor network connections initiated by Regsvcs.exe. This activity is significant as Regsvcs.exe, a legitimate Microsoft-signed binary, can be exploited to bypass application control mechanisms and establish remote Command and Control (C2) channels. If confirmed malicious, this behavior could allow an attacker to escalate privileges, persist in the environment, and exfiltrate sensitive data. Immediate investigation and remediation are recommended. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies Regsvcs.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.escu.eli5 = The following analytic identifies instances of Regsvcs.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon Event ID 3 logs to monitor network connections initiated by Regsvcs.exe. This activity is significant as Regsvcs.exe, a legitimate Microsoft-signed binary, can be exploited to bypass application control mechanisms and establish remote Command and Control (C2) channels. If confirmed malicious, this behavior could allow an attacker to escalate privileges, persist in the environment, and exfiltrate sensitive data. Immediate investigation and remediation are recommended. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2024-01-30 -action.escu.modification_date = 2024-01-30 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regsvcs with Network Connection - Rule action.escu.search_type = detection @@ -23381,11 +23285,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regsvcs with Network Connection - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3e7a1c0-f2b9-445c-8493-f30a63522d1a", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "e3e7a1c0-f2b9-445c-8493-f30a63522d1a", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies Regsvcs.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.notable.param.rule_description = The following analytic identifies instances of Regsvcs.exe establishing a network connection to a public IP address, excluding private IP ranges. This detection leverages Sysmon Event ID 3 logs to monitor network connections initiated by Regsvcs.exe. This activity is significant as Regsvcs.exe, a legitimate Microsoft-signed binary, can be exploited to bypass application control mechanisms and establish remote Command and Control (C2) channels. If confirmed malicious, this behavior could allow an attacker to escalate privileges, persist in the environment, and exfiltrate sensitive data. Immediate investigation and remediation are recommended. action.notable.param.rule_title = Detect Regsvcs with Network Connection action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23403,14 +23307,14 @@ search = `sysmon` EventID=3 dest_ip!=10.0.0.0/8 dest_ip!=172.16.0.0/12 dest_ip!= [ESCU - Detect Regsvcs with No Command Line Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies regsvcs.exe with no command line arguments. This particular behavior occurs when another process injects into regsvcs.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +description = The following analytic detects instances of regsvcs.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regsvcs.exe. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, IDs, and command-line executions. This activity is significant as it may signal an attempt to evade detection and execute malicious code. If confirmed malicious, the attacker could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies regsvcs.exe with no command line arguments. This particular behavior occurs when another process injects into regsvcs.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.escu.eli5 = The following analytic detects instances of regsvcs.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regsvcs.exe. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, IDs, and command-line executions. This activity is significant as it may signal an attempt to evade detection and execute malicious code. If confirmed malicious, the attacker could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage. -action.escu.creation_date = 2022-03-15 -action.escu.modification_date = 2022-03-15 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regsvcs with No Command Line Arguments - Rule action.escu.search_type = detection @@ -23428,11 +23332,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regsvcs with No Command Line Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Regsvcs Regasm Activity"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6b74d578-a02e-4e94-a0d1-39440d0bf254", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6b74d578-a02e-4e94-a0d1-39440d0bf254", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies regsvcs.exe with no command line arguments. This particular behavior occurs when another process injects into regsvcs.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe. +action.notable.param.rule_description = The following analytic detects instances of regsvcs.exe running without command line arguments. This behavior typically indicates process injection, where another process manipulates regsvcs.exe. The detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, IDs, and command-line executions. This activity is significant as it may signal an attempt to evade detection and execute malicious code. If confirmed malicious, the attacker could achieve code execution, potentially leading to privilege escalation, persistence, or access to sensitive information. action.notable.param.rule_title = Detect Regsvcs with No Command Line Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23450,16 +23354,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Detect Regsvr32 Application Control Bypass - Rule] action.escu = 0 action.escu.enabled = 1 -description = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is often referred to as a "Squiblydoo" attack. \ -Upon investigating, look for network connections to remote destinations (internal or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon execution. +description = The following analytic identifies the abuse of Regsvr32.exe to proxy execution of malicious code, specifically detecting the loading of "scrobj.dll" by Regsvr32.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line executions. This activity is significant because Regsvr32.exe is a trusted, signed Microsoft binary, often used in "Squiblydoo" attacks to bypass application control mechanisms. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise and persistent access. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is often referred to as a "Squiblydoo" attack. \ -Upon investigating, look for network connections to remote destinations (internal or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon execution. +action.escu.eli5 = The following analytic identifies the abuse of Regsvr32.exe to proxy execution of malicious code, specifically detecting the loading of "scrobj.dll" by Regsvr32.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line executions. This activity is significant because Regsvr32.exe is a trusted, signed Microsoft binary, often used in "Squiblydoo" attacks to bypass application control mechanisms. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise and persistent access. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives related to third party software registering .DLL's. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Regsvr32 Application Control Bypass - Rule action.escu.search_type = detection @@ -23477,12 +23379,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Regsvr32 Application Control Bypass - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Cobalt Strike", "Graceful Wipe Out Attack", "Living Off The Land", "Suspicious Regsvr32 Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "070e9b80-6252-11eb-ae93-0242ac130002", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "070e9b80-6252-11eb-ae93-0242ac130002", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is often referred to as a "Squiblydoo" attack. \ -Upon investigating, look for network connections to remote destinations (internal or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon execution. +action.notable.param.rule_description = The following analytic identifies the abuse of Regsvr32.exe to proxy execution of malicious code, specifically detecting the loading of "scrobj.dll" by Regsvr32.exe. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events and command-line executions. This activity is significant because Regsvr32.exe is a trusted, signed Microsoft binary, often used in "Squiblydoo" attacks to bypass application control mechanisms. If confirmed malicious, this technique could allow an attacker to execute arbitrary code, potentially leading to system compromise and persistent access. action.notable.param.rule_title = Detect Regsvr32 Application Control Bypass action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23500,14 +23401,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Remote Access Software Usage File - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects when a file from a known remote access software is written to disk within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description = The following analytic detects the writing of files from known remote access software to disk within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on file path, file name, and user information. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration, further compromise, or complete control over affected systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects when a file from a known remote access software is written to disk within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +action.escu.eli5 = The following analytic detects the writing of files from known remote access software to disk within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on file path, file name, and user information. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration, further compromise, or complete control over affected systems. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the file path, file name, and the user that created the file. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Known or approved applications used by the organization or usage of built-in functions. -action.escu.creation_date = 2024-02-22 -action.escu.modification_date = 2024-02-22 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Remote Access Software Usage File - Rule action.escu.search_type = detection @@ -23525,7 +23426,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Remote Access Software Usage File - Rule action.correlationsearch.annotations = {"analytic_story": ["Command And Control", "Insider Threat", "Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3bf5541a-6a45-4fdc-b01d-59b899fff961", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3bf5541a-6a45-4fdc-b01d-59b899fff961", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23541,14 +23442,14 @@ search = | tstats `security_content_summariesonly` count, min(_time) as firstTim [ESCU - Detect Remote Access Software Usage FileInfo - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects when process with file or code signing attributes from a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description = The following analytic detects the execution of processes with file or code signing attributes from known remote access software within the environment. It leverages Sysmon EventCode 1 data and cross-references a lookup table of remote access utilities such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use these tools to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration or further compromise of the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic detects when process with file or code signing attributes from a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +action.escu.eli5 = The following analytic detects the execution of processes with file or code signing attributes from known remote access software within the environment. It leverages Sysmon EventCode 1 data and cross-references a lookup table of remote access utilities such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use these tools to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration or further compromise of the network. action.escu.how_to_implement = This analytic relies on Sysmon to be properly installed and utilized in the environment. Ensure that proper logging is setup for Sysmon and data is being ingested into Splunk. action.escu.known_false_positives = Known or approved applications used by the organization or usage of built-in functions. -action.escu.creation_date = 2024-02-22 -action.escu.modification_date = 2024-02-22 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Remote Access Software Usage FileInfo - Rule action.escu.search_type = detection @@ -23566,7 +23467,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Remote Access Software Usage FileInfo - Rule action.correlationsearch.annotations = {"analytic_story": ["Command And Control", "Insider Threat", "Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ccad96d7-a48c-4f13-8b9c-9f6a31cba454", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ccad96d7-a48c-4f13-8b9c-9f6a31cba454", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23582,14 +23483,14 @@ search = `sysmon` EventCode=1 | stats count min(_time) as firstTime max(_time) a [ESCU - Detect Remote Access Software Usage Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects when a known remote access software is executed within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +description = The following analytic detects the execution of known remote access software within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes mapped to the Endpoint data model. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or deploy additional malware, posing a severe threat to the organization's security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects when a known remote access software is executed within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others. +action.escu.eli5 = The following analytic detects the execution of known remote access software within the environment. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes mapped to the Endpoint data model. This activity is significant as adversaries often use remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer to maintain unauthorized access. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or deploy additional malware, posing a severe threat to the organization's security. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. -action.escu.creation_date = 2024-02-22 -action.escu.modification_date = 2024-02-22 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Remote Access Software Usage Process - Rule action.escu.search_type = detection @@ -23607,7 +23508,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Remote Access Software Usage Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Command And Control", "Insider Threat", "Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ffd5e001-2e34-48f4-97a2-26dc4bb08178", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ffd5e001-2e34-48f4-97a2-26dc4bb08178", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23623,14 +23524,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Renamed 7-Zip - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies renamed 7-Zip usage using Sysmon. At this stage of an attack, review parallel processes and file modifications for data that is staged or potentially have been exfiltrated. This analytic utilizes the OriginalFileName to capture the renamed process. During triage, validate this is the legitimate version of `7zip` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +description = The following analytic detects the usage of a renamed 7-Zip executable using Sysmon data. It leverages the OriginalFileName field to identify instances where the 7-Zip process has been renamed. This activity is significant as attackers often rename legitimate tools to evade detection while staging or exfiltrating data. If confirmed malicious, this behavior could indicate data exfiltration attempts or other unauthorized data manipulation, potentially leading to significant data breaches or loss of sensitive information. Analysts should validate the legitimacy of the 7-Zip executable and investigate parallel processes for further suspicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies renamed 7-Zip usage using Sysmon. At this stage of an attack, review parallel processes and file modifications for data that is staged or potentially have been exfiltrated. This analytic utilizes the OriginalFileName to capture the renamed process. During triage, validate this is the legitimate version of `7zip` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +action.escu.eli5 = The following analytic detects the usage of a renamed 7-Zip executable using Sysmon data. It leverages the OriginalFileName field to identify instances where the 7-Zip process has been renamed. This activity is significant as attackers often rename legitimate tools to evade detection while staging or exfiltrating data. If confirmed malicious, this behavior could indicate data exfiltration attempts or other unauthorized data manipulation, potentially leading to significant data breaches or loss of sensitive information. Analysts should validate the legitimacy of the 7-Zip executable and investigate parallel processes for further suspicious activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives, however this analytic will need to be modified for each environment if Sysmon is not used. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Renamed 7-Zip - Rule action.escu.search_type = detection @@ -23643,7 +23544,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Renamed 7-Zip - Rule action.correlationsearch.annotations = {"analytic_story": ["Collection and Staging"], "cis20": ["CIS 10"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4057291a-b8cf-11eb-95fe-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4057291a-b8cf-11eb-95fe-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23659,14 +23560,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Renamed PSExec - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies renamed instances of `PsExec.exe` being utilized on an endpoint. Most instances, it is highly probable to capture `Psexec.exe` or other SysInternal utility usage with the command-line argument of `-accepteula`. During triage, validate this is the legitimate version of `PsExec` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +description = The following analytic identifies instances where `PsExec.exe` has been renamed and executed on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because renaming `PsExec.exe` is a common tactic to evade detection. If confirmed malicious, this could allow an attacker to execute commands remotely, potentially leading to unauthorized access, lateral movement, or further compromise of the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies renamed instances of `PsExec.exe` being utilized on an endpoint. Most instances, it is highly probable to capture `Psexec.exe` or other SysInternal utility usage with the command-line argument of `-accepteula`. During triage, validate this is the legitimate version of `PsExec` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior. +action.escu.eli5 = The following analytic identifies instances where `PsExec.exe` has been renamed and executed on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names. This activity is significant because renaming `PsExec.exe` is a common tactic to evade detection. If confirmed malicious, this could allow an attacker to execute commands remotely, potentially leading to unauthorized access, lateral movement, or further compromise of the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives should be present. It is possible some third party applications may use older versions of PsExec, filter as needed. -action.escu.creation_date = 2022-04-07 -action.escu.modification_date = 2022-04-07 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Renamed PSExec - Rule action.escu.search_type = detection @@ -23679,7 +23580,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Renamed PSExec - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Lateral Movement", "BlackByte Ransomware", "CISA AA22-320A", "DHS Report TA18-074A", "DarkGate Malware", "DarkSide Ransomware", "HAFNIUM Group", "Rhysida Ransomware", "SamSam Ransomware", "Sandworm Tools"], "cis20": ["CIS 10"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "683e6196-b8e8-11eb-9a79-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "683e6196-b8e8-11eb-9a79-acde48001122", "detection_version": "5"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23695,14 +23596,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Renamed RClone - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the usage of `rclone.exe`, renamed, being used to exfiltrate data to a remote destination. RClone has been used by multiple ransomware groups to exfiltrate data. In many instances, it will be downloaded from the legitimate site and executed accordingly. During triage, isolate the endpoint and begin to review parallel processes for additional behavior. At this stage, the adversary may have staged data to be exfiltrated. +description = The following analytic detects the execution of a renamed `rclone.exe` process, which is commonly used for data exfiltration to remote destinations. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and original file names that do not match. This activity is significant because ransomware groups often use RClone to exfiltrate sensitive data. If confirmed malicious, this behavior could indicate an ongoing data exfiltration attempt, potentially leading to significant data loss and further compromise of the affected systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the usage of `rclone.exe`, renamed, being used to exfiltrate data to a remote destination. RClone has been used by multiple ransomware groups to exfiltrate data. In many instances, it will be downloaded from the legitimate site and executed accordingly. During triage, isolate the endpoint and begin to review parallel processes for additional behavior. At this stage, the adversary may have staged data to be exfiltrated. +action.escu.eli5 = The following analytic detects the execution of a renamed `rclone.exe` process, which is commonly used for data exfiltration to remote destinations. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and original file names that do not match. This activity is significant because ransomware groups often use RClone to exfiltrate sensitive data. If confirmed malicious, this behavior could indicate an ongoing data exfiltration attempt, potentially leading to significant data loss and further compromise of the affected systems. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited as this analytic identifies renamed instances of `rclone.exe`. Filter as needed if there is a legitimate business use case. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Renamed RClone - Rule action.escu.search_type = detection @@ -23715,7 +23616,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Renamed RClone - Rule action.correlationsearch.annotations = {"analytic_story": ["DarkSide Ransomware", "Ransomware"], "cis20": ["CIS 10"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6dca1124-b3ec-11eb-9328-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6dca1124-b3ec-11eb-9328-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23731,14 +23632,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Renamed WinRAR - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analtyic identifies renamed instances of `WinRAR.exe`. In most cases, it is not common for WinRAR to be used renamed, however it is common to be installed by a third party application and executed from a non-standard path. During triage, validate additional metadata from the binary that this is `WinRAR`. Review parallel processes and file modifications. +description = The following analytic identifies instances where `WinRAR.exe` has been renamed and executed. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names within the Endpoint data model. This activity is significant because renaming executables is a common tactic used by attackers to evade detection. If confirmed malicious, this could indicate an attempt to bypass security controls, potentially leading to unauthorized data extraction or further system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analtyic identifies renamed instances of `WinRAR.exe`. In most cases, it is not common for WinRAR to be used renamed, however it is common to be installed by a third party application and executed from a non-standard path. During triage, validate additional metadata from the binary that this is `WinRAR`. Review parallel processes and file modifications. +action.escu.eli5 = The following analytic identifies instances where `WinRAR.exe` has been renamed and executed. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and original file names within the Endpoint data model. This activity is significant because renaming executables is a common tactic used by attackers to evade detection. If confirmed malicious, this could indicate an attempt to bypass security controls, potentially leading to unauthorized data extraction or further system compromise. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Unknown. It is possible third party applications use renamed instances of WinRAR. -action.escu.creation_date = 2021-09-16 -action.escu.modification_date = 2021-09-16 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Renamed WinRAR - Rule action.escu.search_type = detection @@ -23751,7 +23652,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Renamed WinRAR - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-277A", "Collection and Staging"], "cis20": ["CIS 10"], "confidence": 90, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1b7bfb2c-b8e6-11eb-99ac-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1b7bfb2c-b8e6-11eb-99ac-acde48001122", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -23767,14 +23668,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect RTLO In File Name - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +description = The following analytic identifies the use of the right-to-left override (RTLO) character in file names. It leverages data from the Endpoint.Filesystem datamodel, specifically focusing on file creation events and file names containing the RTLO character (U+202E). This activity is significant because adversaries use RTLO to disguise malicious files as benign by reversing the text that follows the character. If confirmed malicious, this technique can deceive users and security tools, leading to the execution of harmful files and potential system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +action.escu.eli5 = The following analytic identifies the use of the right-to-left override (RTLO) character in file names. It leverages data from the Endpoint.Filesystem datamodel, specifically focusing on file creation events and file names containing the RTLO character (U+202E). This activity is significant because adversaries use RTLO to disguise malicious files as benign by reversing the text that follows the character. If confirmed malicious, this technique can deceive users and security tools, leading to the execution of harmful files and potential system compromise. action.escu.how_to_implement = To successfully implement this search you need to be ingesting information on process that includes the full command line of the process being launched on your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. action.escu.known_false_positives = Implementation in regions that use right to left in native language. -action.escu.creation_date = 2023-04-26 -action.escu.modification_date = 2023-04-26 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect RTLO In File Name - Rule action.escu.search_type = detection @@ -23792,11 +23693,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect RTLO In File Name - Rule action.correlationsearch.annotations = {"analytic_story": ["Spearphishing Attachments"], "cis20": ["CIS 10"], "confidence": 80, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "468b7e11-d362-43b8-b6ec-7a2d3b246678", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "468b7e11-d362-43b8-b6ec-7a2d3b246678", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +action.notable.param.rule_description = The following analytic identifies the use of the right-to-left override (RTLO) character in file names. It leverages data from the Endpoint.Filesystem datamodel, specifically focusing on file creation events and file names containing the RTLO character (U+202E). This activity is significant because adversaries use RTLO to disguise malicious files as benign by reversing the text that follows the character. If confirmed malicious, this technique can deceive users and security tools, leading to the execution of harmful files and potential system compromise. action.notable.param.rule_title = Detect RTLO In File Name action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23814,14 +23715,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect RTLO In Process - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +description = The following analytic identifies the abuse of the right-to-left override (RTLO) character (U+202E) in process names. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line data. This activity is significant because adversaries use the RTLO character to disguise malicious files or commands, making them appear benign. If confirmed malicious, this technique can allow attackers to execute harmful code undetected, potentially leading to unauthorized access, data exfiltration, or further system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +action.escu.eli5 = The following analytic identifies the abuse of the right-to-left override (RTLO) character (U+202E) in process names. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line data. This activity is significant because adversaries use the RTLO character to disguise malicious files or commands, making them appear benign. If confirmed malicious, this technique can allow attackers to execute harmful code undetected, potentially leading to unauthorized access, data exfiltration, or further system compromise. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Implementation in regions that use right to left in native language. -action.escu.creation_date = 2023-04-26 -action.escu.modification_date = 2023-04-26 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect RTLO In Process - Rule action.escu.search_type = detection @@ -23839,11 +23740,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect RTLO In Process - Rule action.correlationsearch.annotations = {"analytic_story": ["Spearphishing Attachments"], "cis20": ["CIS 10"], "confidence": 80, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "22ac27b4-7189-4a4f-9375-b9017c9620d7", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "22ac27b4-7189-4a4f-9375-b9017c9620d7", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. +action.notable.param.rule_description = The following analytic identifies the abuse of the right-to-left override (RTLO) character (U+202E) in process names. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs and command-line data. This activity is significant because adversaries use the RTLO character to disguise malicious files or commands, making them appear benign. If confirmed malicious, this technique can allow attackers to execute harmful code undetected, potentially leading to unauthorized access, data exfiltration, or further system compromise. action.notable.param.rule_title = Detect RTLO In Process action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23861,14 +23762,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies rundll32.exe loading advpack.dll and ieadvpack.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +description = The following analytic detects the execution of rundll32.exe loading advpack.dll or ieadvpack.dll via the LaunchINFSection function. This method is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate script content, network connections, and any spawned child processes for further context. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies rundll32.exe loading advpack.dll and ieadvpack.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.escu.eli5 = The following analytic detects the execution of rundll32.exe loading advpack.dll or ieadvpack.dll via the LaunchINFSection function. This method is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate script content, network connections, and any spawned child processes for further context. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may use advpack.dll or ieadvpack.dll, triggering a false positive. -action.escu.creation_date = 2021-02-04 -action.escu.modification_date = 2021-02-04 +action.escu.creation_date = 2024-05-17 +action.escu.modification_date = 2024-05-17 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule action.escu.search_type = detection @@ -23886,11 +23787,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Rundll32 Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4aefadfe-9abd-4bf8-b3fd-867e9ef95bf8", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "4aefadfe-9abd-4bf8-b3fd-867e9ef95bf8", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies rundll32.exe loading advpack.dll and ieadvpack.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.notable.param.rule_description = The following analytic detects the execution of rundll32.exe loading advpack.dll or ieadvpack.dll via the LaunchINFSection function. This method is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate script content, network connections, and any spawned child processes for further context. action.notable.param.rule_title = Detect Rundll32 Application Control Bypass - advpack action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23908,14 +23809,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies rundll32.exe loading setupapi.dll and iesetupapi.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +description = The following analytic detects the execution of rundll32.exe loading setupapi.dll and iesetupapi.dll via the LaunchINFSection function. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events and command-line arguments. This activity is significant as it indicates a potential application control bypass, allowing an attacker to execute arbitrary script code. If confirmed malicious, this technique could enable code execution, privilege escalation, or persistence within the environment, posing a severe threat to system integrity and security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies rundll32.exe loading setupapi.dll and iesetupapi.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.escu.eli5 = The following analytic detects the execution of rundll32.exe loading setupapi.dll and iesetupapi.dll via the LaunchINFSection function. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events and command-line arguments. This activity is significant as it indicates a potential application control bypass, allowing an attacker to execute arbitrary script code. If confirmed malicious, this technique could enable code execution, privilege escalation, or persistence within the environment, posing a severe threat to system integrity and security. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may use setupapi triggering a false positive. -action.escu.creation_date = 2021-02-04 -action.escu.modification_date = 2021-02-04 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule action.escu.search_type = detection @@ -23933,11 +23834,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Rundll32 Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "61e7b44a-6088-4f26-b788-9a96ba13b37a", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "61e7b44a-6088-4f26-b788-9a96ba13b37a", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies rundll32.exe loading setupapi.dll and iesetupapi.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.notable.param.rule_description = The following analytic detects the execution of rundll32.exe loading setupapi.dll and iesetupapi.dll via the LaunchINFSection function. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events and command-line arguments. This activity is significant as it indicates a potential application control bypass, allowing an attacker to execute arbitrary script code. If confirmed malicious, this technique could enable code execution, privilege escalation, or persistence within the environment, posing a severe threat to system integrity and security. action.notable.param.rule_title = Detect Rundll32 Application Control Bypass - setupapi action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -23955,14 +23856,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies rundll32.exe loading syssetup.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +description = The following analytic detects the execution of rundll32.exe loading syssetup.dll via the LaunchINFSection function. This method is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate the script content, network connections, and any spawned child processes for further context. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies rundll32.exe loading syssetup.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.escu.eli5 = The following analytic detects the execution of rundll32.exe loading syssetup.dll via the LaunchINFSection function. This method is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate the script content, network connections, and any spawned child processes for further context. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may use syssetup.dll, triggering a false positive. -action.escu.creation_date = 2021-02-04 -action.escu.modification_date = 2021-02-04 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule action.escu.search_type = detection @@ -23980,11 +23881,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "Suspicious Rundll32 Activity"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71b9bf37-cde1-45fb-b899-1b0aa6fa1183", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "71b9bf37-cde1-45fb-b899-1b0aa6fa1183", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies rundll32.exe loading syssetup.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk. +action.notable.param.rule_description = The following analytic detects the execution of rundll32.exe loading syssetup.dll via the LaunchINFSection function. This method is identified through Endpoint Detection and Response (EDR) telemetry, focusing on command-line executions and process details. This activity is significant as it indicates a potential application control bypass, allowing script code execution from a file. If confirmed malicious, an attacker could execute arbitrary code, potentially leading to privilege escalation, persistence, or further network compromise. Investigate the script content, network connections, and any spawned child processes for further context. action.notable.param.rule_title = Detect Rundll32 Application Control Bypass - syssetup action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24002,14 +23903,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Rundll32 Inline HTA Execution - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies "rundll32.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. This type of behavior is commonly observed with fileless malware or application whitelisting bypass techniques. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +description = The following analytic detects the execution of "rundll32.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line arguments. This activity is significant as it is often associated with fileless malware or application whitelisting bypass techniques. If confirmed malicious, this could allow an attacker to execute arbitrary code, bypass security controls, and maintain persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies "rundll32.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. This type of behavior is commonly observed with fileless malware or application whitelisting bypass techniques. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +action.escu.eli5 = The following analytic detects the execution of "rundll32.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line arguments. This activity is significant as it is often associated with fileless malware or application whitelisting bypass techniques. If confirmed malicious, this could allow an attacker to execute arbitrary code, bypass security controls, and maintain persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive. -action.escu.creation_date = 2021-01-20 -action.escu.modification_date = 2021-01-20 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Rundll32 Inline HTA Execution - Rule action.escu.search_type = detection @@ -24027,11 +23928,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Rundll32 Inline HTA Execution - Rule action.correlationsearch.annotations = {"analytic_story": ["Living Off The Land", "NOBELIUM Group", "Suspicious MSHTA Activity"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "91c79f14-5b41-11eb-ae93-0242ac130002", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "91c79f14-5b41-11eb-ae93-0242ac130002", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies "rundll32.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. This type of behavior is commonly observed with fileless malware or application whitelisting bypass techniques. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process. +action.notable.param.rule_description = The following analytic detects the execution of "rundll32.exe" with inline protocol handlers such as "JavaScript", "VBScript", and "About". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on command-line arguments. This activity is significant as it is often associated with fileless malware or application whitelisting bypass techniques. If confirmed malicious, this could allow an attacker to execute arbitrary code, bypass security controls, and maintain persistence within the environment. action.notable.param.rule_title = Detect Rundll32 Inline HTA Execution action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24049,14 +23950,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Detect SharpHound Command-Line Arguments - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies common command-line arguments used by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +description = The following analytic detects the execution of SharpHound command-line arguments, specifically `-collectionMethod` and `invoke-bloodhound`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as SharpHound is commonly used for Active Directory enumeration, which can be a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially compromising sensitive information and critical systems. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies common command-line arguments used by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +action.escu.eli5 = The following analytic detects the execution of SharpHound command-line arguments, specifically `-collectionMethod` and `invoke-bloodhound`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as SharpHound is commonly used for Active Directory enumeration, which can be a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially compromising sensitive information and critical systems. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited as the arguments used are specific to SharpHound. Filter as needed or add more command-line arguments as needed. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect SharpHound Command-Line Arguments - Rule action.escu.search_type = detection @@ -24074,11 +23975,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect SharpHound Command-Line Arguments - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware", "Windows Discovery Techniques"], "cis20": ["CIS 10"], "confidence": 80, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a0bdd2f6-c2ff-11eb-b918-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a0bdd2f6-c2ff-11eb-b918-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies common command-line arguments used by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives. +action.notable.param.rule_description = The following analytic detects the execution of SharpHound command-line arguments, specifically `-collectionMethod` and `invoke-bloodhound`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as SharpHound is commonly used for Active Directory enumeration, which can be a precursor to lateral movement or privilege escalation. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially compromising sensitive information and critical systems. action.notable.param.rule_title = Detect SharpHound Command-Line Arguments action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24096,14 +23997,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect SharpHound File Modifications - Rule] action.escu = 0 action.escu.enabled = 1 -description = SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. SharpHound will query the domain controller and begin gathering all the data related to the domain and trusts. For output, it will drop a .zip file upon completion following a typical pattern that is often not changed. This analytic focuses on the default file name scheme. Note that this may be evaded with different parameters within SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` are two examples. In addition, executing SharpHound via .exe or .ps1 without any command-line arguments will still perform activity and dump output to the default filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates multiple temp files following the same pattern `20210601182121_computers.json`, `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, or remove these json's entirely if it is too noisy. During traige, review parallel processes for further suspicious behavior. Typically, the process executing the `.ps1` ingestor will be PowerShell. +description = The following analytic detects the creation of files typically associated with SharpHound, a reconnaissance tool used for gathering domain and trust data. It leverages file modification events from the Endpoint.Filesystem data model, focusing on default file naming patterns like `*_BloodHound.zip` and various JSON files. This activity is significant as it indicates potential domain enumeration, which is a precursor to more targeted attacks. If confirmed malicious, an attacker could gain detailed insights into the domain structure, facilitating lateral movement and privilege escalation. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. SharpHound will query the domain controller and begin gathering all the data related to the domain and trusts. For output, it will drop a .zip file upon completion following a typical pattern that is often not changed. This analytic focuses on the default file name scheme. Note that this may be evaded with different parameters within SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` are two examples. In addition, executing SharpHound via .exe or .ps1 without any command-line arguments will still perform activity and dump output to the default filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates multiple temp files following the same pattern `20210601182121_computers.json`, `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, or remove these json's entirely if it is too noisy. During traige, review parallel processes for further suspicious behavior. Typically, the process executing the `.ps1` ingestor will be PowerShell. +action.escu.eli5 = The following analytic detects the creation of files typically associated with SharpHound, a reconnaissance tool used for gathering domain and trust data. It leverages file modification events from the Endpoint.Filesystem data model, focusing on default file naming patterns like `*_BloodHound.zip` and various JSON files. This activity is significant as it indicates potential domain enumeration, which is a precursor to more targeted attacks. If confirmed malicious, an attacker could gain detailed insights into the domain structure, facilitating lateral movement and privilege escalation. action.escu.how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. action.escu.known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect SharpHound File Modifications - Rule action.escu.search_type = detection @@ -24121,11 +24022,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect SharpHound File Modifications - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware", "Windows Discovery Techniques"], "cis20": ["CIS 10"], "confidence": 80, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "42b4b438-beed-11eb-ba1d-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "42b4b438-beed-11eb-ba1d-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. SharpHound will query the domain controller and begin gathering all the data related to the domain and trusts. For output, it will drop a .zip file upon completion following a typical pattern that is often not changed. This analytic focuses on the default file name scheme. Note that this may be evaded with different parameters within SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` are two examples. In addition, executing SharpHound via .exe or .ps1 without any command-line arguments will still perform activity and dump output to the default filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates multiple temp files following the same pattern `20210601182121_computers.json`, `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, or remove these json's entirely if it is too noisy. During traige, review parallel processes for further suspicious behavior. Typically, the process executing the `.ps1` ingestor will be PowerShell. +action.notable.param.rule_description = The following analytic detects the creation of files typically associated with SharpHound, a reconnaissance tool used for gathering domain and trust data. It leverages file modification events from the Endpoint.Filesystem data model, focusing on default file naming patterns like `*_BloodHound.zip` and various JSON files. This activity is significant as it indicates potential domain enumeration, which is a precursor to more targeted attacks. If confirmed malicious, an attacker could gain detailed insights into the domain structure, facilitating lateral movement and privilege escalation. action.notable.param.rule_title = Detect SharpHound File Modifications action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24143,14 +24044,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect SharpHound Usage - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies SharpHound binary usage by using the original filena,e. In addition to renaming the PE, other coverage is available to detect command-line arguments. This particular analytic looks for the original_file_name of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe have different original filenames. Dependent upon the operator, the code may be re-compiled and the attributes removed or changed to anything else. During triage, review the metadata of the binary in question. Review parallel processes for suspicious behavior. Identify the source of this binary. +description = The following analytic detects the usage of the SharpHound binary by identifying its original filename, `SharpHound.exe`, and the process name. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process metadata and command-line executions. SharpHound is a tool used for Active Directory enumeration, often by attackers during the reconnaissance phase. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially leading to privilege escalation and lateral movement within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies SharpHound binary usage by using the original filena,e. In addition to renaming the PE, other coverage is available to detect command-line arguments. This particular analytic looks for the original_file_name of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe have different original filenames. Dependent upon the operator, the code may be re-compiled and the attributes removed or changed to anything else. During triage, review the metadata of the binary in question. Review parallel processes for suspicious behavior. Identify the source of this binary. +action.escu.eli5 = The following analytic detects the usage of the SharpHound binary by identifying its original filename, `SharpHound.exe`, and the process name. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process metadata and command-line executions. SharpHound is a tool used for Active Directory enumeration, often by attackers during the reconnaissance phase. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially leading to privilege escalation and lateral movement within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited as this is specific to a file attribute not used by anything else. Filter as needed. -action.escu.creation_date = 2024-03-14 -action.escu.modification_date = 2024-03-14 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect SharpHound Usage - Rule action.escu.search_type = detection @@ -24168,11 +24069,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect SharpHound Usage - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware", "Windows Discovery Techniques"], "cis20": ["CIS 10"], "confidence": 80, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dd04b29a-beed-11eb-87bc-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dd04b29a-beed-11eb-87bc-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies SharpHound binary usage by using the original filena,e. In addition to renaming the PE, other coverage is available to detect command-line arguments. This particular analytic looks for the original_file_name of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe have different original filenames. Dependent upon the operator, the code may be re-compiled and the attributes removed or changed to anything else. During triage, review the metadata of the binary in question. Review parallel processes for suspicious behavior. Identify the source of this binary. +action.notable.param.rule_description = The following analytic detects the usage of the SharpHound binary by identifying its original filename, `SharpHound.exe`, and the process name. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process metadata and command-line executions. SharpHound is a tool used for Active Directory enumeration, often by attackers during the reconnaissance phase. If confirmed malicious, this activity could allow an attacker to map out the network, identify high-value targets, and plan further attacks, potentially leading to privilege escalation and lateral movement within the environment. action.notable.param.rule_title = Detect SharpHound Usage action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24190,14 +24091,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect suspicious processnames using pretrained model in DSDL - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic uses a pre-trained Deep Learning model to predict whether a processname is suspicious or not. Malwares and malicious programs such as ransomware often use tactics, techniques, and procedures (TTPs) such as copying malicious files to the local machine to propagate themselves across the network. A key indicator of compromise is that after a successful execution of the malware, it copies itself as an executable file with a randomly generated filename and places this file in one of the directories. Such techniques are seen in several malwares such as TrickBot. We develop machine learning model that uses a Recurrent Neural Network (RNN) to distinguish between malicious and benign processnames. The model is trained independently and is then made available for download. We use a character level RNN to classify malicious vs. benign processnames. The higher is_malicious_prob, the more likely is the processname to be suspicious (between [0,1]). The threshold for flagging a processname as suspicious is set as 0.5. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies suspicious process names using a pre-trained Deep Learning model. It leverages Endpoint Detection and Response (EDR) telemetry to analyze process names and predict their likelihood of being malicious. The model, a character-level Recurrent Neural Network (RNN), classifies process names as benign or suspicious based on a threshold score of 0.5. This detection is significant as it helps identify malware, such as TrickBot, which often uses randomly generated filenames to evade detection. If confirmed malicious, this activity could indicate the presence of malware capable of propagating across the network and executing harmful actions. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic uses a pre-trained Deep Learning model to predict whether a processname is suspicious or not. Malwares and malicious programs such as ransomware often use tactics, techniques, and procedures (TTPs) such as copying malicious files to the local machine to propagate themselves across the network. A key indicator of compromise is that after a successful execution of the malware, it copies itself as an executable file with a randomly generated filename and places this file in one of the directories. Such techniques are seen in several malwares such as TrickBot. We develop machine learning model that uses a Recurrent Neural Network (RNN) to distinguish between malicious and benign processnames. The model is trained independently and is then made available for download. We use a character level RNN to classify malicious vs. benign processnames. The higher is_malicious_prob, the more likely is the processname to be suspicious (between [0,1]). The threshold for flagging a processname as suspicious is set as 0.5. +action.escu.eli5 = The following analytic identifies suspicious process names using a pre-trained Deep Learning model. It leverages Endpoint Detection and Response (EDR) telemetry to analyze process names and predict their likelihood of being malicious. The model, a character-level Recurrent Neural Network (RNN), classifies process names as benign or suspicious based on a threshold score of 0.5. This detection is significant as it helps identify malware, such as TrickBot, which often uses randomly generated filenames to evade detection. If confirmed malicious, this activity could indicate the presence of malware capable of propagating across the network and executing harmful actions. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives may be present if a suspicious processname is similar to a benign processname. -action.escu.creation_date = 2023-01-23 -action.escu.modification_date = 2023-01-23 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect suspicious processnames using pretrained model in DSDL - Rule action.escu.search_type = detection @@ -24215,7 +24116,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Detect suspicious processnames using pretrained model in DSDL - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious Command-Line Executions"], "cis20": ["CIS 10"], "confidence": 90, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a15f8977-ad7d-4669-92ef-b59b97219bf5", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a15f8977-ad7d-4669-92ef-b59b97219bf5", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -24231,14 +24132,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for the execution of the cscript.exe or wscript.exe processes, with a parent of cmd.exe. The search will return the count, the first and last time this execution was seen on a machine, the user, and the destination of the machine +description = The following analytic detects the execution of cscript.exe or wscript.exe processes initiated by cmd.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes within the Endpoint data model. This activity is significant as it may indicate script-based attacks or administrative actions that could be leveraged for malicious purposes. If confirmed malicious, this behavior could allow attackers to execute scripts, potentially leading to code execution, privilege escalation, or persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search looks for the execution of the cscript.exe or wscript.exe processes, with a parent of cmd.exe. The search will return the count, the first and last time this execution was seen on a machine, the user, and the destination of the machine +action.escu.eli5 = The following analytic detects the execution of cscript.exe or wscript.exe processes initiated by cmd.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes within the Endpoint data model. This activity is significant as it may indicate script-based attacks or administrative actions that could be leveraged for malicious purposes. If confirmed malicious, this behavior could allow attackers to execute scripts, potentially leading to code execution, privilege escalation, or persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = This detection may also be triggered by legitimate applications and numerous service accounts, which often end with a $ sign. To manage this, it's advised to check the service account's activities and, if they are valid, modify the filter macro to exclude them. -action.escu.creation_date = 2023-12-07 -action.escu.modification_date = 2023-12-07 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule action.escu.search_type = detection @@ -24256,11 +24157,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Emotet Malware DHS Report TA18-201A", "Suspicious Command-Line Executions"], "cis20": ["CIS 10"], "confidence": 50, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b89919ed-fe5f-492c-b139-95dbb162039e", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b89919ed-fe5f-492c-b139-95dbb162039e", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for the execution of the cscript.exe or wscript.exe processes, with a parent of cmd.exe. The search will return the count, the first and last time this execution was seen on a machine, the user, and the destination of the machine +action.notable.param.rule_description = The following analytic detects the execution of cscript.exe or wscript.exe processes initiated by cmd.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and parent processes within the Endpoint data model. This activity is significant as it may indicate script-based attacks or administrative actions that could be leveraged for malicious purposes. If confirmed malicious, this behavior could allow attackers to execute scripts, potentially leading to code execution, privilege escalation, or persistence within the environment. action.notable.param.rule_title = Detect Use of cmd exe to Launch Script Interpreters action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24278,14 +24179,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Detect Webshell Exploit Behavior - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is used to detect the abuse of web applications by adversaries. Adversaries may install a backdoor or script onto web servers by exploiting known vulnerabilities or misconfigruations. Web shells are used to establish persistent access to systems and provide a set of executable functions or a command-line interface on the system hosting the Web server. +description = The following analytic identifies the execution of suspicious processes typically associated with webshell activity on web servers. It detects when processes like `cmd.exe`, `powershell.exe`, or `bash.exe` are spawned by web server processes such as `w3wp.exe` or `nginx.exe`. This behavior is significant as it may indicate an adversary exploiting a web application vulnerability to install a webshell, providing persistent access and command execution capabilities. If confirmed malicious, this activity could allow attackers to maintain control over the compromised server, execute arbitrary commands, and potentially escalate privileges or exfiltrate sensitive data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is used to detect the abuse of web applications by adversaries. Adversaries may install a backdoor or script onto web servers by exploiting known vulnerabilities or misconfigruations. Web shells are used to establish persistent access to systems and provide a set of executable functions or a command-line interface on the system hosting the Web server. +action.escu.eli5 = The following analytic identifies the execution of suspicious processes typically associated with webshell activity on web servers. It detects when processes like `cmd.exe`, `powershell.exe`, or `bash.exe` are spawned by web server processes such as `w3wp.exe` or `nginx.exe`. This behavior is significant as it may indicate an adversary exploiting a web application vulnerability to install a webshell, providing persistent access and command execution capabilities. If confirmed malicious, this activity could allow attackers to maintain control over the compromised server, execute arbitrary commands, and potentially escalate privileges or exfiltrate sensitive data. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Legitimate OS functions called by vendor applications, baseline the environment and filter before enabling. Recommend throttle by dest/process_name -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect Webshell Exploit Behavior - Rule action.escu.search_type = detection @@ -24303,11 +24204,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect Webshell Exploit Behavior - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "CISA AA22-257A", "CISA AA22-264A", "Citrix ShareFile RCE CVE-2023-24489", "Flax Typhoon", "HAFNIUM Group", "ProxyNotShell", "ProxyShell", "SysAid On-Prem Software CVE-2023-47246 Vulnerability", "WS FTP Server Critical Vulnerabilities"], "cis20": ["CIS 10"], "confidence": 80, "impact": 100, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "22597426-6dbd-49bd-bcdc-4ec19857192f", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "22597426-6dbd-49bd-bcdc-4ec19857192f", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is used to detect the abuse of web applications by adversaries. Adversaries may install a backdoor or script onto web servers by exploiting known vulnerabilities or misconfigruations. Web shells are used to establish persistent access to systems and provide a set of executable functions or a command-line interface on the system hosting the Web server. +action.notable.param.rule_description = The following analytic identifies the execution of suspicious processes typically associated with webshell activity on web servers. It detects when processes like `cmd.exe`, `powershell.exe`, or `bash.exe` are spawned by web server processes such as `w3wp.exe` or `nginx.exe`. This behavior is significant as it may indicate an adversary exploiting a web application vulnerability to install a webshell, providing persistent access and command execution capabilities. If confirmed malicious, this activity could allow attackers to maintain control over the compromised server, execute arbitrary commands, and potentially escalate privileges or exfiltrate sensitive data. action.notable.param.rule_title = Detect Webshell Exploit Behavior action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24325,24 +24226,14 @@ search = | tstats `security_content_summariesonly` count max(_time) as lastTime, [ESCU - Detect WMI Event Subscription Persistence - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. \ -All event subscriptions have three components \ -1. Filter - WQL Query for the events we want. EventID equals 19 \ -1. Consumer - An action to take upon triggering the filter. EventID equals 20 \ -1. Binding - Registers a filter to a consumer. EventID equals 21 \ -Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. +description = The following analytic identifies the creation of WMI Event Subscriptions, which can be used to establish persistence or perform privilege escalation. It detects EventID 19 (EventFilter creation), EventID 20 (EventConsumer creation), and EventID 21 (FilterToConsumerBinding creation) from Sysmon logs. This activity is significant because WMI Event Subscriptions can execute code with elevated SYSTEM privileges, making it a powerful persistence mechanism. If confirmed malicious, an attacker could maintain long-term access, escalate privileges, and execute arbitrary code, posing a severe threat to the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. \ -All event subscriptions have three components \ -1. Filter - WQL Query for the events we want. EventID equals 19 \ -1. Consumer - An action to take upon triggering the filter. EventID equals 20 \ -1. Binding - Registers a filter to a consumer. EventID equals 21 \ -Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. +action.escu.eli5 = The following analytic identifies the creation of WMI Event Subscriptions, which can be used to establish persistence or perform privilege escalation. It detects EventID 19 (EventFilter creation), EventID 20 (EventConsumer creation), and EventID 21 (FilterToConsumerBinding creation) from Sysmon logs. This activity is significant because WMI Event Subscriptions can execute code with elevated SYSTEM privileges, making it a powerful persistence mechanism. If confirmed malicious, an attacker could maintain long-term access, escalate privileges, and execute arbitrary code, posing a severe threat to the environment. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with that provide WMI Event Subscription from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA and have enabled EventID 19, 20 and 21. Tune and filter known good to limit the volume. action.escu.known_false_positives = It is possible some applications will create a consumer and may be required to be filtered. For tuning, add any additional LOLBin's for further depth of coverage. -action.escu.creation_date = 2021-06-16 -action.escu.modification_date = 2021-06-16 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Detect WMI Event Subscription Persistence - Rule action.escu.search_type = detection @@ -24360,16 +24251,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Detect WMI Event Subscription Persistence - Rule action.correlationsearch.annotations = {"analytic_story": ["Suspicious WMI Use"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01d9a0c2-cece-11eb-ab46-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "01d9a0c2-cece-11eb-ab46-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. \ -All event subscriptions have three components \ -1. Filter - WQL Query for the events we want. EventID equals 19 \ -1. Consumer - An action to take upon triggering the filter. EventID equals 20 \ -1. Binding - Registers a filter to a consumer. EventID equals 21 \ -Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. +action.notable.param.rule_description = The following analytic identifies the creation of WMI Event Subscriptions, which can be used to establish persistence or perform privilege escalation. It detects EventID 19 (EventFilter creation), EventID 20 (EventConsumer creation), and EventID 21 (FilterToConsumerBinding creation) from Sysmon logs. This activity is significant because WMI Event Subscriptions can execute code with elevated SYSTEM privileges, making it a powerful persistence mechanism. If confirmed malicious, an attacker could maintain long-term access, escalate privileges, and execute arbitrary code, posing a severe threat to the environment. action.notable.param.rule_title = Detect WMI Event Subscription Persistence action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24434,14 +24320,14 @@ search = | tstats `security_content_summariesonly` count min(_time) values(Proce [ESCU - Disable AMSI Through Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = this search is to identify modification in registry to disable AMSI windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +description = The following analytic detects modifications to the Windows registry that disable the Antimalware Scan Interface (AMSI) by setting the "AmsiEnable" value to "0x00000000". This detection leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable". Disabling AMSI is significant as it is a common technique used by ransomware, Remote Access Trojans (RATs), and Advanced Persistent Threats (APTs) to evade detection and impair defenses. If confirmed malicious, this activity could allow attackers to execute payloads with minimal alerts, leading to potential system compromise and data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = this search is to identify modification in registry to disable AMSI windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +action.escu.eli5 = The following analytic detects modifications to the Windows registry that disable the Antimalware Scan Interface (AMSI) by setting the "AmsiEnable" value to "0x00000000". This detection leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable". Disabling AMSI is significant as it is a common technique used by ransomware, Remote Access Trojans (RATs), and Advanced Persistent Threats (APTs) to evade detection and impair defenses. If confirmed malicious, this activity could allow attackers to execute payloads with minimal alerts, leading to potential system compromise and data exfiltration. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = network operator may disable this feature of windows but not so common. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable AMSI Through Registry - Rule action.escu.search_type = detection @@ -24459,11 +24345,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable AMSI Through Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Ransomware", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9c27ec42-d338-11eb-9044-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9c27ec42-d338-11eb-9044-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = this search is to identify modification in registry to disable AMSI windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +action.notable.param.rule_description = The following analytic detects modifications to the Windows registry that disable the Antimalware Scan Interface (AMSI) by setting the "AmsiEnable" value to "0x00000000". This detection leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable". Disabling AMSI is significant as it is a common technique used by ransomware, Remote Access Trojans (RATs), and Advanced Persistent Threats (APTs) to evade detection and impair defenses. If confirmed malicious, this activity could allow attackers to execute payloads with minimal alerts, leading to potential system compromise and data exfiltration. action.notable.param.rule_title = Disable AMSI Through Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24481,14 +24367,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Defender AntiVirus Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +description = The following analytic detects the modification of Windows Defender registry settings to disable antivirus and antispyware protections. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with Windows Defender policies. This activity is significant because disabling antivirus protections is a common tactic used by adversaries to evade detection and maintain persistence on compromised systems. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches, system compromise, and further propagation of malware within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.escu.eli5 = The following analytic detects the modification of Windows Defender registry settings to disable antivirus and antispyware protections. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with Windows Defender policies. This activity is significant because disabling antivirus protections is a common tactic used by adversaries to evade detection and maintain persistence on compromised systems. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches, system compromise, and further propagation of malware within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable windows defender product -action.escu.creation_date = 2023-04-11 -action.escu.modification_date = 2023-04-11 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Defender AntiVirus Registry - Rule action.escu.search_type = detection @@ -24506,11 +24392,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Defender AntiVirus Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "aa4f695a-3024-11ec-9987-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "aa4f695a-3024-11ec-9987-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.notable.param.rule_description = The following analytic detects the modification of Windows Defender registry settings to disable antivirus and antispyware protections. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with Windows Defender policies. This activity is significant because disabling antivirus protections is a common tactic used by adversaries to evade detection and maintain persistence on compromised systems. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches, system compromise, and further propagation of malware within the network. action.notable.param.rule_title = Disable Defender AntiVirus Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24528,14 +24414,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Defender BlockAtFirstSeen Feature - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks suspicious files the first time seen on the host. +description = The following analytic detects the modification of the Windows registry to disable the Windows Defender BlockAtFirstSeen feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the DisableBlockAtFirstSeen value. This activity is significant because disabling this feature can allow malicious files to bypass initial detection by Windows Defender, increasing the risk of malware infection. If confirmed malicious, this action could enable attackers to execute malicious code undetected, leading to potential system compromise and data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks suspicious files the first time seen on the host. +action.escu.eli5 = The following analytic detects the modification of the Windows registry to disable the Windows Defender BlockAtFirstSeen feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the DisableBlockAtFirstSeen value. This activity is significant because disabling this feature can allow malicious files to bypass initial detection by Windows Defender, increasing the risk of malware infection. If confirmed malicious, this action could enable attackers to execute malicious code undetected, leading to potential system compromise and data breaches. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable windows defender product -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Defender BlockAtFirstSeen Feature - Rule action.escu.search_type = detection @@ -24553,11 +24439,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Defender BlockAtFirstSeen Feature - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "CISA AA23-347A", "IcedID", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2dd719ac-3021-11ec-97b4-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2dd719ac-3021-11ec-97b4-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks suspicious files the first time seen on the host. +action.notable.param.rule_description = The following analytic detects the modification of the Windows registry to disable the Windows Defender BlockAtFirstSeen feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the DisableBlockAtFirstSeen value. This activity is significant because disabling this feature can allow malicious files to bypass initial detection by Windows Defender, increasing the risk of malware infection. If confirmed malicious, this action could enable attackers to execute malicious code undetected, leading to potential system compromise and data breaches. action.notable.param.rule_title = Disable Defender BlockAtFirstSeen Feature action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24575,14 +24461,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Defender Enhanced Notification - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is intended to detect a suspicious modification of registry to disable windows defender features. This technique attempts to bypass or evade detection from Windows Defender AV, specifically the Enhanced Notification feature where a user or admin would receive alerts. +description = The following analytic detects the modification of the registry to disable Windows Defender's Enhanced Notification feature. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring changes to the registry path associated with Windows Defender reporting. This activity is significant because disabling Enhanced Notifications can prevent users and administrators from receiving critical security alerts, potentially allowing malicious activities to go unnoticed. If confirmed malicious, this action could enable an attacker to bypass detection mechanisms, maintain persistence, and escalate their activities without triggering alerts. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is intended to detect a suspicious modification of registry to disable windows defender features. This technique attempts to bypass or evade detection from Windows Defender AV, specifically the Enhanced Notification feature where a user or admin would receive alerts. +action.escu.eli5 = The following analytic detects the modification of the registry to disable Windows Defender's Enhanced Notification feature. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring changes to the registry path associated with Windows Defender reporting. This activity is significant because disabling Enhanced Notifications can prevent users and administrators from receiving critical security alerts, potentially allowing malicious activities to go unnoticed. If confirmed malicious, this action could enable an attacker to bypass detection mechanisms, maintain persistence, and escalate their activities without triggering alerts. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = user may choose to disable windows defender AV -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Defender Enhanced Notification - Rule action.escu.search_type = detection @@ -24600,11 +24486,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Defender Enhanced Notification - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "CISA AA23-347A", "IcedID", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc65678c-301f-11ec-8e30-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc65678c-301f-11ec-8e30-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is intended to detect a suspicious modification of registry to disable windows defender features. This technique attempts to bypass or evade detection from Windows Defender AV, specifically the Enhanced Notification feature where a user or admin would receive alerts. +action.notable.param.rule_description = The following analytic detects the modification of the registry to disable Windows Defender's Enhanced Notification feature. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring changes to the registry path associated with Windows Defender reporting. This activity is significant because disabling Enhanced Notifications can prevent users and administrators from receiving critical security alerts, potentially allowing malicious activities to go unnoticed. If confirmed malicious, this action could enable an attacker to bypass detection mechanisms, maintain persistence, and escalate their activities without triggering alerts. action.notable.param.rule_title = Disable Defender Enhanced Notification action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24617,19 +24503,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = | tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) AS lastTime FROM datamodel=Endpoint.Processes BY _time span=1h Processes.user Processes.process_id Processes.process_name Processes.process Processes.process_path Processes.dest Processes.parent_process_name Processes.parent_process Processes.process_guid | `drop_dm_object_name(Processes)` | join process_guid [ | tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*Microsoft\\Windows Defender\\Reporting*" Registry.registry_value_name = DisableEnhancedNotifications Registry.registry_value_data = 0x00000001) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`] | fields firstTime lastTime dest user parent_process_name parent_process process_name process_path process registry_key_name registry_path registry_value_name registry_value_data process_guid | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_defender_antivirus_registry_filter` +search = | tstats `security_content_summariesonly` count min(_time) AS firstTime max(_time) AS lastTime FROM datamodel=Endpoint.Processes BY _time span=1h Processes.user Processes.process_id Processes.process_name Processes.process Processes.process_path Processes.dest Processes.parent_process_name Processes.parent_process Processes.process_guid | `drop_dm_object_name(Processes)` | join process_guid [ | tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*Microsoft\\Windows Defender\\Reporting*" Registry.registry_value_name = DisableEnhancedNotifications Registry.registry_value_data = 0x00000001) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`] | fields firstTime lastTime dest user parent_process_name parent_process process_name process_path process registry_key_name registry_path registry_value_name registry_value_data process_guid | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_defender_enhanced_notification_filter` [ESCU - Disable Defender MpEngine Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +description = The following analytic detects the modification of the Windows Defender MpEngine registry value, specifically setting MpEnablePus to 0x00000000. This detection leverages endpoint registry logs, focusing on changes within the path "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*". This activity is significant as it indicates an attempt to disable key Windows Defender features, potentially allowing malware to evade detection. If confirmed malicious, this could lead to undetected malware execution, persistence, and further system compromise. Immediate investigation and endpoint isolation are recommended. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.escu.eli5 = The following analytic detects the modification of the Windows Defender MpEngine registry value, specifically setting MpEnablePus to 0x00000000. This detection leverages endpoint registry logs, focusing on changes within the path "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*". This activity is significant as it indicates an attempt to disable key Windows Defender features, potentially allowing malware to evade detection. If confirmed malicious, this could lead to undetected malware execution, persistence, and further system compromise. Immediate investigation and endpoint isolation are recommended. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable windows defender product -action.escu.creation_date = 2023-04-11 -action.escu.modification_date = 2023-04-11 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Defender MpEngine Registry - Rule action.escu.search_type = detection @@ -24647,11 +24533,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Defender MpEngine Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc391750-3024-11ec-955a-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc391750-3024-11ec-955a-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.notable.param.rule_description = The following analytic detects the modification of the Windows Defender MpEngine registry value, specifically setting MpEnablePus to 0x00000000. This detection leverages endpoint registry logs, focusing on changes within the path "*\\Policies\\Microsoft\\Windows Defender\\MpEngine*". This activity is significant as it indicates an attempt to disable key Windows Defender features, potentially allowing malware to evade detection. If confirmed malicious, this could lead to undetected malware execution, persistence, and further system compromise. Immediate investigation and endpoint isolation are recommended. action.notable.param.rule_title = Disable Defender MpEngine Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24716,14 +24602,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Defender Submit Samples Consent Feature - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the feature that submits samples for further analysis. +description = The following analytic detects the modification of the Windows registry to disable the Windows Defender Submit Samples Consent feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the SubmitSamplesConsent value set to 0x00000000. This activity is significant as it indicates an attempt to bypass or evade detection by preventing Windows Defender from submitting samples for further analysis. If confirmed malicious, this could allow an attacker to execute malicious code without being detected by Windows Defender, leading to potential system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the feature that submits samples for further analysis. +action.escu.eli5 = The following analytic detects the modification of the Windows registry to disable the Windows Defender Submit Samples Consent feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the SubmitSamplesConsent value set to 0x00000000. This activity is significant as it indicates an attempt to bypass or evade detection by preventing Windows Defender from submitting samples for further analysis. If confirmed malicious, this could allow an attacker to execute malicious code without being detected by Windows Defender, leading to potential system compromise. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable windows defender product -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Defender Submit Samples Consent Feature - Rule action.escu.search_type = detection @@ -24741,11 +24627,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Defender Submit Samples Consent Feature - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "CISA AA23-347A", "IcedID", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "73922ff8-3022-11ec-bf5e-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "73922ff8-3022-11ec-bf5e-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the feature that submits samples for further analysis. +action.notable.param.rule_description = The following analytic detects the modification of the Windows registry to disable the Windows Defender Submit Samples Consent feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path associated with Windows Defender SpyNet and the SubmitSamplesConsent value set to 0x00000000. This activity is significant as it indicates an attempt to bypass or evade detection by preventing Windows Defender from submitting samples for further analysis. If confirmed malicious, this could allow an attacker to execute malicious code without being detected by Windows Defender, leading to potential system compromise. action.notable.param.rule_title = Disable Defender Submit Samples Consent Feature action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24763,14 +24649,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable ETW Through Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to identify modification in registry to disable ETW windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +description = The following analytic detects modifications to the registry that disable the Event Tracing for Windows (ETW) feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\.NETFramework\\ETWEnabled" with a value set to "0x00000000". This activity is significant because disabling ETW can allow attackers to evade detection mechanisms, making it harder for security tools to monitor malicious activities. If confirmed malicious, this could enable attackers to execute payloads with minimal alerts, impairing defenses and potentially leading to further compromise of the system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to identify modification in registry to disable ETW windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +action.escu.eli5 = The following analytic detects modifications to the registry that disable the Event Tracing for Windows (ETW) feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\.NETFramework\\ETWEnabled" with a value set to "0x00000000". This activity is significant because disabling ETW can allow attackers to evade detection mechanisms, making it harder for security tools to monitor malicious activities. If confirmed malicious, this could enable attackers to execute payloads with minimal alerts, impairing defenses and potentially leading to further compromise of the system. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = network operator may disable this feature of windows but not so common. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable ETW Through Registry - Rule action.escu.search_type = detection @@ -24788,11 +24674,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable ETW Through Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Ransomware", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f0eacfa4-d33f-11eb-8f9d-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f0eacfa4-d33f-11eb-8f9d-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to identify modification in registry to disable ETW windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible. +action.notable.param.rule_description = The following analytic detects modifications to the registry that disable the Event Tracing for Windows (ETW) feature. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\.NETFramework\\ETWEnabled" with a value set to "0x00000000". This activity is significant because disabling ETW can allow attackers to evade detection mechanisms, making it harder for security tools to monitor malicious activities. If confirmed malicious, this could enable attackers to execute payloads with minimal alerts, impairing defenses and potentially leading to further compromise of the system. action.notable.param.rule_title = Disable ETW Through Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24857,14 +24743,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Disable Registry Tool - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search identifies modification of registry to disable the regedit or registry tools of the windows operating system. Since registry tool is a swiss knife in analyzing registry, malware such as RAT or trojan Spy disable this application to prevent the removal of their registry entry such as persistence, file less components and defense evasion. +description = The following analytic detects modifications to the Windows registry aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" with a value of "0x00000001". This activity is significant because malware, such as RATs or trojans, often disable registry tools to prevent the removal of their entries, aiding in persistence and defense evasion. If confirmed malicious, this could hinder incident response efforts and allow the attacker to maintain control over the compromised system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search identifies modification of registry to disable the regedit or registry tools of the windows operating system. Since registry tool is a swiss knife in analyzing registry, malware such as RAT or trojan Spy disable this application to prevent the removal of their registry entry such as persistence, file less components and defense evasion. +action.escu.eli5 = The following analytic detects modifications to the Windows registry aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" with a value of "0x00000001". This activity is significant because malware, such as RATs or trojans, often disable registry tools to prevent the removal of their entries, aiding in persistence and defense evasion. If confirmed malicious, this could hinder incident response efforts and allow the attacker to maintain control over the compromised system. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may disable this application for non technical user. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-14 +action.escu.modification_date = 2024-05-14 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Registry Tool - Rule action.escu.search_type = detection @@ -24882,11 +24768,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Registry Tool - Rule action.correlationsearch.annotations = {"analytic_story": ["NjRAT", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cd2cf33c-9201-11eb-a10a-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cd2cf33c-9201-11eb-a10a-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search identifies modification of registry to disable the regedit or registry tools of the windows operating system. Since registry tool is a swiss knife in analyzing registry, malware such as RAT or trojan Spy disable this application to prevent the removal of their registry entry such as persistence, file less components and defense evasion. +action.notable.param.rule_description = The following analytic detects modifications to the Windows registry aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" with a value of "0x00000001". This activity is significant because malware, such as RATs or trojans, often disable registry tools to prevent the removal of their entries, aiding in persistence and defense evasion. If confirmed malicious, this could hinder incident response efforts and allow the attacker to maintain control over the compromised system. action.notable.param.rule_title = Disable Registry Tool action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24904,14 +24790,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Schedule Task - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is to detect a suspicious commandline to disable existing schedule task. This technique is used by adversaries or commodity malware like IcedID to disable security application (AV products) in the targetted host to evade detections. This TTP is a good pivot to check further why and what other process run before and after this detection. check which process execute the commandline and what task is disabled. parent child process is quite valuable in this scenario too. +description = The following analytic detects the execution of a command to disable an existing scheduled task using 'schtasks.exe' with the '/change' and '/disable' parameters. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Disabling scheduled tasks is significant as it is a common tactic used by adversaries, including malware like IcedID, to disable security applications and evade detection. If confirmed malicious, this activity could allow attackers to persist undetected, disable critical security defenses, and further compromise the targeted host. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is to detect a suspicious commandline to disable existing schedule task. This technique is used by adversaries or commodity malware like IcedID to disable security application (AV products) in the targetted host to evade detections. This TTP is a good pivot to check further why and what other process run before and after this detection. check which process execute the commandline and what task is disabled. parent child process is quite valuable in this scenario too. +action.escu.eli5 = The following analytic detects the execution of a command to disable an existing scheduled task using 'schtasks.exe' with the '/change' and '/disable' parameters. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Disabling scheduled tasks is significant as it is a common tactic used by adversaries, including malware like IcedID, to disable security applications and evade detection. If confirmed malicious, this activity could allow attackers to persist undetected, disable critical security defenses, and further compromise the targeted host. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = admin may disable problematic schedule task -action.escu.creation_date = 2021-10-18 -action.escu.modification_date = 2021-10-18 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Schedule Task - Rule action.escu.search_type = detection @@ -24929,11 +24815,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Schedule Task - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 80, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "db596056-3019-11ec-a9ff-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "db596056-3019-11ec-a9ff-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is to detect a suspicious commandline to disable existing schedule task. This technique is used by adversaries or commodity malware like IcedID to disable security application (AV products) in the targetted host to evade detections. This TTP is a good pivot to check further why and what other process run before and after this detection. check which process execute the commandline and what task is disabled. parent child process is quite valuable in this scenario too. +action.notable.param.rule_description = The following analytic detects the execution of a command to disable an existing scheduled task using 'schtasks.exe' with the '/change' and '/disable' parameters. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Disabling scheduled tasks is significant as it is a common tactic used by adversaries, including malware like IcedID, to disable security applications and evade detection. If confirmed malicious, this activity could allow attackers to persist undetected, disable critical security defenses, and further compromise the targeted host. action.notable.param.rule_title = Disable Schedule Task action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24951,14 +24837,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTim [ESCU - Disable Security Logs Using MiniNt Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is to detect a suspicious registry modification to disable security audit logs. This technique was shared by a researcher to disable Security logs of windows by adding this registry. The Windows will think it is WinPE and will not log any event to the Security Log +description = The following analytic detects a suspicious registry modification aimed at disabling security audit logs by adding a specific registry entry. It leverages data from the Endpoint.Registry data model, focusing on changes to the "Control\\MiniNt" registry path. This activity is significant because it can prevent Windows from logging any events to the Security Log, effectively blinding security monitoring efforts. If confirmed malicious, this technique could allow an attacker to operate undetected, making it difficult to trace their actions and compromising the integrity of security audits. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is to detect a suspicious registry modification to disable security audit logs. This technique was shared by a researcher to disable Security logs of windows by adding this registry. The Windows will think it is WinPE and will not log any event to the Security Log +action.escu.eli5 = The following analytic detects a suspicious registry modification aimed at disabling security audit logs by adding a specific registry entry. It leverages data from the Endpoint.Registry data model, focusing on changes to the "Control\\MiniNt" registry path. This activity is significant because it can prevent Windows from logging any events to the Security Log, effectively blinding security monitoring efforts. If confirmed malicious, this technique could allow an attacker to operate undetected, making it difficult to trace their actions and compromising the integrity of security audits. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = Unknown. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Security Logs Using MiniNt Registry - Rule action.escu.search_type = detection @@ -24976,11 +24862,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Security Logs Using MiniNt Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "39ebdc68-25b9-11ec-aec7-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "39ebdc68-25b9-11ec-aec7-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is to detect a suspicious registry modification to disable security audit logs. This technique was shared by a researcher to disable Security logs of windows by adding this registry. The Windows will think it is WinPE and will not log any event to the Security Log +action.notable.param.rule_description = The following analytic detects a suspicious registry modification aimed at disabling security audit logs by adding a specific registry entry. It leverages data from the Endpoint.Registry data model, focusing on changes to the "Control\\MiniNt" registry path. This activity is significant because it can prevent Windows from logging any events to the Security Log, effectively blinding security monitoring efforts. If confirmed malicious, this technique could allow an attacker to operate undetected, making it difficult to trace their actions and compromising the integrity of security audits. action.notable.param.rule_title = Disable Security Logs Using MiniNt Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -24998,14 +24884,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Show Hidden Files - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic is to identify a modification in the Windows registry to prevent users from seeing all the files with hidden attributes. This event or techniques are known on some worm and trojan spy malware that will drop hidden files on the infected machine. +description = The following analytic detects modifications to the Windows registry that disable the display of hidden files. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with hidden file settings. This activity is significant because malware, such as worms and trojan spyware, often use hidden files to evade detection. If confirmed malicious, this behavior could allow an attacker to conceal malicious files on the system, making it harder for security tools and analysts to identify and remove the threat. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.001", "T1562.001", "T1564", "T1562", "T1112"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic is to identify a modification in the Windows registry to prevent users from seeing all the files with hidden attributes. This event or techniques are known on some worm and trojan spy malware that will drop hidden files on the infected machine. +action.escu.eli5 = The following analytic detects modifications to the Windows registry that disable the display of hidden files. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with hidden file settings. This activity is significant because malware, such as worms and trojan spyware, often use hidden files to evade detection. If confirmed malicious, this behavior could allow an attacker to conceal malicious files on the system, making it harder for security tools and analysts to identify and remove the threat. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Show Hidden Files - Rule action.escu.search_type = detection @@ -25023,7 +24909,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Show Hidden Files - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.001", "T1562.001", "T1564", "T1562", "T1112"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6f3ccfa2-91fe-11eb-8f9b-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "6f3ccfa2-91fe-11eb-8f9b-acde48001122", "detection_version": "6"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -25039,14 +24925,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable UAC Remote Restriction - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is to detect a suspicious modification of registry to disable UAC remote restriction. This technique was well documented in Microsoft page where attacker may modify this registry value to bypassed UAC feature of windows host. This is a good indicator that some tries to bypassed UAC to suspicious process or gain privilege escalation. +description = The following analytic detects the modification of the registry to disable UAC remote restriction by setting the "LocalAccountTokenFilterPolicy" value to "0x00000001". It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\CurrentVersion\\Policies\\System*". This activity is significant because disabling UAC remote restriction can allow an attacker to bypass User Account Control (UAC) protections, potentially leading to privilege escalation. If confirmed malicious, this could enable an attacker to execute unauthorized actions with elevated privileges, compromising the security of the affected system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is to detect a suspicious modification of registry to disable UAC remote restriction. This technique was well documented in Microsoft page where attacker may modify this registry value to bypassed UAC feature of windows host. This is a good indicator that some tries to bypassed UAC to suspicious process or gain privilege escalation. +action.escu.eli5 = The following analytic detects the modification of the registry to disable UAC remote restriction by setting the "LocalAccountTokenFilterPolicy" value to "0x00000001". It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\CurrentVersion\\Policies\\System*". This activity is significant because disabling UAC remote restriction can allow an attacker to bypass User Account Control (UAC) protections, potentially leading to privilege escalation. If confirmed malicious, this could enable an attacker to execute unauthorized actions with elevated privileges, compromising the security of the affected system. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may set this policy for non-critical machine. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable UAC Remote Restriction - Rule action.escu.search_type = detection @@ -25064,11 +24950,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable UAC Remote Restriction - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Suspicious Windows Registry Activities", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9928b732-210e-11ec-b65e-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9928b732-210e-11ec-b65e-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is to detect a suspicious modification of registry to disable UAC remote restriction. This technique was well documented in Microsoft page where attacker may modify this registry value to bypassed UAC feature of windows host. This is a good indicator that some tries to bypassed UAC to suspicious process or gain privilege escalation. +action.notable.param.rule_description = The following analytic detects the modification of the registry to disable UAC remote restriction by setting the "LocalAccountTokenFilterPolicy" value to "0x00000001". It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\CurrentVersion\\Policies\\System*". This activity is significant because disabling UAC remote restriction can allow an attacker to bypass User Account Control (UAC) protections, potentially leading to privilege escalation. If confirmed malicious, this could enable an attacker to execute unauthorized actions with elevated privileges, compromising the security of the affected system. action.notable.param.rule_title = Disable UAC Remote Restriction action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25086,14 +24972,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Windows App Hotkeys - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects a suspicious registry modification to disable Windows hotkey (shortcut keys) for native Windows applications. This technique is commonly used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. This technique is used to impair the analyst in analyzing and removing the attacker implant in compromised systems. +description = The following analytic detects a suspicious registry modification aimed at disabling Windows hotkeys for native applications. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values indicative of this behavior. This activity is significant as it can impair an analyst's ability to use essential tools like Task Manager and Command Prompt, hindering incident response efforts. If confirmed malicious, this technique can allow an attacker to maintain persistence and evade detection, complicating the remediation process. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects a suspicious registry modification to disable Windows hotkey (shortcut keys) for native Windows applications. This technique is commonly used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. This technique is used to impair the analyst in analyzing and removing the attacker implant in compromised systems. +action.escu.eli5 = The following analytic detects a suspicious registry modification aimed at disabling Windows hotkeys for native applications. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values indicative of this behavior. This activity is significant as it can impair an analyst's ability to use essential tools like Task Manager and Command Prompt, hindering incident response efforts. If confirmed malicious, this technique can allow an attacker to maintain persistence and evade detection, complicating the remediation process. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-04-27 -action.escu.modification_date = 2023-04-27 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Windows App Hotkeys - Rule action.escu.search_type = detection @@ -25111,11 +24997,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Windows App Hotkeys - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Registry Abuse", "XMRig"], "cis20": ["CIS 10"], "confidence": 100, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1490f224-ad8b-11eb-8c4f-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "1490f224-ad8b-11eb-8c4f-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects a suspicious registry modification to disable Windows hotkey (shortcut keys) for native Windows applications. This technique is commonly used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. This technique is used to impair the analyst in analyzing and removing the attacker implant in compromised systems. +action.notable.param.rule_description = The following analytic detects a suspicious registry modification aimed at disabling Windows hotkeys for native applications. It leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values indicative of this behavior. This activity is significant as it can impair an analyst's ability to use essential tools like Task Manager and Command Prompt, hindering incident response efforts. If confirmed malicious, this technique can allow an attacker to maintain persistence and evade detection, complicating the remediation process. action.notable.param.rule_title = Disable Windows App Hotkeys action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25180,14 +25066,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disable Windows SmartScreen Protection - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following search identifies a modification of registry to disable the smartscreen protection of windows machine. This is windows feature provide an early warning system against website that might engage in phishing attack or malware distribution. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload. +description = The following analytic detects modifications to the Windows registry that disable SmartScreen protection. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with SmartScreen settings. This activity is significant because SmartScreen provides an early warning system against phishing and malware. Disabling it can indicate malicious intent, often seen in Remote Access Trojans (RATs) to evade detection while downloading additional payloads. If confirmed malicious, this action could allow attackers to bypass security measures, increasing the risk of successful phishing attacks and malware infections. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following search identifies a modification of registry to disable the smartscreen protection of windows machine. This is windows feature provide an early warning system against website that might engage in phishing attack or malware distribution. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload. +action.escu.eli5 = The following analytic detects modifications to the Windows registry that disable SmartScreen protection. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with SmartScreen settings. This activity is significant because SmartScreen provides an early warning system against phishing and malware. Disabling it can indicate malicious intent, often seen in Remote Access Trojans (RATs) to evade detection while downloading additional payloads. If confirmed malicious, this action could allow attackers to bypass security measures, increasing the risk of successful phishing attacks and malware infections. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable this windows features. -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Disable Windows SmartScreen Protection - Rule action.escu.search_type = detection @@ -25205,11 +25091,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disable Windows SmartScreen Protection - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "664f0fd0-91ff-11eb-a56f-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "664f0fd0-91ff-11eb-a56f-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following search identifies a modification of registry to disable the smartscreen protection of windows machine. This is windows feature provide an early warning system against website that might engage in phishing attack or malware distribution. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload. +action.notable.param.rule_description = The following analytic detects modifications to the Windows registry that disable SmartScreen protection. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with SmartScreen settings. This activity is significant because SmartScreen provides an early warning system against phishing and malware. Disabling it can indicate malicious intent, often seen in Remote Access Trojans (RATs) to evade detection while downloading additional payloads. If confirmed malicious, this action could allow attackers to bypass security measures, increasing the risk of successful phishing attacks and malware infections. action.notable.param.rule_title = Disable Windows SmartScreen Protection action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25227,14 +25113,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUser` commandlet with specific parameters. `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Get-ADUser` is used to query for domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack their passwords offline. +description = The following analytic detects the execution of the `Get-ADUser` PowerShell cmdlet with parameters indicating a search for domain accounts with Kerberos Pre-Authentication disabled. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific activity. This behavior is significant because discovering accounts with Kerberos Pre-Authentication disabled can allow adversaries to perform offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to user accounts, potentially compromising sensitive information and escalating privileges within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUser` commandlet with specific parameters. `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Get-ADUser` is used to query for domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack their passwords offline. +action.escu.eli5 = The following analytic detects the execution of the `Get-ADUser` PowerShell cmdlet with parameters indicating a search for domain accounts with Kerberos Pre-Authentication disabled. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific activity. This behavior is significant because discovering accounts with Kerberos Pre-Authentication disabled can allow adversaries to perform offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to user accounts, potentially compromising sensitive information and escalating privileges within the network. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Administrators or power users may use search for accounts with Kerberos Pre Authentication disabled for legitimate purposes. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule action.escu.search_type = detection @@ -25252,11 +25138,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Kerberos Attacks", "CISA AA23-347A"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "114c6bfe-9406-11ec-bcce-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "114c6bfe-9406-11ec-bcce-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUser` commandlet with specific parameters. `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Get-ADUser` is used to query for domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack their passwords offline. +action.notable.param.rule_description = The following analytic detects the execution of the `Get-ADUser` PowerShell cmdlet with parameters indicating a search for domain accounts with Kerberos Pre-Authentication disabled. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this specific activity. This behavior is significant because discovering accounts with Kerberos Pre-Authentication disabled can allow adversaries to perform offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to user accounts, potentially compromising sensitive information and escalating privileges within the network. action.notable.param.rule_title = Disabled Kerberos Pre-Authentication Discovery With Get-ADUser action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25274,16 +25160,14 @@ search = `powershell` EventCode=4104 (ScriptBlockText = "*Get-ADUser*" AND Scri [ESCU - Disabled Kerberos Pre-Authentication Discovery With PowerView - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet with specific parameters. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is used to identify domain users and combining it with `-PreauthNotRequired` allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled. \ -Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts and attempt to crack their passwords offline. +description = The following analytic detects the execution of the `Get-DomainUser` commandlet with the `-PreauthNotRequired` parameter using PowerShell Script Block Logging (EventCode=4104). This command is part of PowerView, a tool used for enumerating Windows Active Directory networks. Identifying domain accounts with Kerberos Pre-Authentication disabled is significant because adversaries can leverage this information to attempt offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to domain accounts, potentially compromising sensitive information and escalating privileges within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet with specific parameters. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is used to identify domain users and combining it with `-PreauthNotRequired` allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled. \ -Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts and attempt to crack their passwords offline. +action.escu.eli5 = The following analytic detects the execution of the `Get-DomainUser` commandlet with the `-PreauthNotRequired` parameter using PowerShell Script Block Logging (EventCode=4104). This command is part of PowerView, a tool used for enumerating Windows Active Directory networks. Identifying domain accounts with Kerberos Pre-Authentication disabled is significant because adversaries can leverage this information to attempt offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to domain accounts, potentially compromising sensitive information and escalating privileges within the network. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Administrators or power users may use PowerView for troubleshooting -action.escu.creation_date = 2022-05-03 -action.escu.modification_date = 2022-05-03 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabled Kerberos Pre-Authentication Discovery With PowerView - Rule action.escu.search_type = detection @@ -25301,12 +25185,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabled Kerberos Pre-Authentication Discovery With PowerView - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Kerberos Attacks"], "cis20": ["CIS 10"], "confidence": 90, "impact": 60, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b0b34e2c-90de-11ec-baeb-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b0b34e2c-90de-11ec-baeb-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet with specific parameters. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is used to identify domain users and combining it with `-PreauthNotRequired` allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled. \ -Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts and attempt to crack their passwords offline. +action.notable.param.rule_description = The following analytic detects the execution of the `Get-DomainUser` commandlet with the `-PreauthNotRequired` parameter using PowerShell Script Block Logging (EventCode=4104). This command is part of PowerView, a tool used for enumerating Windows Active Directory networks. Identifying domain accounts with Kerberos Pre-Authentication disabled is significant because adversaries can leverage this information to attempt offline password cracking. If confirmed malicious, this activity could lead to unauthorized access to domain accounts, potentially compromising sensitive information and escalating privileges within the network. action.notable.param.rule_title = Disabled Kerberos Pre-Authentication Discovery With PowerView action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25324,14 +25207,14 @@ search = `powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainUser*" AND [ESCU - Disabling CMD Application - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to identify modification in registry to disable cmd prompt application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging or deleting there samples through cmd application which is one of the tool of analyst to traverse on directory and files. +description = The following analytic detects modifications to the registry that disable the CMD prompt application. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableCMD" registry value. This activity is significant because disabling CMD can hinder an analyst's ability to investigate and remediate threats, a tactic often used by malware such as RATs, Trojans, or Worms. If confirmed malicious, this could prevent security teams from using CMD for directory and file traversal, complicating incident response and allowing the attacker to maintain persistence. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to identify modification in registry to disable cmd prompt application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging or deleting there samples through cmd application which is one of the tool of analyst to traverse on directory and files. +action.escu.eli5 = The following analytic detects modifications to the registry that disable the CMD prompt application. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableCMD" registry value. This activity is significant because disabling CMD can hinder an analyst's ability to investigate and remediate threats, a tactic often used by malware such as RATs, Trojans, or Worms. If confirmed malicious, this could prevent security teams from using CMD for directory and file traversal, complicating incident response and allowing the attacker to maintain persistence. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may disable this application for non technical user. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling CMD Application - Rule action.escu.search_type = detection @@ -25349,11 +25232,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling CMD Application - Rule action.correlationsearch.annotations = {"analytic_story": ["NjRAT", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ff86077c-9212-11eb-a1e6-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ff86077c-9212-11eb-a1e6-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to identify modification in registry to disable cmd prompt application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging or deleting there samples through cmd application which is one of the tool of analyst to traverse on directory and files. +action.notable.param.rule_description = The following analytic detects modifications to the registry that disable the CMD prompt application. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the "DisableCMD" registry value. This activity is significant because disabling CMD can hinder an analyst's ability to investigate and remediate threats, a tactic often used by malware such as RATs, Trojans, or Worms. If confirmed malicious, this could prevent security teams from using CMD for directory and file traversal, complicating incident response and allowing the attacker to maintain persistence. action.notable.param.rule_title = Disabling CMD Application action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25418,14 +25301,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disabling Defender Services - Rule] action.escu = 0 action.escu.enabled = 1 -description = This particular behavior is typically executed when an adversaries or malware gains access to an endpoint and beings to perform execution and to evade detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +description = The following analytic detects the disabling of Windows Defender services by monitoring registry modifications. It leverages registry event data to identify changes to specific registry paths associated with Defender services, where the 'Start' value is set to '0x00000004'. This activity is significant because disabling Defender services can indicate an attempt by an adversary to evade detection and maintain persistence on the endpoint. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches or system compromise. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This particular behavior is typically executed when an adversaries or malware gains access to an endpoint and beings to perform execution and to evade detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.escu.eli5 = The following analytic detects the disabling of Windows Defender services by monitoring registry modifications. It leverages registry event data to identify changes to specific registry paths associated with Defender services, where the 'Start' value is set to '0x00000004'. This activity is significant because disabling Defender services can indicate an attempt by an adversary to evade detection and maintain persistence on the endpoint. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches or system compromise. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin or user may choose to disable windows defender product -action.escu.creation_date = 2023-04-27 -action.escu.modification_date = 2023-04-27 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling Defender Services - Rule action.escu.search_type = detection @@ -25443,11 +25326,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling Defender Services - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "RedLine Stealer", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "911eacdc-317f-11ec-ad30-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "911eacdc-317f-11ec-ad30-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This particular behavior is typically executed when an adversaries or malware gains access to an endpoint and beings to perform execution and to evade detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated. +action.notable.param.rule_description = The following analytic detects the disabling of Windows Defender services by monitoring registry modifications. It leverages registry event data to identify changes to specific registry paths associated with Defender services, where the 'Start' value is set to '0x00000004'. This activity is significant because disabling Defender services can indicate an attempt by an adversary to evade detection and maintain persistence on the endpoint. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches or system compromise. action.notable.param.rule_title = Disabling Defender Services action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25506,14 +25389,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Disabling FolderOptions Windows Feature - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to identify registry modification to disable folder options feature of windows to show hidden files, file extension and etc. This technique used by malware in combination if disabling show hidden files feature to hide their files and also to hide the file extension to lure the user base on file icons or fake file extensions. +description = The following analytic detects the modification of the Windows registry to disable the Folder Options feature, which prevents users from showing hidden files and file extensions. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions" with a value of "0x00000001". This activity is significant as it is commonly used by malware to conceal malicious files and deceive users with fake file extensions. If confirmed malicious, this could allow an attacker to hide their presence and malicious files, making detection and remediation more difficult. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to identify registry modification to disable folder options feature of windows to show hidden files, file extension and etc. This technique used by malware in combination if disabling show hidden files feature to hide their files and also to hide the file extension to lure the user base on file icons or fake file extensions. +action.escu.eli5 = The following analytic detects the modification of the Windows registry to disable the Folder Options feature, which prevents users from showing hidden files and file extensions. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions" with a value of "0x00000001". This activity is significant as it is commonly used by malware to conceal malicious files and deceive users with fake file extensions. If confirmed malicious, this could allow an attacker to hide their presence and malicious files, making detection and remediation more difficult. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may disable this application for non technical user. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling FolderOptions Windows Feature - Rule action.escu.search_type = detection @@ -25531,11 +25414,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling FolderOptions Windows Feature - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA23-347A", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "83776de4-921a-11eb-868a-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "83776de4-921a-11eb-868a-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to identify registry modification to disable folder options feature of windows to show hidden files, file extension and etc. This technique used by malware in combination if disabling show hidden files feature to hide their files and also to hide the file extension to lure the user base on file icons or fake file extensions. +action.notable.param.rule_description = The following analytic detects the modification of the Windows registry to disable the Folder Options feature, which prevents users from showing hidden files and file extensions. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions" with a value of "0x00000001". This activity is significant as it is commonly used by malware to conceal malicious files and deceive users with fake file extensions. If confirmed malicious, this could allow an attacker to hide their presence and malicious files, making detection and remediation more difficult. action.notable.param.rule_title = Disabling FolderOptions Windows Feature action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25600,14 +25483,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Disabling NoRun Windows App - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to identify modification of registry to disable run application in window start menu. this application is known to be a helpful shortcut to windows OS user to run known application and also to execute some reg or batch script. This technique is used malware to make cleaning of its infection more harder by preventing known application run easily through run shortcut. +description = The following analytic detects the modification of the Windows registry to disable the Run application in the Start menu. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" with a value of "0x00000001". This activity is significant because the Run application is a useful shortcut for executing known applications and scripts. If confirmed malicious, this action could hinder system cleaning efforts and make it more difficult to run essential tools, thereby aiding malware persistence. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to identify modification of registry to disable run application in window start menu. this application is known to be a helpful shortcut to windows OS user to run known application and also to execute some reg or batch script. This technique is used malware to make cleaning of its infection more harder by preventing known application run easily through run shortcut. +action.escu.eli5 = The following analytic detects the modification of the Windows registry to disable the Run application in the Start menu. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" with a value of "0x00000001". This activity is significant because the Run application is a useful shortcut for executing known applications and scripts. If confirmed malicious, this action could hinder system cleaning efforts and make it more difficult to run essential tools, thereby aiding malware persistence. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may disable this application for non technical user. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-13 +action.escu.modification_date = 2024-05-13 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling NoRun Windows App - Rule action.escu.search_type = detection @@ -25625,11 +25508,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling NoRun Windows App - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de81bc46-9213-11eb-adc9-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "de81bc46-9213-11eb-adc9-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to identify modification of registry to disable run application in window start menu. this application is known to be a helpful shortcut to windows OS user to run known application and also to execute some reg or batch script. This technique is used malware to make cleaning of its infection more harder by preventing known application run easily through run shortcut. +action.notable.param.rule_description = The following analytic detects the modification of the Windows registry to disable the Run application in the Start menu. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoRun" with a value of "0x00000001". This activity is significant because the Run application is a useful shortcut for executing known applications and scripts. If confirmed malicious, this action could hinder system cleaning efforts and make it more difficult to run essential tools, thereby aiding malware persistence. action.notable.param.rule_title = Disabling NoRun Windows App action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25694,14 +25577,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Disabling SystemRestore In Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following search identifies the modification of registry related in disabling the system restore of a machine. This event or behavior are seen in some RAT malware to make the restore of the infected machine difficult and keep their infection on the box. +description = The following analytic detects the modification of registry keys to disable System Restore on a machine. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with System Restore settings. This activity is significant because disabling System Restore can hinder recovery efforts and is a tactic often used by Remote Access Trojans (RATs) to maintain persistence on an infected system. If confirmed malicious, this action could prevent system recovery, allowing the attacker to sustain their foothold and potentially cause further damage or data loss. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following search identifies the modification of registry related in disabling the system restore of a machine. This event or behavior are seen in some RAT malware to make the restore of the infected machine difficult and keep their infection on the box. +action.escu.eli5 = The following analytic detects the modification of registry keys to disable System Restore on a machine. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with System Restore settings. This activity is significant because disabling System Restore can hinder recovery efforts and is a tactic often used by Remote Access Trojans (RATs) to maintain persistence on an infected system. If confirmed malicious, this action could prevent system recovery, allowing the attacker to sustain their foothold and potentially cause further damage or data loss. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = in some cases admin can disable systemrestore on a machine. -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling SystemRestore In Registry - Rule action.escu.search_type = detection @@ -25719,11 +25602,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling SystemRestore In Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["NjRAT", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4f837e2-91fb-11eb-8bf6-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f4f837e2-91fb-11eb-8bf6-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following search identifies the modification of registry related in disabling the system restore of a machine. This event or behavior are seen in some RAT malware to make the restore of the infected machine difficult and keep their infection on the box. +action.notable.param.rule_description = The following analytic detects the modification of registry keys to disable System Restore on a machine. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with System Restore settings. This activity is significant because disabling System Restore can hinder recovery efforts and is a tactic often used by Remote Access Trojans (RATs) to maintain persistence on an infected system. If confirmed malicious, this action could prevent system recovery, allowing the attacker to sustain their foothold and potentially cause further damage or data loss. action.notable.param.rule_title = Disabling SystemRestore In Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25741,14 +25624,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Disabling Task Manager - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to identifies modification of registry to disable the task manager of windows operating system. this event or technique are commonly seen in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate their process. +description = The following analytic identifies modifications to the Windows registry that disable Task Manager. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" with a value of "0x00000001". This activity is significant as it is commonly associated with malware such as RATs, Trojans, and worms, which disable Task Manager to prevent users from terminating malicious processes. If confirmed malicious, this could allow attackers to maintain persistence and control over the infected system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to identifies modification of registry to disable the task manager of windows operating system. this event or technique are commonly seen in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate their process. +action.escu.eli5 = The following analytic identifies modifications to the Windows registry that disable Task Manager. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" with a value of "0x00000001". This activity is significant as it is commonly associated with malware such as RATs, Trojans, and worms, which disable Task Manager to prevent users from terminating malicious processes. If confirmed malicious, this could allow attackers to maintain persistence and control over the infected system. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = admin may disable this application for non technical user. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Disabling Task Manager - Rule action.escu.search_type = detection @@ -25766,11 +25649,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Disabling Task Manager - Rule action.correlationsearch.annotations = {"analytic_story": ["NjRAT", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 60, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dac279bc-9202-11eb-b7fb-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dac279bc-9202-11eb-b7fb-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to identifies modification of registry to disable the task manager of windows operating system. this event or technique are commonly seen in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate their process. +action.notable.param.rule_description = The following analytic identifies modifications to the Windows registry that disable Task Manager. It leverages data from the Endpoint.Registry data model, specifically looking for changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableTaskMgr" with a value of "0x00000001". This activity is significant as it is commonly associated with malware such as RATs, Trojans, and worms, which disable Task Manager to prevent users from terminating malicious processes. If confirmed malicious, this could allow attackers to maintain persistence and control over the infected system. action.notable.param.rule_title = Disabling Task Manager action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25835,14 +25718,14 @@ search = | tstats `security_content_summariesonly` min(_time) as _time from data [ESCU - DLLHost with no Command Line Arguments with Network - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic identifies DLLHost.exe with no command line arguments with a network connection. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects instances of DLLHost.exe running without command line arguments while establishing a network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network activity data. It is significant because DLLHost.exe typically runs with specific arguments, and its absence can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers to execute code, move laterally, or exfiltrate data, posing a severe threat to the network's security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint", "Network_Traffic"] -action.escu.eli5 = The following analytic identifies DLLHost.exe with no command line arguments with a network connection. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.escu.eli5 = The following analytic detects instances of DLLHost.exe running without command line arguments while establishing a network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network activity data. It is significant because DLLHost.exe typically runs with specific arguments, and its absence can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers to execute code, move laterally, or exfiltrate data, posing a severe threat to the network's security. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Although unlikely, some legitimate third party applications may use a moved copy of dllhost, triggering a false positive. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - DLLHost with no Command Line Arguments with Network - Rule action.escu.search_type = detection @@ -25860,11 +25743,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - DLLHost with no Command Line Arguments with Network - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Cobalt Strike", "Graceful Wipe Out Attack"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f1c07594-a141-11eb-8407-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f1c07594-a141-11eb-8407-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies DLLHost.exe with no command line arguments with a network connection. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. +action.notable.param.rule_description = The following analytic detects instances of DLLHost.exe running without command line arguments while establishing a network connection. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process execution and network activity data. It is significant because DLLHost.exe typically runs with specific arguments, and its absence can indicate malicious activity, such as Cobalt Strike usage. If confirmed malicious, this activity could allow attackers to execute code, move laterally, or exfiltrate data, posing a severe threat to the network's security. action.notable.param.rule_title = DLLHost with no Command Line Arguments with Network action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25882,14 +25765,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - DNS Exfiltration Using Nslookup App - Rule] action.escu = 0 action.escu.enabled = 1 -description = this search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +description = The following analytic identifies potential DNS exfiltration using the nslookup application. It detects specific command-line parameters such as query type (TXT, A, AAAA) and retry options, which are commonly used by attackers to exfiltrate data. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution logs. This activity is significant as it may indicate an attempt to communicate with a Command and Control (C2) server or exfiltrate sensitive data. If confirmed malicious, this could lead to data breaches and unauthorized access to critical information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = this search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +action.escu.eli5 = The following analytic identifies potential DNS exfiltration using the nslookup application. It detects specific command-line parameters such as query type (TXT, A, AAAA) and retry options, which are commonly used by attackers to exfiltrate data. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution logs. This activity is significant as it may indicate an attempt to communicate with a Command and Control (C2) server or exfiltrate sensitive data. If confirmed malicious, this could lead to data breaches and unauthorized access to critical information. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = admin nslookup usage -action.escu.creation_date = 2021-04-15 -action.escu.modification_date = 2021-04-15 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - DNS Exfiltration Using Nslookup App - Rule action.escu.search_type = detection @@ -25907,11 +25790,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - DNS Exfiltration Using Nslookup App - Rule action.correlationsearch.annotations = {"analytic_story": ["Command And Control", "Data Exfiltration", "Dynamic DNS", "Suspicious DNS Traffic"], "cis20": ["CIS 10"], "confidence": 80, "impact": 90, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2452e632-9e0d-11eb-bacd-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2452e632-9e0d-11eb-bacd-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = this search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +action.notable.param.rule_description = The following analytic identifies potential DNS exfiltration using the nslookup application. It detects specific command-line parameters such as query type (TXT, A, AAAA) and retry options, which are commonly used by attackers to exfiltrate data. The detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process execution logs. This activity is significant as it may indicate an attempt to communicate with a Command and Control (C2) server or exfiltrate sensitive data. If confirmed malicious, this could lead to data breaches and unauthorized access to critical information. action.notable.param.rule_title = DNS Exfiltration Using Nslookup App action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -25929,14 +25812,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Domain Account Discovery with Dsquery - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover domain users. The `user` argument returns a list of all users registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery. +description = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to discover domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to map out domain users, which is a common precursor to further attacks. If confirmed malicious, this behavior could allow attackers to gain insights into user accounts, facilitating subsequent actions like privilege escalation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover domain users. The `user` argument returns a list of all users registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to discover domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to map out domain users, which is a common precursor to further attacks. If confirmed malicious, this behavior could allow attackers to gain insights into user accounts, facilitating subsequent actions like privilege escalation or lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-08-24 -action.escu.modification_date = 2021-08-24 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Account Discovery with Dsquery - Rule action.escu.search_type = detection @@ -25949,7 +25832,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Account Discovery with Dsquery - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b1a8ce04-04c2-11ec-bea7-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b1a8ce04-04c2-11ec-bea7-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -25965,14 +25848,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Account Discovery With Net App - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike may use net.exe to enumerate domain users for situational awareness and Active Directory Discovery. +description = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out user accounts, potentially leading to further exploitation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike may use net.exe to enumerate domain users for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out user accounts, potentially leading to further exploitation or lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2023-06-13 -action.escu.modification_date = 2023-06-13 +action.escu.creation_date = 2024-05-27 +action.escu.modification_date = 2024-05-27 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Account Discovery With Net App - Rule action.escu.search_type = detection @@ -25990,11 +25873,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Account Discovery With Net App - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "Graceful Wipe Out Attack", "Rhysida Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "98f6a534-04c2-11ec-96b2-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "98f6a534-04c2-11ec-96b2-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike may use net.exe to enumerate domain users for situational awareness and Active Directory Discovery. +action.notable.param.rule_description = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query domain users. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an attempt by adversaries to enumerate domain users for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out user accounts, potentially leading to further exploitation or lateral movement within the network. action.notable.param.rule_title = Domain Account Discovery With Net App action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26059,14 +25942,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Controller Discovery with Nltest - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `nltest.exe` with command-line arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', can be used to return a list of all domain controllers. Red Teams and adversaries alike may use nltest.exe to identify domain controllers in a Windows Domain for situational awareness and Active Directory Discovery. +description = The following analytic detects the execution of `nltest.exe` with command-line arguments `/dclist:` or `/dsgetdc:` to discover domain controllers. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `nltest.exe` for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out domain controllers, facilitating further attacks such as privilege escalation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `nltest.exe` with command-line arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', can be used to return a list of all domain controllers. Red Teams and adversaries alike may use nltest.exe to identify domain controllers in a Windows Domain for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic detects the execution of `nltest.exe` with command-line arguments `/dclist:` or `/dsgetdc:` to discover domain controllers. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `nltest.exe` for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out domain controllers, facilitating further attacks such as privilege escalation or lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Controller Discovery with Nltest - Rule action.escu.search_type = detection @@ -26084,11 +25967,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Controller Discovery with Nltest - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "CISA AA23-347A", "Rhysida Ransomware"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "41243735-89a7-4c83-bcdd-570aa78f00a1", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "41243735-89a7-4c83-bcdd-570aa78f00a1", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic looks for the execution of `nltest.exe` with command-line arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', can be used to return a list of all domain controllers. Red Teams and adversaries alike may use nltest.exe to identify domain controllers in a Windows Domain for situational awareness and Active Directory Discovery. +action.notable.param.rule_description = The following analytic detects the execution of `nltest.exe` with command-line arguments `/dclist:` or `/dsgetdc:` to discover domain controllers. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `nltest.exe` for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out domain controllers, facilitating further attacks such as privilege escalation or lateral movement within the network. action.notable.param.rule_title = Domain Controller Discovery with Nltest action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26106,14 +25989,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Controller Discovery with Wmic - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command line return a list of all domain controllers in a Windows domain. Red Teams and adversaries alike use *.exe to identify remote systems for situational awareness and Active Directory Discovery. +description = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to discover domain controllers in a Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it is commonly used by adversaries and Red Teams for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the network, identify key systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command line return a list of all domain controllers in a Windows domain. Red Teams and adversaries alike use *.exe to identify remote systems for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to discover domain controllers in a Windows domain. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it is commonly used by adversaries and Red Teams for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the network, identify key systems, and plan further attacks, potentially leading to unauthorized access and data exfiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Controller Discovery with Wmic - Rule action.escu.search_type = detection @@ -26126,7 +26009,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Controller Discovery with Wmic - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "64c7adaa-48ee-483c-b0d6-7175bc65e6cc", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "64c7adaa-48ee-483c-b0d6-7175bc65e6cc", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26142,14 +26025,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Group Discovery with Adsisearcher - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain groups for situational awareness and Active Directory Discovery. +description = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain groups. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `[adsisearcher]` and group-related queries. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain groups for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain groups for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain groups. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `[adsisearcher]` and group-related queries. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain groups for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Administrators or power users may use Adsisearcher for troubleshooting. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Group Discovery with Adsisearcher - Rule action.escu.search_type = detection @@ -26167,11 +26050,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Group Discovery with Adsisearcher - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 60, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "089c862f-5f83-49b5-b1c8-7e4ff66560c7", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "089c862f-5f83-49b5-b1c8-7e4ff66560c7", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain groups for situational awareness and Active Directory Discovery. +action.notable.param.rule_description = The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell to query Active Directory for domain groups. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `[adsisearcher]` and group-related queries. This activity is significant as it may indicate an attempt by adversaries or Red Teams to enumerate domain groups for situational awareness and Active Directory discovery. If confirmed malicious, this behavior could lead to further reconnaissance, privilege escalation, or lateral movement within the network. action.notable.param.rule_title = Domain Group Discovery with Adsisearcher action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26189,14 +26072,14 @@ search = `powershell` (ScriptBlockText = "*[adsisearcher]*" AND ScriptBlockText [ESCU - Domain Group Discovery With Dsquery - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to query for domain groups. The argument `group`, returns a list of all domain groups. Red Teams and adversaries alike use may leverage dsquery.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +description = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to query for domain groups. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `dsquery.exe` to enumerate domain groups, gaining situational awareness and facilitating further Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the domain structure, identify high-value targets, and plan subsequent attacks, potentially leading to privilege escalation or data exfiltration. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to query for domain groups. The argument `group`, returns a list of all domain groups. Red Teams and adversaries alike use may leverage dsquery.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic identifies the execution of `dsquery.exe` with command-line arguments used to query for domain groups. It leverages Endpoint Detection and Response (EDR) data, focusing on process names and command-line arguments. This activity is significant because both Red Teams and adversaries use `dsquery.exe` to enumerate domain groups, gaining situational awareness and facilitating further Active Directory discovery. If confirmed malicious, this behavior could allow attackers to map out the domain structure, identify high-value targets, and plan subsequent attacks, potentially leading to privilege escalation or data exfiltration. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-09-01 -action.escu.modification_date = 2021-09-01 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Group Discovery With Dsquery - Rule action.escu.search_type = detection @@ -26209,7 +26092,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Group Discovery With Dsquery - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 50, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f0c9d62f-a232-4edd-b17e-bc409fb133d4", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f0c9d62f-a232-4edd-b17e-bc409fb133d4", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26225,14 +26108,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Group Discovery With Net - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `net.exe` with command-line arguments utilized to query for domain groups. The argument `group /domain`, returns a list of all domain groups. Red Teams and adversaries alike use net.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +description = The following analytic identifies the execution of `net.exe` with command-line arguments used to query domain groups, specifically `group /domain`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain groups, which is a common step in Active Directory Discovery. If confirmed malicious, this behavior could allow attackers to gain insights into the domain structure, aiding in further attacks such as privilege escalation or lateral movement. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `net.exe` with command-line arguments utilized to query for domain groups. The argument `group /domain`, returns a list of all domain groups. Red Teams and adversaries alike use net.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic identifies the execution of `net.exe` with command-line arguments used to query domain groups, specifically `group /domain`. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant as it indicates potential reconnaissance efforts by adversaries to enumerate domain groups, which is a common step in Active Directory Discovery. If confirmed malicious, this behavior could allow attackers to gain insights into the domain structure, aiding in further attacks such as privilege escalation or lateral movement. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2023-06-13 -action.escu.modification_date = 2023-06-13 +action.escu.creation_date = 2024-05-28 +action.escu.modification_date = 2024-05-28 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Group Discovery With Net - Rule action.escu.search_type = detection @@ -26245,7 +26128,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Group Discovery With Net - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "Graceful Wipe Out Attack", "Prestige Ransomware", "Rhysida Ransomware", "Windows Post-Exploitation"], "cis20": ["CIS 10"], "confidence": 50, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2f14ac7-fa81-471a-80d5-7eb65c3c7349", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f2f14ac7-fa81-471a-80d5-7eb65c3c7349", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26261,14 +26144,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Domain Group Discovery With Wmic - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for domain groups. The arguments utilized in this command return a list of all domain groups. Red Teams and adversaries alike use wmic.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +description = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to query for domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to gain situational awareness and map out Active Directory structures. If confirmed malicious, this behavior could allow attackers to identify and target specific domain groups, potentially leading to privilege escalation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for domain groups. The arguments utilized in this command return a list of all domain groups. Red Teams and adversaries alike use wmic.exe to enumerate domain groups for situational awareness and Active Directory Discovery. +action.escu.eli5 = The following analytic identifies the execution of `wmic.exe` with command-line arguments used to query for domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to gain situational awareness and map out Active Directory structures. If confirmed malicious, this behavior could allow attackers to identify and target specific domain groups, potentially leading to privilege escalation or lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-08-25 -action.escu.modification_date = 2021-08-25 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Domain Group Discovery With Wmic - Rule action.escu.search_type = detection @@ -26281,7 +26164,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Domain Group Discovery With Wmic - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 50, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a87736a6-95cd-4728-8689-3c64d5026b3e", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a87736a6-95cd-4728-8689-3c64d5026b3e", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26297,14 +26180,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Download Files Using Telegram - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic will identify a suspicious download by the Telegram application on a Windows system. This behavior was identified on a honeypot where the adversary gained access, installed Telegram and followed through with downloading different network scanners (port, bruteforcer, masscan) to the system and later used to mapped the whole network and further move laterally. +description = The following analytic detects suspicious file downloads by the Telegram application on a Windows system. It leverages Sysmon EventCode 15 to identify instances where Telegram.exe creates files with a Zone.Identifier, indicating a download. This activity is significant as it may indicate an adversary using Telegram to download malicious tools, such as network scanners, for further exploitation. If confirmed malicious, this behavior could lead to network mapping, lateral movement, and potential compromise of additional systems within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic will identify a suspicious download by the Telegram application on a Windows system. This behavior was identified on a honeypot where the adversary gained access, installed Telegram and followed through with downloading different network scanners (port, bruteforcer, masscan) to the system and later used to mapped the whole network and further move laterally. +action.escu.eli5 = The following analytic detects suspicious file downloads by the Telegram application on a Windows system. It leverages Sysmon EventCode 15 to identify instances where Telegram.exe creates files with a Zone.Identifier, indicating a download. This activity is significant as it may indicate an adversary using Telegram to download malicious tools, such as network scanners, for further exploitation. If confirmed malicious, this behavior could lead to network mapping, lateral movement, and potential compromise of additional systems within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and TargetFilename from your endpoints or Events that monitor filestream events which is happened when process download something. (EventCode 15) If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = normal download of file in telegram app. (if it was a common app in network) -action.escu.creation_date = 2021-05-06 -action.escu.modification_date = 2021-05-06 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Download Files Using Telegram - Rule action.escu.search_type = detection @@ -26322,11 +26205,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Download Files Using Telegram - Rule action.correlationsearch.annotations = {"analytic_story": ["Phemedrone Stealer", "Snake Keylogger", "XMRig"], "cis20": ["CIS 10"], "confidence": 70, "impact": 70, "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "58194e28-ae5e-11eb-8912-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "58194e28-ae5e-11eb-8912-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic will identify a suspicious download by the Telegram application on a Windows system. This behavior was identified on a honeypot where the adversary gained access, installed Telegram and followed through with downloading different network scanners (port, bruteforcer, masscan) to the system and later used to mapped the whole network and further move laterally. +action.notable.param.rule_description = The following analytic detects suspicious file downloads by the Telegram application on a Windows system. It leverages Sysmon EventCode 15 to identify instances where Telegram.exe creates files with a Zone.Identifier, indicating a download. This activity is significant as it may indicate an adversary using Telegram to download malicious tools, such as network scanners, for further exploitation. If confirmed malicious, this behavior could lead to network mapping, lateral movement, and potential compromise of additional systems within the network. action.notable.param.rule_title = Download Files Using Telegram action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26344,14 +26227,14 @@ search = `sysmon` EventCode= 15 process_name = "telegram.exe" TargetFilename = " [ESCU - Drop IcedID License dat - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect dropping a suspicious file named as "license.dat" in %appdata%. This behavior seen in latest IcedID malware that contain the actual core bot that will be injected in other process to do banking stealing. +description = The following analytic detects the dropping of a suspicious file named "license.dat" in %appdata% or %programdata%. This behavior is associated with the IcedID malware, which uses this file to inject its core bot into other processes for banking credential theft. The detection leverages Sysmon EventCode 11 to monitor file creation events in these directories. This activity is significant as it indicates a potential malware infection aiming to steal sensitive banking information. If confirmed malicious, the attacker could gain unauthorized access to financial data, leading to significant financial loss and data breaches. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect dropping a suspicious file named as "license.dat" in %appdata%. This behavior seen in latest IcedID malware that contain the actual core bot that will be injected in other process to do banking stealing. +action.escu.eli5 = The following analytic detects the dropping of a suspicious file named "license.dat" in %appdata% or %programdata%. This behavior is associated with the IcedID malware, which uses this file to inject its core bot into other processes for banking credential theft. The detection leverages Sysmon EventCode 11 to monitor file creation events in these directories. This activity is significant as it indicates a potential malware infection aiming to steal sensitive banking information. If confirmed malicious, the attacker could gain unauthorized access to financial data, leading to significant financial loss and data breaches. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-07-30 -action.escu.modification_date = 2021-07-30 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Drop IcedID License dat - Rule action.escu.search_type = detection @@ -26364,7 +26247,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Drop IcedID License dat - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID"], "cis20": ["CIS 10"], "confidence": 90, "impact": 70, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b7a045fc-f14a-11eb-8e79-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b7a045fc-f14a-11eb-8e79-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26380,24 +26263,14 @@ search = `sysmon` EventCode= 11 TargetFilename = "*\\license.dat" AND (TargetFi [ESCU - DSQuery Domain Discovery - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies "dsquery.exe" execution with arguments looking for `TrustedDomain` query directly on the command-line. This is typically indicative of an Administrator or adversary perform domain trust discovery. Note that this query does not identify any other variations of "Dsquery.exe" usage. \ -Within this detection, it is assumed `dsquery.exe` is not moved or renamed. \ -The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "dsquery.exe" and its parent process. \ -DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` and only on Server operating system. \ -The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found loaded by another process, it is possible dsquery is running within that process context in memory. \ -In addition to trust discovery, review parallel processes for additional behaviors performed. Identify the parent process and capture any files (batch files, for example) being used. +description = The following analytic detects the execution of "dsquery.exe" with arguments targeting `TrustedDomain` queries directly from the command line. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line arguments. This activity is significant as it often indicates domain trust discovery, a common step in lateral movement or privilege escalation by adversaries. If confirmed malicious, this could allow attackers to map domain trusts, potentially leading to further exploitation and unauthorized access to trusted domains. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies "dsquery.exe" execution with arguments looking for `TrustedDomain` query directly on the command-line. This is typically indicative of an Administrator or adversary perform domain trust discovery. Note that this query does not identify any other variations of "Dsquery.exe" usage. \ -Within this detection, it is assumed `dsquery.exe` is not moved or renamed. \ -The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "dsquery.exe" and its parent process. \ -DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` and only on Server operating system. \ -The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found loaded by another process, it is possible dsquery is running within that process context in memory. \ -In addition to trust discovery, review parallel processes for additional behaviors performed. Identify the parent process and capture any files (batch files, for example) being used. +action.escu.eli5 = The following analytic detects the execution of "dsquery.exe" with arguments targeting `TrustedDomain` queries directly from the command line. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line arguments. This activity is significant as it often indicates domain trust discovery, a common step in lateral movement or privilege escalation by adversaries. If confirmed malicious, this could allow attackers to map domain trusts, potentially leading to further exploitation and unauthorized access to trusted domains. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Limited false positives. If there is a true false positive, filter based on command-line or parent process. -action.escu.creation_date = 2021-03-31 -action.escu.modification_date = 2021-03-31 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - DSQuery Domain Discovery - Rule action.escu.search_type = detection @@ -26415,16 +26288,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - DSQuery Domain Discovery - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "Domain Trust Discovery"], "cis20": ["CIS 10"], "confidence": 90, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc316032-924a-11eb-91a2-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cc316032-924a-11eb-91a2-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies "dsquery.exe" execution with arguments looking for `TrustedDomain` query directly on the command-line. This is typically indicative of an Administrator or adversary perform domain trust discovery. Note that this query does not identify any other variations of "Dsquery.exe" usage. \ -Within this detection, it is assumed `dsquery.exe` is not moved or renamed. \ -The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "dsquery.exe" and its parent process. \ -DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` and only on Server operating system. \ -The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found loaded by another process, it is possible dsquery is running within that process context in memory. \ -In addition to trust discovery, review parallel processes for additional behaviors performed. Identify the parent process and capture any files (batch files, for example) being used. +action.notable.param.rule_description = The following analytic detects the execution of "dsquery.exe" with arguments targeting `TrustedDomain` queries directly from the command line. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line arguments. This activity is significant as it often indicates domain trust discovery, a common step in lateral movement or privilege escalation by adversaries. If confirmed malicious, this could allow attackers to map domain trusts, potentially leading to further exploitation and unauthorized access to trusted domains. action.notable.param.rule_title = DSQuery Domain Discovery action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26442,14 +26310,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Dump LSASS via comsvcs DLL - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source. +description = The following analytic detects the behavior of dumping credentials from memory by exploiting the Local Security Authority Subsystem Service (LSASS) using the comsvcs.dll and MiniDump via rundll32. This detection leverages process information from Endpoint Detection and Response (EDR) logs, focusing on specific command-line executions. This activity is significant because it indicates potential credential theft, which can lead to broader system compromise, persistence, lateral movement, and privilege escalation. If confirmed malicious, attackers could gain unauthorized access to sensitive information, leading to data theft, ransomware attacks, or other damaging outcomes. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source. +action.escu.eli5 = The following analytic detects the behavior of dumping credentials from memory by exploiting the Local Security Authority Subsystem Service (LSASS) using the comsvcs.dll and MiniDump via rundll32. This detection leverages process information from Endpoint Detection and Response (EDR) logs, focusing on specific command-line executions. This activity is significant because it indicates potential credential theft, which can lead to broader system compromise, persistence, lateral movement, and privilege escalation. If confirmed malicious, attackers could gain unauthorized access to sensitive information, leading to data theft, ransomware attacks, or other damaging outcomes. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = None identified. -action.escu.creation_date = 2023-04-14 -action.escu.modification_date = 2023-04-14 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Dump LSASS via comsvcs DLL - Rule action.escu.search_type = detection @@ -26467,11 +26335,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Dump LSASS via comsvcs DLL - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-257A", "CISA AA22-264A", "Credential Dumping", "Data Destruction", "Flax Typhoon", "HAFNIUM Group", "Industroyer2", "Living Off The Land", "Prestige Ransomware", "Suspicious Rundll32 Activity", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8943b567-f14d-4ee8-a0bb-2121d4ce3184", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8943b567-f14d-4ee8-a0bb-2121d4ce3184", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source. +action.notable.param.rule_description = The following analytic detects the behavior of dumping credentials from memory by exploiting the Local Security Authority Subsystem Service (LSASS) using the comsvcs.dll and MiniDump via rundll32. This detection leverages process information from Endpoint Detection and Response (EDR) logs, focusing on specific command-line executions. This activity is significant because it indicates potential credential theft, which can lead to broader system compromise, persistence, lateral movement, and privilege escalation. If confirmed malicious, attackers could gain unauthorized access to sensitive information, leading to data theft, ransomware attacks, or other damaging outcomes. action.notable.param.rule_title = Dump LSASS via comsvcs DLL action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26489,16 +26357,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Dump LSASS via procdump - Rule] action.escu = 0 action.escu.enabled = 1 -description = Detect procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. This query does not monitor for the internal name (original_file_name=procdump) of the PE or look for procdump64.exe. Modify the query as needed. \ -During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe. +description = The following analytic detects the use of procdump.exe to dump the LSASS process, specifically looking for the -mm and -ma command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant because dumping LSASS can expose sensitive credentials, posing a severe security risk. If confirmed malicious, an attacker could obtain credentials, escalate privileges, and move laterally within the network, leading to potential data breaches and further compromise of the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = Detect procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. This query does not monitor for the internal name (original_file_name=procdump) of the PE or look for procdump64.exe. Modify the query as needed. \ -During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe. +action.escu.eli5 = The following analytic detects the use of procdump.exe to dump the LSASS process, specifically looking for the -mm and -ma command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant because dumping LSASS can expose sensitive credentials, posing a severe security risk. If confirmed malicious, an attacker could obtain credentials, escalate privileges, and move laterally within the network, leading to potential data breaches and further compromise of the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = None identified. -action.escu.creation_date = 2022-08-31 -action.escu.modification_date = 2022-08-31 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Dump LSASS via procdump - Rule action.escu.search_type = detection @@ -26516,12 +26382,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Dump LSASS via procdump - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-257A", "Credential Dumping", "HAFNIUM Group"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3742ebfe-64c2-11eb-ae93-0242ac130002", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3742ebfe-64c2-11eb-ae93-0242ac130002", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = Detect procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. This query does not monitor for the internal name (original_file_name=procdump) of the PE or look for procdump64.exe. Modify the query as needed. \ -During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe. +action.notable.param.rule_description = The following analytic detects the use of procdump.exe to dump the LSASS process, specifically looking for the -mm and -ma command-line arguments. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant because dumping LSASS can expose sensitive credentials, posing a severe security risk. If confirmed malicious, an attacker could obtain credentials, escalate privileges, and move laterally within the network, leading to potential data breaches and further compromise of the environment. action.notable.param.rule_title = Dump LSASS via procdump action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26539,14 +26404,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Elevated Group Discovery With Net - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for specific elevated domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +description = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query elevated domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within Active Directory. If confirmed malicious, this behavior could lead to further attacks aimed at compromising privileged accounts, escalating privileges, or gaining unauthorized access to sensitive systems and data. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for specific elevated domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +action.escu.eli5 = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query elevated domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within Active Directory. If confirmed malicious, this behavior could lead to further attacks aimed at compromising privileged accounts, escalating privileges, or gaining unauthorized access to sensitive systems and data. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-08-25 -action.escu.modification_date = 2021-08-25 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - Elevated Group Discovery With Net - Rule action.escu.search_type = detection @@ -26564,11 +26429,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Elevated Group Discovery With Net - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery", "Rhysida Ransomware", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a23a0e20-0b1b-4a07-82e5-ec5f70811e7a", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a23a0e20-0b1b-4a07-82e5-ec5f70811e7a", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for specific elevated domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +action.notable.param.rule_description = The following analytic detects the execution of `net.exe` or `net1.exe` with command-line arguments used to query elevated domain groups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within Active Directory. If confirmed malicious, this behavior could lead to further attacks aimed at compromising privileged accounts, escalating privileges, or gaining unauthorized access to sensitive systems and data. action.notable.param.rule_title = Elevated Group Discovery With Net action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26586,14 +26451,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Elevated Group Discovery with PowerView - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroupMember` commandlet. `Get-DomainGroupMember` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroupMember` is used to list the members of an specific domain group. Red Teams and adversaries alike use PowerView to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +description = The following analytic detects the execution of the `Get-DomainGroupMember` cmdlet from PowerView, identified through PowerShell Script Block Logging (EventCode=4104). This cmdlet is used to enumerate members of elevated domain groups such as Domain Admins and Enterprise Admins. Monitoring this activity is crucial as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within the domain. If confirmed malicious, this activity could lead to targeted attacks on privileged accounts, facilitating further compromise and lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroupMember` commandlet. `Get-DomainGroupMember` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroupMember` is used to list the members of an specific domain group. Red Teams and adversaries alike use PowerView to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +action.escu.eli5 = The following analytic detects the execution of the `Get-DomainGroupMember` cmdlet from PowerView, identified through PowerShell Script Block Logging (EventCode=4104). This cmdlet is used to enumerate members of elevated domain groups such as Domain Admins and Enterprise Admins. Monitoring this activity is crucial as it indicates potential reconnaissance efforts by adversaries to identify high-privileged users within the domain. If confirmed malicious, this activity could lead to targeted attacks on privileged accounts, facilitating further compromise and lateral movement within the network. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Administrators or power users may use this PowerView for troubleshooting. -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-06-10 +action.escu.modification_date = 2024-06-10 action.escu.confidence = high action.escu.full_search_name = ESCU - Elevated Group Discovery with PowerView - Rule action.escu.search_type = detection @@ -26606,7 +26471,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Elevated Group Discovery with PowerView - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10d62950-0de5-4199-a710-cff9ea79b413", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "10d62950-0de5-4199-a710-cff9ea79b413", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26617,19 +26482,19 @@ relation = greater than quantity = 0 realtime_schedule = 0 is_visible = false -search = `powershell` EventCode=4104 (Message = "*Get-DomainGroupMember*") AND Message IN ("*Domain Admins*","*Enterprise Admins*", "*Schema Admins*", "*Account Operators*" , "*Server Operators*", "*Protected Users*", "*Dns Admins*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | rename ComputerName as dest, User as user | `security_content_ctime(firstTime)` | `elevated_group_discovery_with_powerview_filter` +search = `powershell` EventCode=4104 (ScriptBlockText = "*Get-DomainGroupMember*") AND ScriptBlockText IN ("*Domain Admins*","*Enterprise Admins*", "*Schema Admins*", "*Account Operators*" , "*Server Operators*", "*Protected Users*", "*Dns Admins*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer UserID | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)` | `elevated_group_discovery_with_powerview_filter` [ESCU - Elevated Group Discovery With Wmic - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for specific domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +description = The following analytic detects the execution of `wmic.exe` with command-line arguments querying specific elevated domain groups. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes that access the LDAP namespace and search for groups like "Domain Admins" or "Enterprise Admins." This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privilege accounts within Active Directory. If confirmed malicious, this behavior could lead to privilege escalation, allowing attackers to gain elevated access and control over critical network resources. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for specific domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +action.escu.eli5 = The following analytic detects the execution of `wmic.exe` with command-line arguments querying specific elevated domain groups. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes that access the LDAP namespace and search for groups like "Domain Admins" or "Enterprise Admins." This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privilege accounts within Active Directory. If confirmed malicious, this behavior could lead to privilege escalation, allowing attackers to gain elevated access and control over critical network resources. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or power users may use this command for troubleshooting. -action.escu.creation_date = 2021-08-25 -action.escu.modification_date = 2021-08-25 +action.escu.creation_date = 2024-05-24 +action.escu.modification_date = 2024-05-24 action.escu.confidence = high action.escu.full_search_name = ESCU - Elevated Group Discovery With Wmic - Rule action.escu.search_type = detection @@ -26647,11 +26512,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Elevated Group Discovery With Wmic - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Discovery"], "cis20": ["CIS 10"], "confidence": 70, "impact": 30, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3f6bbf22-093e-4cb4-9641-83f47b8444b6", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "3f6bbf22-093e-4cb4-9641-83f47b8444b6", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for specific domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users. +action.notable.param.rule_description = The following analytic detects the execution of `wmic.exe` with command-line arguments querying specific elevated domain groups. It leverages Endpoint Detection and Response (EDR) telemetry to identify processes that access the LDAP namespace and search for groups like "Domain Admins" or "Enterprise Admins." This activity is significant as it indicates potential reconnaissance efforts by adversaries to identify high-privilege accounts within Active Directory. If confirmed malicious, this behavior could lead to privilege escalation, allowing attackers to gain elevated access and control over critical network resources. action.notable.param.rule_title = Elevated Group Discovery With Wmic action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26669,14 +26534,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Enable RDP In Other Port Number - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a modification to registry to enable rdp to a machine with different port number. This technique was seen in some atttacker tries to do lateral movement and remote access to a compromised machine to gain control of it. +description = The following analytic detects modifications to the registry that enable RDP on a machine using a non-default port number. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" and the "PortNumber" value. This activity is significant as attackers often modify RDP settings to facilitate lateral movement and maintain remote access to compromised systems. If confirmed malicious, this could allow attackers to bypass network defenses, gain persistent access, and potentially control the compromised machine. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search is to detect a modification to registry to enable rdp to a machine with different port number. This technique was seen in some atttacker tries to do lateral movement and remote access to a compromised machine to gain control of it. +action.escu.eli5 = The following analytic detects modifications to the registry that enable RDP on a machine using a non-default port number. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" and the "PortNumber" value. This activity is significant as attackers often modify RDP settings to facilitate lateral movement and maintain remote access to compromised systems. If confirmed malicious, this could allow attackers to bypass network defenses, gain persistent access, and potentially control the compromised machine. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-04-27 -action.escu.modification_date = 2023-04-27 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Enable RDP In Other Port Number - Rule action.escu.search_type = detection @@ -26694,11 +26559,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Enable RDP In Other Port Number - Rule action.correlationsearch.annotations = {"analytic_story": ["Prohibited Traffic Allowed or Protocol Mismatch", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "99495452-b899-11eb-96dc-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "99495452-b899-11eb-96dc-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search is to detect a modification to registry to enable rdp to a machine with different port number. This technique was seen in some atttacker tries to do lateral movement and remote access to a compromised machine to gain control of it. +action.notable.param.rule_description = The following analytic detects modifications to the registry that enable RDP on a machine using a non-default port number. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" and the "PortNumber" value. This activity is significant as attackers often modify RDP settings to facilitate lateral movement and maintain remote access to compromised systems. If confirmed malicious, this could allow attackers to bypass network defenses, gain persistent access, and potentially control the compromised machine. action.notable.param.rule_title = Enable RDP In Other Port Number action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26716,14 +26581,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Enable WDigest UseLogonCredential Registry - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic is to detect a suspicious registry modification to enable plain text credential feature of windows. This technique was used by several malware and also by mimikatz to be able to dumpe the a plain text credential to the compromised or target host. This TTP is really a good indicator that someone wants to dump the crendential of the host so it must be a good pivot for credential dumping techniques. +description = The following analytic detects a suspicious registry modification that enables the plain text credential feature in Windows by setting the "UseLogonCredential" value to 1 in the WDigest registry path. This detection leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because it is commonly used by malware and tools like Mimikatz to dump plain text credentials, indicating a potential credential dumping attempt. If confirmed malicious, this could allow an attacker to obtain sensitive credentials, leading to further compromise and lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic is to detect a suspicious registry modification to enable plain text credential feature of windows. This technique was used by several malware and also by mimikatz to be able to dumpe the a plain text credential to the compromised or target host. This TTP is really a good indicator that someone wants to dump the crendential of the host so it must be a good pivot for credential dumping techniques. +action.escu.eli5 = The following analytic detects a suspicious registry modification that enables the plain text credential feature in Windows by setting the "UseLogonCredential" value to 1 in the WDigest registry path. This detection leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because it is commonly used by malware and tools like Mimikatz to dump plain text credentials, indicating a potential credential dumping attempt. If confirmed malicious, this could allow an attacker to obtain sensitive credentials, leading to further compromise and lateral movement within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709 action.escu.known_false_positives = unknown -action.escu.creation_date = 2023-04-27 -action.escu.modification_date = 2023-04-27 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Enable WDigest UseLogonCredential Registry - Rule action.escu.search_type = detection @@ -26741,11 +26606,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Enable WDigest UseLogonCredential Registry - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-320A", "Credential Dumping", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0c7d8ffe-25b1-11ec-9f39-acde48001122", "detection_version": "4"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0c7d8ffe-25b1-11ec-9f39-acde48001122", "detection_version": "5"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic is to detect a suspicious registry modification to enable plain text credential feature of windows. This technique was used by several malware and also by mimikatz to be able to dumpe the a plain text credential to the compromised or target host. This TTP is really a good indicator that someone wants to dump the crendential of the host so it must be a good pivot for credential dumping techniques. +action.notable.param.rule_description = The following analytic detects a suspicious registry modification that enables the plain text credential feature in Windows by setting the "UseLogonCredential" value to 1 in the WDigest registry path. This detection leverages data from the Endpoint.Registry data model, focusing on specific registry paths and values. This activity is significant because it is commonly used by malware and tools like Mimikatz to dump plain text credentials, indicating a potential credential dumping attempt. If confirmed malicious, this could allow an attacker to obtain sensitive credentials, leading to further compromise and lateral movement within the network. action.notable.param.rule_title = Enable WDigest UseLogonCredential Registry action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26763,14 +26628,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Enumerate Users Local Group Using Telegram - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic will detect a suspicious Telegram process enumerating all network users in a local group. This technique was seen in a Monero infected honeypot to mapped all the users on the compromised system. EventCode 4798 is generated when a process enumerates a user's security-enabled local groups on a computer or device. +description = The following analytic detects a Telegram process enumerating all network users in a local group. It leverages EventCode 4798, which is generated when a process enumerates a user's security-enabled local groups on a computer or device. This activity is significant as it may indicate an attempt to gather information on user accounts, a common precursor to further malicious actions. If confirmed malicious, this behavior could allow an attacker to map out user accounts, potentially leading to privilege escalation or lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic will detect a suspicious Telegram process enumerating all network users in a local group. This technique was seen in a Monero infected honeypot to mapped all the users on the compromised system. EventCode 4798 is generated when a process enumerates a user's security-enabled local groups on a computer or device. +action.escu.eli5 = The following analytic detects a Telegram process enumerating all network users in a local group. It leverages EventCode 4798, which is generated when a process enumerates a user's security-enabled local groups on a computer or device. This activity is significant as it may indicate an attempt to gather information on user accounts, a common precursor to further malicious actions. If confirmed malicious, this behavior could allow an attacker to map out user accounts, potentially leading to privilege escalation or lateral movement within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the Task Schedule (Exa. Security Log EventCode 4798) endpoints. Tune and filter known instances of process like logonUI used in your environment. action.escu.known_false_positives = unknown -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Enumerate Users Local Group Using Telegram - Rule action.escu.search_type = detection @@ -26788,11 +26653,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Enumerate Users Local Group Using Telegram - Rule action.correlationsearch.annotations = {"analytic_story": ["XMRig"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fcd74532-ae54-11eb-a5ab-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "fcd74532-ae54-11eb-a5ab-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic will detect a suspicious Telegram process enumerating all network users in a local group. This technique was seen in a Monero infected honeypot to mapped all the users on the compromised system. EventCode 4798 is generated when a process enumerates a user's security-enabled local groups on a computer or device. +action.notable.param.rule_description = The following analytic detects a Telegram process enumerating all network users in a local group. It leverages EventCode 4798, which is generated when a process enumerates a user's security-enabled local groups on a computer or device. This activity is significant as it may indicate an attempt to gather information on user accounts, a common precursor to further malicious actions. If confirmed malicious, this behavior could allow an attacker to map out user accounts, potentially leading to privilege escalation or lateral movement within the network. action.notable.param.rule_title = Enumerate Users Local Group Using Telegram action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26810,14 +26675,14 @@ search = `wineventlog_security` EventCode=4798 CallerProcessName = "*\\telegram [ESCU - Esentutl SAM Copy - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the process - `esentutl.exe` - being used to capture credentials stored in ntds.dit or the SAM file on disk. During triage, review parallel processes and determine if legitimate activity. Upon determination of illegitimate activity, take further action to isolate and contain the threat. +description = The following analytic detects the use of `esentutl.exe` to access credentials stored in the ntds.dit or SAM file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it may indicate an attempt to extract sensitive credential information, which is a common tactic in lateral movement and privilege escalation. If confirmed malicious, this could allow an attacker to gain unauthorized access to user credentials, potentially compromising the entire network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the process - `esentutl.exe` - being used to capture credentials stored in ntds.dit or the SAM file on disk. During triage, review parallel processes and determine if legitimate activity. Upon determination of illegitimate activity, take further action to isolate and contain the threat. +action.escu.eli5 = The following analytic detects the use of `esentutl.exe` to access credentials stored in the ntds.dit or SAM file. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process execution logs that include command-line details. This activity is significant because it may indicate an attempt to extract sensitive credential information, which is a common tactic in lateral movement and privilege escalation. If confirmed malicious, this could allow an attacker to gain unauthorized access to user credentials, potentially compromising the entire network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited. Filter as needed. -action.escu.creation_date = 2021-08-18 -action.escu.modification_date = 2021-08-18 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Esentutl SAM Copy - Rule action.escu.search_type = detection @@ -26830,7 +26695,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Esentutl SAM Copy - Rule action.correlationsearch.annotations = {"analytic_story": ["Credential Dumping", "Living Off The Land"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"], "type": "Hunting"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d372f928-ce4f-11eb-a762-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "d372f928-ce4f-11eb-a762-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -26893,14 +26758,14 @@ search = | tstats `security_content_summariesonly` count FROM datamodel=Endpoint [ESCU - Eventvwr UAC Bypass - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following search identifies Eventvwr bypass by identifying the registry modification into a specific path that eventvwr.msc looks to (but is not valid) upon execution. A successful attack will include a suspicious command to be executed upon eventvwr.msc loading. Upon triage, review the parallel processes that have executed. Identify any additional registry modifications on the endpoint that may look suspicious. Remediate as necessary. +description = The following analytic detects an Eventvwr UAC bypass by identifying suspicious registry modifications in the path that Eventvwr.msc references upon execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry changes and process execution details. This activity is significant because it indicates a potential privilege escalation attempt, allowing an attacker to execute arbitrary commands with elevated privileges. If confirmed malicious, this could lead to unauthorized code execution, persistence, and further compromise of the affected system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following search identifies Eventvwr bypass by identifying the registry modification into a specific path that eventvwr.msc looks to (but is not valid) upon execution. A successful attack will include a suspicious command to be executed upon eventvwr.msc loading. Upon triage, review the parallel processes that have executed. Identify any additional registry modifications on the endpoint that may look suspicious. Remediate as necessary. +action.escu.eli5 = The following analytic detects an Eventvwr UAC bypass by identifying suspicious registry modifications in the path that Eventvwr.msc references upon execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry changes and process execution details. This activity is significant because it indicates a potential privilege escalation attempt, allowing an attacker to execute arbitrary commands with elevated privileges. If confirmed malicious, this could lead to unauthorized code execution, persistence, and further compromise of the affected system. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Some false positives may be present and will need to be filtered. -action.escu.creation_date = 2022-11-14 -action.escu.modification_date = 2022-11-14 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Eventvwr UAC Bypass - Rule action.escu.search_type = detection @@ -26918,11 +26783,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Eventvwr UAC Bypass - Rule action.correlationsearch.annotations = {"analytic_story": ["IcedID", "Living Off The Land", "Windows Defense Evasion Tactics", "Windows Registry Abuse"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9cf8fe08-7ad8-11eb-9819-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9cf8fe08-7ad8-11eb-9819-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following search identifies Eventvwr bypass by identifying the registry modification into a specific path that eventvwr.msc looks to (but is not valid) upon execution. A successful attack will include a suspicious command to be executed upon eventvwr.msc loading. Upon triage, review the parallel processes that have executed. Identify any additional registry modifications on the endpoint that may look suspicious. Remediate as necessary. +action.notable.param.rule_description = The following analytic detects an Eventvwr UAC bypass by identifying suspicious registry modifications in the path that Eventvwr.msc references upon execution. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on registry changes and process execution details. This activity is significant because it indicates a potential privilege escalation attempt, allowing an attacker to execute arbitrary commands with elevated privileges. If confirmed malicious, this could lead to unauthorized code execution, persistence, and further compromise of the affected system. action.notable.param.rule_title = Eventvwr UAC Bypass action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26940,14 +26805,14 @@ search = | tstats `security_content_summariesonly` count min(_time) AS firstTime [ESCU - Excel Spawning PowerShell - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies Microsoft Excel spawning PowerShell. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written. +description = The following analytic detects Microsoft Excel spawning PowerShell, an uncommon and suspicious behavior. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is "excel.exe" and the child process is PowerShell. This activity is significant because it is often associated with spearphishing attacks, where malicious attachments execute encoded PowerShell commands. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to data exfiltration, privilege escalation, or persistent access within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following detection identifies Microsoft Excel spawning PowerShell. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written. +action.escu.eli5 = The following analytic detects Microsoft Excel spawning PowerShell, an uncommon and suspicious behavior. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is "excel.exe" and the child process is PowerShell. This activity is significant because it is often associated with spearphishing attacks, where malicious attachments execute encoded PowerShell commands. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to data exfiltration, privilege escalation, or persistent access within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited, but if any are present, filter as needed. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Excel Spawning PowerShell - Rule action.escu.search_type = detection @@ -26965,11 +26830,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excel Spawning PowerShell - Rule action.correlationsearch.annotations = {"analytic_story": ["Spearphishing Attachments"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "42d40a22-9be3-11eb-8f08-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "42d40a22-9be3-11eb-8f08-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following detection identifies Microsoft Excel spawning PowerShell. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written. +action.notable.param.rule_description = The following analytic detects Microsoft Excel spawning PowerShell, an uncommon and suspicious behavior. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where the parent process is "excel.exe" and the child process is PowerShell. This activity is significant because it is often associated with spearphishing attacks, where malicious attachments execute encoded PowerShell commands. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, potentially leading to data exfiltration, privilege escalation, or persistent access within the environment. action.notable.param.rule_title = Excel Spawning PowerShell action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -26987,14 +26852,14 @@ search = | tstats `security_content_summariesonly` count values(Processes.proces [ESCU - Excel Spawning Windows Script Host - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following detection identifies Microsoft Excel spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly. +description = The following analytic identifies instances where Microsoft Excel spawns Windows Script Host processes (`cscript.exe` or `wscript.exe`). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is `excel.exe`. This activity is significant because it is uncommon and often associated with malicious actions, such as spearphishing attacks. If confirmed malicious, this could allow an attacker to execute scripts, potentially leading to code execution, data exfiltration, or further system compromise. Immediate investigation and mitigation are recommended. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following detection identifies Microsoft Excel spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly. +action.escu.eli5 = The following analytic identifies instances where Microsoft Excel spawns Windows Script Host processes (`cscript.exe` or `wscript.exe`). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is `excel.exe`. This activity is significant because it is uncommon and often associated with malicious actions, such as spearphishing attacks. If confirmed malicious, this could allow an attacker to execute scripts, potentially leading to code execution, data exfiltration, or further system compromise. Immediate investigation and mitigation are recommended. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = False positives should be limited, but if any are present, filter as needed. In some instances, `cscript.exe` is used for legitimate business practices. -action.escu.creation_date = 2023-11-07 -action.escu.modification_date = 2023-11-07 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Excel Spawning Windows Script Host - Rule action.escu.search_type = detection @@ -27012,11 +26877,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excel Spawning Windows Script Host - Rule action.correlationsearch.annotations = {"analytic_story": ["Spearphishing Attachments"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "57fe880a-9be3-11eb-9bf3-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "57fe880a-9be3-11eb-9bf3-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following detection identifies Microsoft Excel spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly. +action.notable.param.rule_description = The following analytic identifies instances where Microsoft Excel spawns Windows Script Host processes (`cscript.exe` or `wscript.exe`). This behavior is detected using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the parent process is `excel.exe`. This activity is significant because it is uncommon and often associated with malicious actions, such as spearphishing attacks. If confirmed malicious, this could allow an attacker to execute scripts, potentially leading to code execution, data exfiltration, or further system compromise. Immediate investigation and mitigation are recommended. action.notable.param.rule_title = Excel Spawning Windows Script Host action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27075,14 +26940,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Excessive distinct processes from Windows Temp - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic will identify suspicious series of process executions. We have observed that post exploit framework tools like Koadic and Meterpreter will launch an excessive number of processes with distinct file paths from Windows\Temp to execute actions on objective. This behavior is extremely anomalous compared to typical application behaviors that use Windows\Temp. +description = The following analytic identifies an excessive number of distinct processes executing from the Windows\Temp directory. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process paths and counts within a 20-minute window. This behavior is significant as it often indicates the presence of post-exploit frameworks like Koadic and Meterpreter, which use this technique to execute malicious actions. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, and maintain persistence within the environment, posing a severe threat to system integrity and security. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic will identify suspicious series of process executions. We have observed that post exploit framework tools like Koadic and Meterpreter will launch an excessive number of processes with distinct file paths from Windows\Temp to execute actions on objective. This behavior is extremely anomalous compared to typical application behaviors that use Windows\Temp. +action.escu.eli5 = The following analytic identifies an excessive number of distinct processes executing from the Windows\Temp directory. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process paths and counts within a 20-minute window. This behavior is significant as it often indicates the presence of post-exploit frameworks like Koadic and Meterpreter, which use this technique to execute malicious actions. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, and maintain persistence within the environment, posing a severe threat to system integrity and security. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Many benign applications will create processes from executables in Windows\Temp, although unlikely to exceed the given threshold. Filter as needed. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-29 +action.escu.modification_date = 2024-05-29 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive distinct processes from Windows Temp - Rule action.escu.search_type = detection @@ -27100,7 +26965,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive distinct processes from Windows Temp - Rule action.correlationsearch.annotations = {"analytic_story": ["Meterpreter"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "23587b6a-c479-11eb-b671-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "23587b6a-c479-11eb-b671-acde48001122", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27116,14 +26981,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Excessive File Deletion In WinDefender Folder - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies excessive file deletion events in the Windows Defender folder. This technique was observed in the WhisperGate malware campaign, where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges and then executed PowerShell commands to delete files within the Windows Defender application folder. Such behavior is a strong indicator that the offending process is attempting to corrupt a Windows Defender installation. +description = The following analytic detects excessive file deletion events in the Windows Defender folder. It leverages Sysmon EventCodes 23 and 26 to identify processes deleting multiple files within this directory. This behavior is significant as it may indicate an attempt to corrupt or disable Windows Defender, a key security component. If confirmed malicious, this activity could allow an attacker to disable endpoint protection, facilitating further malicious actions without detection. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies excessive file deletion events in the Windows Defender folder. This technique was observed in the WhisperGate malware campaign, where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges and then executed PowerShell commands to delete files within the Windows Defender application folder. Such behavior is a strong indicator that the offending process is attempting to corrupt a Windows Defender installation. +action.escu.eli5 = The following analytic detects excessive file deletion events in the Windows Defender folder. It leverages Sysmon EventCodes 23 and 26 to identify processes deleting multiple files within this directory. This behavior is significant as it may indicate an attempt to corrupt or disable Windows Defender, a key security component. If confirmed malicious, this activity could allow an attacker to disable endpoint protection, facilitating further malicious actions without detection. action.escu.how_to_implement = To successfully implement this search, you must ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are utilizing Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed. action.escu.known_false_positives = Windows Defender AV updates may trigger this alert. Please adjust the filter macros to mitigate false positives. -action.escu.creation_date = 2024-03-05 -action.escu.modification_date = 2024-03-05 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive File Deletion In WinDefender Folder - Rule action.escu.search_type = detection @@ -27141,11 +27006,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive File Deletion In WinDefender Folder - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Data Destruction", "WhisperGate"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b5baa09a-7a05-11ec-8da4-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b5baa09a-7a05-11ec-8da4-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies excessive file deletion events in the Windows Defender folder. This technique was observed in the WhisperGate malware campaign, where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges and then executed PowerShell commands to delete files within the Windows Defender application folder. Such behavior is a strong indicator that the offending process is attempting to corrupt a Windows Defender installation. +action.notable.param.rule_description = The following analytic detects excessive file deletion events in the Windows Defender folder. It leverages Sysmon EventCodes 23 and 26 to identify processes deleting multiple files within this directory. This behavior is significant as it may indicate an attempt to corrupt or disable Windows Defender, a key security component. If confirmed malicious, this activity could allow an attacker to disable endpoint protection, facilitating further malicious actions without detection. action.notable.param.rule_title = Excessive File Deletion In WinDefender Folder action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27163,14 +27028,14 @@ search = `sysmon` EventCode IN ("23","26") TargetFilename = "*\\ProgramData\\Mic [ESCU - Excessive number of service control start as disabled - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection targets behaviors observed when threat actors have used sc.exe to modify services. We observed malware in a honey pot spawning numerous sc.exe processes in a short period of time, presumably to impair defenses, possibly to block others from compromising the same machine. This detection will alert when we see both an excessive number of sc.exe processes launched with specific commandline arguments to disable the start of certain services. +description = The following analytic detects an excessive number of `sc.exe` processes launched with the command line argument `start= disabled` within a short period. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and process GUIDs. This activity is significant as it may indicate an attempt to disable critical services, potentially impairing system defenses. If confirmed malicious, this behavior could allow an attacker to disrupt security mechanisms, hinder incident response, and maintain control over the compromised system. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This detection targets behaviors observed when threat actors have used sc.exe to modify services. We observed malware in a honey pot spawning numerous sc.exe processes in a short period of time, presumably to impair defenses, possibly to block others from compromising the same machine. This detection will alert when we see both an excessive number of sc.exe processes launched with specific commandline arguments to disable the start of certain services. +action.escu.eli5 = The following analytic detects an excessive number of `sc.exe` processes launched with the command line argument `start= disabled` within a short period. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and process GUIDs. This activity is significant as it may indicate an attempt to disable critical services, potentially impairing system defenses. If confirmed malicious, this behavior could allow an attacker to disrupt security mechanisms, hinder incident response, and maintain control over the compromised system. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Legitimate programs and administrators will execute sc.exe with the start disabled flag. It is possible, but unlikely from the telemetry of normal Windows operation we observed, that sc.exe will be called more than seven times in a short period of time. -action.escu.creation_date = 2021-06-25 -action.escu.modification_date = 2021-06-25 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive number of service control start as disabled - Rule action.escu.search_type = detection @@ -27188,7 +27053,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive number of service control start as disabled - Rule action.correlationsearch.annotations = {"analytic_story": ["Windows Defense Evasion Tactics"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "77592bec-d5cc-11eb-9e60-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "77592bec-d5cc-11eb-9e60-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27204,14 +27069,14 @@ search = | tstats `security_content_summariesonly` distinct_count(Processes.proc [ESCU - Excessive number of taskhost processes - Rule] action.escu = 0 action.escu.enabled = 1 -description = This detection targets behaviors observed in post exploit kits like Meterpreter and Koadic that are run in memory. We have observed that these tools must invoke an excessive number of taskhost.exe and taskhostex.exe processes to complete various actions (discovery, lateral movement, etc.). It is extremely uncommon in the course of normal operations to see so many distinct taskhost and taskhostex processes running concurrently in a short time frame. +description = The following analytic identifies an excessive number of taskhost.exe and taskhostex.exe processes running within a short time frame. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and their counts. This behavior is significant as it is commonly associated with post-exploitation tools like Meterpreter and Koadic, which use multiple instances of these processes for actions such as discovery and lateral movement. If confirmed malicious, this activity could indicate an ongoing attack, allowing attackers to execute code, escalate privileges, or move laterally within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This detection targets behaviors observed in post exploit kits like Meterpreter and Koadic that are run in memory. We have observed that these tools must invoke an excessive number of taskhost.exe and taskhostex.exe processes to complete various actions (discovery, lateral movement, etc.). It is extremely uncommon in the course of normal operations to see so many distinct taskhost and taskhostex processes running concurrently in a short time frame. +action.escu.eli5 = The following analytic identifies an excessive number of taskhost.exe and taskhostex.exe processes running within a short time frame. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and their counts. This behavior is significant as it is commonly associated with post-exploitation tools like Meterpreter and Koadic, which use multiple instances of these processes for actions such as discovery and lateral movement. If confirmed malicious, this activity could indicate an ongoing attack, allowing attackers to execute code, escalate privileges, or move laterally within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators, administrative actions or certain applications may run many instances of taskhost and taskhostex concurrently. Filter as needed. -action.escu.creation_date = 2024-04-26 -action.escu.modification_date = 2024-04-26 +action.escu.creation_date = 2024-05-20 +action.escu.modification_date = 2024-05-20 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive number of taskhost processes - Rule action.escu.search_type = detection @@ -27229,7 +27094,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive number of taskhost processes - Rule action.correlationsearch.annotations = {"analytic_story": ["Meterpreter"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f443dac2-c7cf-11eb-ab51-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f443dac2-c7cf-11eb-ab51-acde48001122", "detection_version": "4"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27245,14 +27110,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process_id) [ESCU - Excessive Service Stop Attempt - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies suspicious series of attempt to kill multiple services on a system using either `net.exe` or `sc.exe`. This technique is use by adversaries to terminate security services or other related services to continue there objective and evade detections. +description = The following analytic detects multiple attempts to stop or delete services on a system using `net.exe`, `sc.exe`, or `net1.exe`. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line executions within a one-minute window. This activity is significant as it may indicate an adversary attempting to disable security or critical services to evade detection and further their objectives. If confirmed malicious, this could lead to the attacker gaining persistence, escalating privileges, or disrupting essential services, thereby compromising the system's security posture. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies suspicious series of attempt to kill multiple services on a system using either `net.exe` or `sc.exe`. This technique is use by adversaries to terminate security services or other related services to continue there objective and evade detections. +action.escu.eli5 = The following analytic detects multiple attempts to stop or delete services on a system using `net.exe`, `sc.exe`, or `net1.exe`. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on process names and command-line executions within a one-minute window. This activity is significant as it may indicate an adversary attempting to disable security or critical services to evade detection and further their objectives. If confirmed malicious, this could lead to the attacker gaining persistence, escalating privileges, or disrupting essential services, thereby compromising the system's security posture. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-05-04 -action.escu.modification_date = 2021-05-04 +action.escu.creation_date = 2024-05-25 +action.escu.modification_date = 2024-05-25 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive Service Stop Attempt - Rule action.escu.search_type = detection @@ -27270,7 +27135,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive Service Stop Attempt - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "Ransomware", "XMRig"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ae8d3f4a-acd7-11eb-8846-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "ae8d3f4a-acd7-11eb-8846-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27286,14 +27151,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Excessive Usage Of Cacls App - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe` or `icacls.exe` application to change file or folder permission. This behavior is commonly seen where the adversary attempts to impair some users from deleting or accessing its malware components or artifact from the compromised system. +description = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe`, or `icacls.exe` to change file or folder permissions. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an adversary attempting to restrict access to malware components or artifacts on a compromised system. If confirmed malicious, this behavior could prevent users from deleting or accessing critical files, aiding in the persistence and concealment of malicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe` or `icacls.exe` application to change file or folder permission. This behavior is commonly seen where the adversary attempts to impair some users from deleting or accessing its malware components or artifact from the compromised system. +action.escu.eli5 = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe`, or `icacls.exe` to change file or folder permissions. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant as it may indicate an adversary attempting to restrict access to malware components or artifacts on a compromised system. If confirmed malicious, this behavior could prevent users from deleting or accessing critical files, aiding in the persistence and concealment of malicious activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = Administrators or administrative scripts may use this application. Filter as needed. -action.escu.creation_date = 2021-05-07 -action.escu.modification_date = 2021-05-07 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive Usage Of Cacls App - Rule action.escu.search_type = detection @@ -27311,7 +27176,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive Usage Of Cacls App - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Prestige Ransomware", "Windows Post-Exploitation", "XMRig"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0bdf6092-af17-11eb-939a-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0bdf6092-af17-11eb-939a-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27327,14 +27192,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Excessive Usage Of Net App - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies excessive usage of `net.exe` or `net1.exe` within a bucket of time (1 minute). This behavior was seen in a Monero incident where the adversary attempts to create many users, delete and disable users as part of its malicious behavior. +description = The following analytic detects excessive usage of `net.exe` or `net1.exe` within a one-minute interval. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This behavior is significant as it may indicate an adversary attempting to create, delete, or disable multiple user accounts rapidly, a tactic observed in Monero mining incidents. If confirmed malicious, this activity could lead to unauthorized user account manipulation, potentially compromising system integrity and enabling further malicious actions. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies excessive usage of `net.exe` or `net1.exe` within a bucket of time (1 minute). This behavior was seen in a Monero incident where the adversary attempts to create many users, delete and disable users as part of its malicious behavior. +action.escu.eli5 = The following analytic detects excessive usage of `net.exe` or `net1.exe` within a one-minute interval. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and command-line executions. This behavior is significant as it may indicate an adversary attempting to create, delete, or disable multiple user accounts rapidly, a tactic observed in Monero mining incidents. If confirmed malicious, this activity could lead to unauthorized user account manipulation, potentially compromising system integrity and enabling further malicious actions. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown. Filter as needed. Modify the time span as needed. -action.escu.creation_date = 2023-06-13 -action.escu.modification_date = 2023-06-13 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive Usage Of Net App - Rule action.escu.search_type = detection @@ -27352,7 +27217,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive Usage Of Net App - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Graceful Wipe Out Attack", "Prestige Ransomware", "Ransomware", "Rhysida Ransomware", "Windows Post-Exploitation", "XMRig"], "cis20": ["CIS 10"], "confidence": 70, "impact": 40, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "45e52536-ae42-11eb-b5c6-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "45e52536-ae42-11eb-b5c6-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27368,14 +27233,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Excessive Usage of NSLOOKUP App - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type (TXT, A, AAAA) that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +description = The following analytic detects excessive usage of the nslookup application, which may indicate potential DNS exfiltration attempts. It leverages Sysmon EventCode 1 to monitor process executions, specifically focusing on nslookup.exe. The detection identifies outliers by comparing the frequency of nslookup executions against a calculated threshold. This activity is significant as it can reveal attempts by malware or APT groups to exfiltrate data via DNS queries. If confirmed malicious, this behavior could allow attackers to stealthily transfer sensitive information out of the network, bypassing traditional data exfiltration defenses. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type (TXT, A, AAAA) that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries. +action.escu.eli5 = The following analytic detects excessive usage of the nslookup application, which may indicate potential DNS exfiltration attempts. It leverages Sysmon EventCode 1 to monitor process executions, specifically focusing on nslookup.exe. The detection identifies outliers by comparing the frequency of nslookup executions against a calculated threshold. This activity is significant as it can reveal attempts by malware or APT groups to exfiltrate data via DNS queries. If confirmed malicious, this behavior could allow attackers to stealthily transfer sensitive information out of the network, bypassing traditional data exfiltration defenses. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of nslookup.exe may be used. action.escu.known_false_positives = unknown -action.escu.creation_date = 2022-06-03 -action.escu.modification_date = 2022-06-03 +action.escu.creation_date = 2024-05-15 +action.escu.modification_date = 2024-05-15 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive Usage of NSLOOKUP App - Rule action.escu.search_type = detection @@ -27393,7 +27258,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive Usage of NSLOOKUP App - Rule action.correlationsearch.annotations = {"analytic_story": ["Command And Control", "Data Exfiltration", "Dynamic DNS", "Suspicious DNS Traffic"], "cis20": ["CIS 10"], "confidence": 70, "impact": 40, "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0a69fdaa-a2b8-11eb-b16d-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "0a69fdaa-a2b8-11eb-b16d-acde48001122", "detection_version": "3"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27409,14 +27274,14 @@ search = `sysmon` EventCode = 1 process_name = "nslookup.exe" | bucket _time spa [ESCU - Excessive Usage Of SC Service Utility - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search is to detect a suspicious excessive usage of sc.exe in a host machine. This technique was seen in several ransomware , xmrig and other malware to create, modify, delete or disable a service may related to security application or to gain privilege escalation. +description = The following analytic detects excessive usage of the `sc.exe` service utility on a host machine. It leverages Sysmon EventCode 1 logs to identify instances where `sc.exe` is executed more frequently than normal within a 15-minute window. This behavior is significant as it is commonly associated with ransomware, cryptocurrency miners, and other malware attempting to create, modify, delete, or disable services, potentially related to security applications or for privilege escalation. If confirmed malicious, this activity could allow attackers to manipulate critical services, leading to system compromise or disruption of security defenses. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]} action.escu.data_models = [] -action.escu.eli5 = This search is to detect a suspicious excessive usage of sc.exe in a host machine. This technique was seen in several ransomware , xmrig and other malware to create, modify, delete or disable a service may related to security application or to gain privilege escalation. +action.escu.eli5 = The following analytic detects excessive usage of the `sc.exe` service utility on a host machine. It leverages Sysmon EventCode 1 logs to identify instances where `sc.exe` is executed more frequently than normal within a 15-minute window. This behavior is significant as it is commonly associated with ransomware, cryptocurrency miners, and other malware attempting to create, modify, delete, or disable services, potentially related to security applications or for privilege escalation. If confirmed malicious, this activity could allow attackers to manipulate critical services, leading to system compromise or disruption of security defenses. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed taskkill.exe may be used. action.escu.known_false_positives = excessive execution of sc.exe is quite suspicious since it can modify or execute app in high privilege permission. -action.escu.creation_date = 2021-06-24 -action.escu.modification_date = 2021-06-24 +action.escu.creation_date = 2024-05-19 +action.escu.modification_date = 2024-05-19 action.escu.confidence = high action.escu.full_search_name = ESCU - Excessive Usage Of SC Service Utility - Rule action.escu.search_type = detection @@ -27434,7 +27299,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Excessive Usage Of SC Service Utility - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "Ransomware"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cb6b339e-d4c6-11eb-a026-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "cb6b339e-d4c6-11eb-a026-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27491,26 +27356,14 @@ search = | tstats `security_content_summariesonly` values(Processes.process) as [ESCU - Exchange PowerShell Abuse via SSRF - Rule] action.escu = 0 action.escu.enabled = 1 -description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. This analytic identifies suspicious behavior related to ProxyShell against on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 which utilizes the Web Datamodel. \ -Modification of this analytic is requried to ensure fields are mapped accordingly. \ - \ -A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. This is indicative of accessing PowerShell on the back end of Exchange with SSRF. \ - \ -An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` (abbreviated) \ -Review the source attempting to perform this activity against your environment. In addition, review PowerShell logs and access recently granted to Exchange roles. +description = **WARNING**, this detection is marked **EXPERIMENTAL** by the Splunk Threat Research Team. This means that the detection has been manually tested but we do not have the associated attack data to perform automated testing or cannot share this attack dataset due to its sensitive nature. If you have any questions feel free to email us at: research@splunk.com. The following analytic detects suspicious behavior indicative of ProxyShell exploitation against on-premise Microsoft Exchange servers. It identifies HTTP POST requests to `autodiscover.json` containing `PowerShell` in the URI, leveraging server-side request forgery (SSRF) to access backend PowerShell. This detection uses Exchange server logs ingested into Splunk. Monitoring this activity is crucial as it may indicate an attacker attempting to execute commands or scripts on the Exchange server. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or persistent control over the Exchange environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = This analytic identifies suspicious behavior related to ProxyShell against on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 which utilizes the Web Datamodel. \ -Modification of this analytic is requried to ensure fields are mapped accordingly. \ - \ -A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. This is indicative of accessing PowerShell on the back end of Exchange with SSRF. \ - \ -An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` (abbreviated) \ -Review the source attempting to perform this activity against your environment. In addition, review PowerShell logs and access recently granted to Exchange roles. +action.escu.eli5 = The following analytic detects suspicious behavior indicative of ProxyShell exploitation against on-premise Microsoft Exchange servers. It identifies HTTP POST requests to `autodiscover.json` containing `PowerShell` in the URI, leveraging server-side request forgery (SSRF) to access backend PowerShell. This detection uses Exchange server logs ingested into Splunk. Monitoring this activity is crucial as it may indicate an attacker attempting to execute commands or scripts on the Exchange server. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or persistent control over the Exchange environment. action.escu.how_to_implement = The following analytic requires on-premise Exchange to be logging to Splunk using the TA - https://splunkbase.splunk.com/app/3225. Ensure logs are parsed correctly, or tune the analytic for your environment. action.escu.known_false_positives = Limited false positives, however, tune as needed. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Exchange PowerShell Abuse via SSRF - Rule action.escu.search_type = detection @@ -27528,17 +27381,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Experimental - Exchange PowerShell Abuse via SSRF - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "ProxyNotShell", "ProxyShell"], "cis20": ["CIS 10"], "confidence": 100, "impact": 80, "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "29228ab4-0762-11ec-94aa-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "29228ab4-0762-11ec-94aa-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic identifies suspicious behavior related to ProxyShell against on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 which utilizes the Web Datamodel. \ -Modification of this analytic is requried to ensure fields are mapped accordingly. \ - \ -A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. This is indicative of accessing PowerShell on the back end of Exchange with SSRF. \ - \ -An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` (abbreviated) \ -Review the source attempting to perform this activity against your environment. In addition, review PowerShell logs and access recently granted to Exchange roles. +action.notable.param.rule_description = The following analytic detects suspicious behavior indicative of ProxyShell exploitation against on-premise Microsoft Exchange servers. It identifies HTTP POST requests to `autodiscover.json` containing `PowerShell` in the URI, leveraging server-side request forgery (SSRF) to access backend PowerShell. This detection uses Exchange server logs ingested into Splunk. Monitoring this activity is crucial as it may indicate an attacker attempting to execute commands or scripts on the Exchange server. If confirmed malicious, this could lead to unauthorized access, privilege escalation, or persistent control over the Exchange environment. action.notable.param.rule_title = Exchange PowerShell Abuse via SSRF action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27556,22 +27403,14 @@ search = `exchange` c_uri="*//autodiscover*" cs_uri_query="*PowerShell*" cs_meth [ESCU - Exchange PowerShell Module Usage - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the usage of Exchange PowerShell modules that were recently used for a proof of concept related to ProxyShell. Adversaries may abuse a limited set of PwSh Modules related to Exchange once gained access via ProxyShell or ProxyNotShell. \ -Inherently, the usage of the modules is not malicious, but reviewing parallel processes, and user, of the session will assist with determining the intent. \ -Module - New-MailboxExportRequest will begin the process of exporting contents of a primary mailbox or archive to a .pst file. \ -Module - New-managementroleassignment can assign a management role to a management role group, management role assignment policy, user, or universal security group (USG). \ -Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate of search results, place search results on In-Place Hold or copy them to a Discovery mailbox. You can also place all contents in a mailbox on hold by not specifying a search query, which accomplishes similar results as Litigation Hold. \ Module - Get-Recipient cmdlet to view existing recipient objects in your organization. This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, mail contacts, and distribution groups). +description = The following analytic detects the usage of specific Exchange PowerShell modules, such as New-MailboxExportRequest, New-ManagementRoleAssignment, New-MailboxSearch, and Get-Recipient. It leverages PowerShell Script Block Logging (EventCode 4104) to identify these commands. This activity is significant because these modules can be exploited by adversaries who have gained access via ProxyShell or ProxyNotShell vulnerabilities. If confirmed malicious, attackers could export mailbox contents, assign management roles, conduct mailbox searches, or view recipient objects, potentially leading to data exfiltration, privilege escalation, or unauthorized access to sensitive information. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies the usage of Exchange PowerShell modules that were recently used for a proof of concept related to ProxyShell. Adversaries may abuse a limited set of PwSh Modules related to Exchange once gained access via ProxyShell or ProxyNotShell. \ -Inherently, the usage of the modules is not malicious, but reviewing parallel processes, and user, of the session will assist with determining the intent. \ -Module - New-MailboxExportRequest will begin the process of exporting contents of a primary mailbox or archive to a .pst file. \ -Module - New-managementroleassignment can assign a management role to a management role group, management role assignment policy, user, or universal security group (USG). \ -Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate of search results, place search results on In-Place Hold or copy them to a Discovery mailbox. You can also place all contents in a mailbox on hold by not specifying a search query, which accomplishes similar results as Litigation Hold. \ Module - Get-Recipient cmdlet to view existing recipient objects in your organization. This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, mail contacts, and distribution groups). +action.escu.eli5 = The following analytic detects the usage of specific Exchange PowerShell modules, such as New-MailboxExportRequest, New-ManagementRoleAssignment, New-MailboxSearch, and Get-Recipient. It leverages PowerShell Script Block Logging (EventCode 4104) to identify these commands. This activity is significant because these modules can be exploited by adversaries who have gained access via ProxyShell or ProxyNotShell vulnerabilities. If confirmed malicious, attackers could export mailbox contents, assign management roles, conduct mailbox searches, or view recipient objects, potentially leading to data exfiltration, privilege escalation, or unauthorized access to sensitive information. action.escu.how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. action.escu.known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting. -action.escu.creation_date = 2023-07-10 -action.escu.modification_date = 2023-07-10 +action.escu.creation_date = 2024-05-31 +action.escu.modification_date = 2024-05-31 action.escu.confidence = high action.escu.full_search_name = ESCU - Exchange PowerShell Module Usage - Rule action.escu.search_type = detection @@ -27589,15 +27428,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Exchange PowerShell Module Usage - Rule action.correlationsearch.annotations = {"analytic_story": ["BlackByte Ransomware", "CISA AA22-264A", "CISA AA22-277A", "ProxyNotShell", "ProxyShell"], "cis20": ["CIS 10"], "confidence": 80, "impact": 40, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2d10095e-05ae-11ec-8fdf-acde48001122", "detection_version": "5"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "2d10095e-05ae-11ec-8fdf-acde48001122", "detection_version": "6"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the usage of Exchange PowerShell modules that were recently used for a proof of concept related to ProxyShell. Adversaries may abuse a limited set of PwSh Modules related to Exchange once gained access via ProxyShell or ProxyNotShell. \ -Inherently, the usage of the modules is not malicious, but reviewing parallel processes, and user, of the session will assist with determining the intent. \ -Module - New-MailboxExportRequest will begin the process of exporting contents of a primary mailbox or archive to a .pst file. \ -Module - New-managementroleassignment can assign a management role to a management role group, management role assignment policy, user, or universal security group (USG). \ -Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate of search results, place search results on In-Place Hold or copy them to a Discovery mailbox. You can also place all contents in a mailbox on hold by not specifying a search query, which accomplishes similar results as Litigation Hold. \ Module - Get-Recipient cmdlet to view existing recipient objects in your organization. This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, mail contacts, and distribution groups). +action.notable.param.rule_description = The following analytic detects the usage of specific Exchange PowerShell modules, such as New-MailboxExportRequest, New-ManagementRoleAssignment, New-MailboxSearch, and Get-Recipient. It leverages PowerShell Script Block Logging (EventCode 4104) to identify these commands. This activity is significant because these modules can be exploited by adversaries who have gained access via ProxyShell or ProxyNotShell vulnerabilities. If confirmed malicious, attackers could export mailbox contents, assign management roles, conduct mailbox searches, or view recipient objects, potentially leading to data exfiltration, privilege escalation, or unauthorized access to sensitive information. action.notable.param.rule_title = Exchange PowerShell Module Usage action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27615,14 +27450,14 @@ search = `powershell` EventCode=4104 ScriptBlockText IN ("*New-MailboxExportRequ [ESCU - Executable File Written in Administrative SMB Share - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The Trickbot malware family also implements this behavior to try to infect other machines in the infected network. +description = The following analytic detects executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). It leverages Windows Security Event Logs with EventCode 5145 to identify this activity. This behavior is significant as it is commonly used by tools like PsExec/PaExec for staging binaries before creating and starting services on remote endpoints, a technique often employed for lateral movement and remote code execution. If confirmed malicious, this activity could allow an attacker to execute arbitrary code remotely, potentially compromising additional systems within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]} action.escu.data_models = [] -action.escu.eli5 = The following analytic identifies executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The Trickbot malware family also implements this behavior to try to infect other machines in the infected network. +action.escu.eli5 = The following analytic detects executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). It leverages Windows Security Event Logs with EventCode 5145 to identify this activity. This behavior is significant as it is commonly used by tools like PsExec/PaExec for staging binaries before creating and starting services on remote endpoints, a technique often employed for lateral movement and remote code execution. If confirmed malicious, this activity could allow an attacker to execute arbitrary code remotely, potentially compromising additional systems within the network. action.escu.how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy. action.escu.known_false_positives = System Administrators may use looks like PsExec for troubleshooting or administrations tasks. However, this will typically come only from certain users and certain systems that can be added to an allow list. -action.escu.creation_date = 2024-02-14 -action.escu.modification_date = 2024-02-14 +action.escu.creation_date = 2024-05-16 +action.escu.modification_date = 2024-05-16 action.escu.confidence = high action.escu.full_search_name = ESCU - Executable File Written in Administrative SMB Share - Rule action.escu.search_type = detection @@ -27640,11 +27475,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Executable File Written in Administrative SMB Share - Rule action.correlationsearch.annotations = {"analytic_story": ["Active Directory Lateral Movement", "Data Destruction", "Graceful Wipe Out Attack", "Hermetic Wiper", "IcedID", "Industroyer2", "Prestige Ransomware", "Trickbot"], "cis20": ["CIS 10"], "confidence": 100, "impact": 70, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f63c34fe-a435-11eb-935a-acde48001122", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "f63c34fe-a435-11eb-935a-acde48001122", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The Trickbot malware family also implements this behavior to try to infect other machines in the infected network. +action.notable.param.rule_description = The following analytic detects executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). It leverages Windows Security Event Logs with EventCode 5145 to identify this activity. This behavior is significant as it is commonly used by tools like PsExec/PaExec for staging binaries before creating and starting services on remote endpoints, a technique often employed for lateral movement and remote code execution. If confirmed malicious, this activity could allow an attacker to execute arbitrary code remotely, potentially compromising additional systems within the network. action.notable.param.rule_title = Executable File Written in Administrative SMB Share action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27662,14 +27497,14 @@ search = `wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.exe","* [ESCU - Executables Or Script Creation In Suspicious Path - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic identifies potentially malicious executables or scripts by examining a list of suspicious file paths on Windows Operating System. The purpose of this technique is to uncover files with known file extensions that could be used by adversaries to evade detection and persistence. The suspicious file paths selected for investigation are typically uncommon and uncommonly associated with executable or script files. By scrutinizing these paths, we can proactively identify potential security threats and enhance overall system security. +description = The following analytic identifies the creation of executables or scripts in suspicious file paths on Windows systems. It leverages the Endpoint.Filesystem data model to detect files with specific extensions (e.g., .exe, .dll, .ps1) created in uncommon directories (e.g., \windows\fonts\, \users\public\). This activity is significant as adversaries often use these paths to evade detection and maintain persistence. If confirmed malicious, this behavior could allow attackers to execute unauthorized code, escalate privileges, or persist within the environment, posing a significant security threat. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic identifies potentially malicious executables or scripts by examining a list of suspicious file paths on Windows Operating System. The purpose of this technique is to uncover files with known file extensions that could be used by adversaries to evade detection and persistence. The suspicious file paths selected for investigation are typically uncommon and uncommonly associated with executable or script files. By scrutinizing these paths, we can proactively identify potential security threats and enhance overall system security. +action.escu.eli5 = The following analytic identifies the creation of executables or scripts in suspicious file paths on Windows systems. It leverages the Endpoint.Filesystem data model to detect files with specific extensions (e.g., .exe, .dll, .ps1) created in uncommon directories (e.g., \windows\fonts\, \users\public\). This activity is significant as adversaries often use these paths to evade detection and maintain persistence. If confirmed malicious, this behavior could allow attackers to execute unauthorized code, escalate privileges, or persist within the environment, posing a significant security threat. action.escu.how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. action.escu.known_false_positives = Administrators may allow creation of script or exe in the paths specified. Filter as needed. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-21 +action.escu.modification_date = 2024-05-21 action.escu.confidence = high action.escu.full_search_name = ESCU - Executables Or Script Creation In Suspicious Path - Rule action.escu.search_type = detection @@ -27687,7 +27522,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Executables Or Script Creation In Suspicious Path - Rule action.correlationsearch.annotations = {"analytic_story": ["AgentTesla", "Amadey", "AsyncRAT", "Azorult", "BlackByte Ransomware", "Brute Ratel C4", "CISA AA23-347A", "Chaos Ransomware", "DarkCrystal RAT", "DarkGate Malware", "Data Destruction", "Double Zero Destructor", "Graceful Wipe Out Attack", "Hermetic Wiper", "IcedID", "Industroyer2", "LockBit Ransomware", "NjRAT", "PlugX", "Qakbot", "RedLine Stealer", "Remcos", "Rhysida Ransomware", "Snake Keylogger", "Swift Slicer", "Trickbot", "Volt Typhoon", "Warzone RAT", "WhisperGate", "XMRig"], "cis20": ["CIS 10"], "confidence": 50, "impact": 40, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a7e3f0f0-ae42-11eb-b245-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "a7e3f0f0-ae42-11eb-b245-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -27703,14 +27538,14 @@ search = |tstats `security_content_summariesonly` values(Filesystem.file_path) a [ESCU - Execute Javascript With Jscript COM CLSID - Rule] action.escu = 0 action.escu.enabled = 1 -description = This analytic will identify suspicious process of cscript.exe where it tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique was seen in ransomware (reddot ransomware) where it execute javascript with this com object with combination of amsi disabling technique. +description = The following analytic detects the execution of JavaScript using the JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as it is a known technique used by ransomware, such as Reddot, to execute malicious scripts and potentially disable AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.005"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This analytic will identify suspicious process of cscript.exe where it tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique was seen in ransomware (reddot ransomware) where it execute javascript with this com object with combination of amsi disabling technique. +action.escu.eli5 = The following analytic detects the execution of JavaScript using the JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as it is a known technique used by ransomware, such as Reddot, to execute malicious scripts and potentially disable AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = unknown -action.escu.creation_date = 2021-06-22 -action.escu.modification_date = 2021-06-22 +action.escu.creation_date = 2024-05-12 +action.escu.modification_date = 2024-05-12 action.escu.confidence = high action.escu.full_search_name = ESCU - Execute Javascript With Jscript COM CLSID - Rule action.escu.search_type = detection @@ -27728,11 +27563,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Execute Javascript With Jscript COM CLSID - Rule action.correlationsearch.annotations = {"analytic_story": ["Ransomware"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.005"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc64d064-d346-11eb-8588-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "dc64d064-d346-11eb-8588-acde48001122", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This analytic will identify suspicious process of cscript.exe where it tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique was seen in ransomware (reddot ransomware) where it execute javascript with this com object with combination of amsi disabling technique. +action.notable.param.rule_description = The following analytic detects the execution of JavaScript using the JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as it is a known technique used by ransomware, such as Reddot, to execute malicious scripts and potentially disable AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment. action.notable.param.rule_title = Execute Javascript With Jscript COM CLSID action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27750,14 +27585,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Execution of File with Multiple Extensions - Rule] action.escu = 0 action.escu.enabled = 1 -description = This search looks for processes launched from files that have double extensions in the file name. This is typically done to obscure the "real" file extension and make it appear as though the file being accessed is a data file, as opposed to executable content. +description = The following analytic detects the execution of files with multiple extensions, such as ".doc.exe" or ".pdf.exe". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the file name contains double extensions. This activity is significant because attackers often use double extensions to disguise malicious executables as benign documents, increasing the likelihood of user execution. If confirmed malicious, this technique can lead to unauthorized code execution, potentially compromising the endpoint and allowing further malicious activities. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = This search looks for processes launched from files that have double extensions in the file name. This is typically done to obscure the "real" file extension and make it appear as though the file being accessed is a data file, as opposed to executable content. +action.escu.eli5 = The following analytic detects the execution of files with multiple extensions, such as ".doc.exe" or ".pdf.exe". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the file name contains double extensions. This activity is significant because attackers often use double extensions to disguise malicious executables as benign documents, increasing the likelihood of user execution. If confirmed malicious, this technique can lead to unauthorized code execution, potentially compromising the endpoint and allowing further malicious activities. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = None identified. -action.escu.creation_date = 2020-11-18 -action.escu.modification_date = 2020-11-18 +action.escu.creation_date = 2024-05-26 +action.escu.modification_date = 2024-05-26 action.escu.confidence = high action.escu.full_search_name = ESCU - Execution of File with Multiple Extensions - Rule action.escu.search_type = detection @@ -27775,11 +27610,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Execution of File with Multiple Extensions - Rule action.correlationsearch.annotations = {"analytic_story": ["AsyncRAT", "DarkGate Malware", "Masquerading - Rename System Utilities", "Windows File Extension and Association Abuse"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b06a555e-dce0-417d-a2eb-28a5d8d66ef7", "detection_version": "3"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "b06a555e-dce0-417d-a2eb-28a5d8d66ef7", "detection_version": "4"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = This search looks for processes launched from files that have double extensions in the file name. This is typically done to obscure the "real" file extension and make it appear as though the file being accessed is a data file, as opposed to executable content. +action.notable.param.rule_description = The following analytic detects the execution of files with multiple extensions, such as ".doc.exe" or ".pdf.exe". This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where the file name contains double extensions. This activity is significant because attackers often use double extensions to disguise malicious executables as benign documents, increasing the likelihood of user execution. If confirmed malicious, this technique can lead to unauthorized code execution, potentially compromising the endpoint and allowing further malicious activities. action.notable.param.rule_title = Execution of File with Multiple Extensions action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27797,14 +27632,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Extraction of Registry Hives - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic identifies the use of `reg.exe` exporting Windows Registry hives containing credentials. Adversaries may use this technique to export registry hives for offline credential access attacks. Typically found executed from a untrusted process or script. Upon execution, a file will be written to disk. +description = The following analytic detects the use of `reg.exe` to export Windows Registry hives, which may contain sensitive credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `save` or `export` actions targeting the `sam`, `system`, or `security` hives. This activity is significant as it indicates potential offline credential access attacks, often executed from untrusted processes or scripts. If confirmed malicious, attackers could gain access to credential data, enabling further compromise and lateral movement within the network. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic identifies the use of `reg.exe` exporting Windows Registry hives containing credentials. Adversaries may use this technique to export registry hives for offline credential access attacks. Typically found executed from a untrusted process or script. Upon execution, a file will be written to disk. +action.escu.eli5 = The following analytic detects the use of `reg.exe` to export Windows Registry hives, which may contain sensitive credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `save` or `export` actions targeting the `sam`, `system`, or `security` hives. This activity is significant as it indicates potential offline credential access attacks, often executed from untrusted processes or scripts. If confirmed malicious, attackers could gain access to credential data, enabling further compromise and lateral movement within the network. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = It is possible some agent based products will generate false positives. Filter as needed. -action.escu.creation_date = 2023-12-27 -action.escu.modification_date = 2023-12-27 +action.escu.creation_date = 2024-05-23 +action.escu.modification_date = 2024-05-23 action.escu.confidence = high action.escu.full_search_name = ESCU - Extraction of Registry Hives - Rule action.escu.search_type = detection @@ -27822,11 +27657,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Extraction of Registry Hives - Rule action.correlationsearch.annotations = {"analytic_story": ["CISA AA22-257A", "CISA AA23-347A", "Credential Dumping", "DarkSide Ransomware", "Volt Typhoon"], "cis20": ["CIS 10"], "confidence": 70, "impact": 80, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8bbb7d58-b360-11eb-ba21-acde48001122", "detection_version": "2"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "8bbb7d58-b360-11eb-ba21-acde48001122", "detection_version": "3"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic identifies the use of `reg.exe` exporting Windows Registry hives containing credentials. Adversaries may use this technique to export registry hives for offline credential access attacks. Typically found executed from a untrusted process or script. Upon execution, a file will be written to disk. +action.notable.param.rule_description = The following analytic detects the use of `reg.exe` to export Windows Registry hives, which may contain sensitive credentials. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on command-line executions involving `save` or `export` actions targeting the `sam`, `system`, or `security` hives. This activity is significant as it indicates potential offline credential access attacks, often executed from untrusted processes or scripts. If confirmed malicious, attackers could gain access to credential data, enabling further compromise and lateral movement within the network. action.notable.param.rule_title = Extraction of Registry Hives action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27844,14 +27679,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - File with Samsam Extension - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents. +description = The following analytic detects file writes with extensions indicative of a SamSam ransomware attack. It leverages file-system activity data to identify file names ending in .stubbin, .berkshire, .satoshi, .sophos, or .keyxml. This activity is significant because SamSam ransomware is highly destructive, leading to file encryption and ransom demands. If confirmed malicious, the impact includes significant financial losses, operational disruptions, and reputational damage. Immediate actions should include isolating affected systems, restoring files from backups, and investigating the attack source to prevent further incidents. action.escu.mappings = {"cis20": ["CIS 10"], "nist": ["DE.CM"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents. +action.escu.eli5 = The following analytic detects file writes with extensions indicative of a SamSam ransomware attack. It leverages file-system activity data to identify file names ending in .stubbin, .berkshire, .satoshi, .sophos, or .keyxml. This activity is significant because SamSam ransomware is highly destructive, leading to file encryption and ransom demands. If confirmed malicious, the impact includes significant financial losses, operational disruptions, and reputational damage. Immediate actions should include isolating affected systems, restoring files from backups, and investigating the attack source to prevent further incidents. action.escu.how_to_implement = You must be ingesting data that records file-system activity from your hosts to populate the Endpoint file-system data-model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data. action.escu.known_false_positives = Because these extensions are not typically used in normal operations, you should investigate all results. -action.escu.creation_date = 2018-12-14 -action.escu.modification_date = 2018-12-14 +action.escu.creation_date = 2024-05-22 +action.escu.modification_date = 2024-05-22 action.escu.confidence = high action.escu.full_search_name = ESCU - File with Samsam Extension - Rule action.escu.search_type = detection @@ -27869,11 +27704,11 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - File with Samsam Extension - Rule action.correlationsearch.annotations = {"analytic_story": ["SamSam Ransomware"], "cis20": ["CIS 10"], "confidence": 90, "impact": 100, "nist": ["DE.CM"], "type": "TTP"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "02c6cfc2-ae66-4735-bfc7-6291da834cbf", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "02c6cfc2-ae66-4735-bfc7-6291da834cbf", "detection_version": "2"} schedule_window = auto action.notable = 1 action.notable.param.nes_fields = user,dest -action.notable.param.rule_description = The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents. +action.notable.param.rule_description = The following analytic detects file writes with extensions indicative of a SamSam ransomware attack. It leverages file-system activity data to identify file names ending in .stubbin, .berkshire, .satoshi, .sophos, or .keyxml. This activity is significant because SamSam ransomware is highly destructive, leading to file encryption and ransom demands. If confirmed malicious, the impact includes significant financial losses, operational disruptions, and reputational damage. Immediate actions should include isolating affected systems, restoring files from backups, and investigating the attack source to prevent further incidents. action.notable.param.rule_title = File with Samsam Extension action.notable.param.security_domain = endpoint action.notable.param.severity = high @@ -27891,14 +27726,14 @@ search = | tstats `security_content_summariesonly` count min(_time) as firstTime [ESCU - Firewall Allowed Program Enable - Rule] action.escu = 0 action.escu.enabled = 1 -description = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application. +description = The following analytic detects the modification of a firewall rule to allow the execution of a specific application. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events with command-line arguments related to firewall rule changes. This activity is significant as it may indicate an attempt to bypass firewall restrictions, potentially allowing unauthorized applications to communicate over the network. If confirmed malicious, this could enable an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the target environment. action.escu.mappings = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]} action.escu.data_models = ["Endpoint"] -action.escu.eli5 = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application. +action.escu.eli5 = The following analytic detects the modification of a firewall rule to allow the execution of a specific application. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process creation events with command-line arguments related to firewall rule changes. This activity is significant as it may indicate an attempt to bypass firewall restrictions, potentially allowing unauthorized applications to communicate over the network. If confirmed malicious, this could enable an attacker to execute arbitrary code, escalate privileges, or maintain persistence within the target environment. action.escu.how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. action.escu.known_false_positives = A network operator or systems administrator may utilize an automated or manual execution of this firewall rule that may generate false positives. Filter as needed. -action.escu.creation_date = 2021-11-12 -action.escu.modification_date = 2021-11-12 +action.escu.creation_date = 2024-05-11 +action.escu.modification_date = 2024-05-11 action.escu.confidence = high action.escu.full_search_name = ESCU - Firewall Allowed Program Enable - Rule action.escu.search_type = detection @@ -27916,7 +27751,7 @@ dispatch.latest_time = -10m@m action.correlationsearch.enabled = 1 action.correlationsearch.label = ESCU - Firewall Allowed Program Enable - Rule action.correlationsearch.annotations = {"analytic_story": ["Azorult", "BlackByte Ransomware", "NjRAT", "PlugX", "Windows Defense Evasion Tactics"], "cis20": ["CIS 10"], "confidence": 50, "impact": 50, "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"], "type": "Anomaly"} -action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9a8f63a8-43ac-11ec-904c-acde48001122", "detection_version": "1"} +action.correlationsearch.metadata = {"deprecated": "0", "detection_id": "9a8f63a8-43ac-11ec-904c-acde48001122", "detection_version": "2"} schedule_window = auto alert.digest_mode = 1 disabled = true @@ -28014,22 +27849,14 @@ search = `wineventlog_system` EventCode=7036 | rex field=Message "The (?